เครื่องมือสาย Security (ใช้ในแล็บของเรา)

เครื่องมือคือส่วนขยายของความเข้าใจ ไม่ใช่ปุ่มเวทมนตร์

คนใหม่มักคิดว่าพอมีเครื่องมือแรง ๆ แล้วจะเก่งขึ้นทันที ความจริงคือเครื่องมือช่วยให้เรา "มองเห็น" สิ่งที่ปกติซ่อนอยู่ เช่น เห็นข้อมูลที่เบราว์เซอร์ส่งจริง ๆ เห็นว่าเครื่องเราเปิดบริการอะไรทิ้งไว้บ้าง แต่การตีความว่าสิ่งที่เห็นแปลว่าอะไร ต้องอาศัยความเข้าใจพื้นฐานจากบทก่อน ๆ เรื่องเว็บ เครือข่าย และช่องโหว่ เครื่องมือจึงขยายสมองเรา ไม่ได้แทนสมองเรา

proxy คั่นกลางทำงานอย่างไร

ปกติเบราว์เซอร์คุยกับเซิร์ฟเวอร์ตรง ๆ แต่เมื่อมี proxy คั่น เส้นทางจะกลายเป็น เบราว์เซอร์ → Burp → เซิร์ฟเวอร์ ทุกคำขอที่วิ่งผ่านจะโผล่ในหน้าต่างของ Burp ให้เราเห็นทั้ง method, path, headers, cookies และ body มีโหมด Intercept ที่หยุดคำขอไว้ให้เราดูทีละอัน กับ HTTP history ที่บันทึกทุกอย่างที่ผ่านไปแล้ว จุดสำคัญคือมันเผยให้เห็นว่าค่าที่หน้าเว็บ "ล็อกไว้ไม่ให้แก้" เช่นราคาสินค้าหรือรหัสผู้ใช้ จริง ๆ แล้วเป็นแค่ข้อความในคำขอที่แก้ได้ ถ้าแอปฝั่งเซิร์ฟเวอร์ไม่ตรวจซ้ำก็จะเชื่อค่าที่ถูกแก้นั้นทันที นี่คือบทเรียนล้ำค่าสำหรับคนเขียนโปรแกรม

อ่านผลลัพธ์ของ nmap ให้เป็น

เวลาสแกน แต่ละพอร์ตจะถูกรายงานเป็นสามสถานะหลัก คือ open หมายถึงมีบริการรับการเชื่อมต่ออยู่ closed หมายถึงเครื่องตอบกลับแต่ไม่มีบริการฟังพอร์ตนั้น และ filtered หมายถึงมีไฟร์วอลล์บังไว้จน nmap ไม่แน่ใจ ตัวเลือก -sV ช่วยเดาเวอร์ชันของบริการหลังพอร์ต ซึ่งมีประโยชน์มากในแง่ป้องกัน เพราะถ้าเห็นว่าเราเปิดบริการเวอร์ชันเก่าที่มีช่องโหว่รู้กันแล้ว ก็จะได้รีบอัปเดตหรือปิด สิ่งที่ควรตกใจไม่ใช่การถูกสแกน แต่คือการที่เราเปิดพอร์ตไว้เยอะโดยไม่รู้ตัว

สแกนเครื่องของตัวเอง เพื่อดูว่าเราเปิดบริการอะไรทิ้งไว้ (รันบนเครื่องเราเอง)

nmap -sV 127.0.0.1

# ตัวอย่างผลลัพธ์
PORT     STATE  SERVICE  VERSION
22/tcp   open   ssh      OpenSSH 8.9
3000/tcp open   http     Node.js Express
5432/tcp open   postgres PostgreSQL 14

จากผลตัวอย่าง เราจะเห็นทันทีว่าฐานข้อมูล postgres เปิดออกมาให้มองเห็น ซึ่งโดยปกติไม่ควรเปิดสู่ภายนอก นี่คือสิ่งที่การสแกนตัวเองช่วยให้เราจับได้ก่อนคนอื่น

อ่านและเขียน HTTP ทีละบรรทัด

ด้วย curl เราเลือก method ได้ด้วย -X ใส่ header เองด้วย -H แนบข้อมูลด้วย -d และดู header ที่ตอบกลับมาด้วย -i ทั้งหมดนี้ทำให้เราทดสอบพฤติกรรมของ API ตัวเองได้ตรงจุด เช่น ลองเรียกหน้าที่ควรต้องล็อกอินก่อน แล้วดูว่าเซิร์ฟเวอร์ตอบ 401 หรือ 403 อย่างที่ควรไหม หรือลองส่งข้อมูลผิดชนิดเพื่อดูว่าระบบตรวจสอบและปฏิเสธถูกต้องหรือเปล่า

คุยกับแอปของเราเองบน localhost เพื่อดู header และสถานะที่ตอบกลับ

# ดู header และ status code ที่แอปเราตอบกลับ
curl -i http://localhost:3000/

# ส่งคำขอแบบมี header เอง ไปยัง API ของเราเอง
curl -X POST http://localhost:3000/api/login \
  -H "Content-Type: application/json" \
  -d '{"user":"test","pass":"test"}'

สังเกตว่าเราชี้ไปที่ localhost ซึ่งคือเครื่องของเราเอง การฝึก curl ที่ดีคือใช้ตรวจสอบว่าแอปที่เรากำลังพัฒนา ตอบสนองอย่างถูกต้องปลอดภัยในทุกกรณี ไม่ใช่การยิงคำขอไปหาเว็บของคนอื่น

ทบทวนความเข้าใจ