🔴 Red Team 101 — บทที่ 6: Web App Hacking เจาะเว็บผ่านช่องโหว่ที่คนละเลย

🎯 Web App Hacking ทำไมถึงสำคัญ?

เว็บแอปพลิเคชันคือ ช่องโหว่ที่ใหญ่ที่สุด ของทุกองค์กร — เพราะมันเปิดให้ทุกคนเข้าถึงได้ผ่าน internet

OWASP (Open Web Application Security Project) จัดอันดับช่องโหว่เว็บที่พบบ่อยที่สุดเป็น OWASP Top 10 — และช่องโหว่เหล่านี้ยังคงอยู่ในอันดับต้นๆ มาหลายทศวรรษ

🔴 ช่องโหว่ #1: SQL Injection (SQLi)

หลักการ

เว็บรับ input ของ user ไปใส่ใน SQL query โดยไม่กรอง — attacker แทรก SQL commands ลงไปใน input

ตัวอย่างแนวคิด (ไม่ใช่ payload จริง):

เว็บมีช่อง login:

SELECT * FROM users WHERE username = '[user_input]' AND password = '[user_input]'

ถ้า user พิมพ์ admin ก็ปกติ — แต่ถ้า attacker พิมพ์อะไรที่เป็น SQL syntax ที่ทำให้ query เปลี่ยนความหมาย ก็อาจ login ได้โดยไม่รู้ password

ประเภทของ SQLi

• In-band SQLi — ผลลัพธ์แสดงบนหน้าเว็บโดยตรง (Error-based, Union-based)
• Blind SQLi — ไม่เห็นผลลัพธ์โดยตรง แต่อาจ infer จากพฤติกรรม (Boolean-based, Time-based)
• Out-of-band SQLi — ส่งข้อมูลออกผ่าน channel อื่น (DNS, HTTP request)

ผลกระทบ

• อ่านข้อมูลจาก database ทั้งหมด
• แก้ไข/ลบข้อมูล
• ได้ access เข้าสู่ระบบ admin
• ในบางกรณี รัน commands บน server

วิธีป้องกัน

• Parameterized Queries (Prepared Statements) — ใช้ placeholder แทนการ concatenate string
• Input Validation — ตรวจสอบ input ว่าตรงกับ format ที่คาดหวัง
• Least Privilege — database user ของเว็บควรมีสิทธิ์แค่ SELECT/INSERT/UPDATE — ไม่ควรมี DROP, FILE, SUPER
• WAF — Web Application Firewall ช่วยกรอง malicious input

# ❌ ไม่ปลอดภัย
query = "SELECT * FROM users WHERE id = " + user_input

# ✅ ปลอดภัย (Parameterized Query)
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_input,))

🔴 ช่องโหว่ #2: Cross-Site Scripting (XSS)

หลักการ

เว็บแสดงผล input ของ user โดยไม่ escape HTML — attacker แทรก code ลงไปใน input แล้ว code นั้นจะรันบน browser ของ user คนอื่น

ประเภทของ XSS

• Reflected XSS — malicious code มาจาก URL/request แล้วแสดงผลทันที (ไม่เก็บใน database)
• Stored XSS — malicious code ถูกเก็บใน database แล้วแสดงผลทุกครั้งที่ user เปิดหน้านั้น (อันตรายกว่ามาก)
• DOM-based XSS — vulnerability อยู่ที่ client-side JavaScript ไม่ใช่ server

ผลกระทบ

• ขโมย session cookies → hijack user session
• แสดง fake login form → ขโมย credentials
• Redirect ไปเว็บปลอม
• Keylogger — บันทึกทุกอย่างที่ user พิมพ์

วิธีป้องกัน

• Output Encoding — escape HTML entities ก่อนแสดงผล (< → &lt;, > → &gt;)
• Content Security Policy (CSP) — HTTP header ที่จำกัดว่า script จากไหนสามารถรันได้
• HttpOnly Cookies — ทำให้ JavaScript อ่าน cookies ไม่ได้
• Input Validation — ตรวจสอบ input ว่าตรงกับ format ที่คาดหวัง

🔴 ช่องโหว่ #3: Cross-Site Request Forgery (CSRF)

หลักการ

Attacker หลอกให้ browser ของ victim ส่ง request ไปที่เว็บที่ victim login อยู่ — โดย victim ไม่รู้ตัว

สถานการณ์:

1. Victim login เข้าเว็บธนาคาร — ได้ session cookie
2. Victim เปิดเว็บของ attacker (ใน tab เดียวกัน)
3. เว็บของ attacker มี code ที่ส่ง request ไปที่เว็บธนาคาร พร้อม session cookie ของ victim
4. เว็บธนาคารเชื่อว่าเป็น victim ที่สั่ง — ทำตาม (เช่น โอนเงิน)

วิธีป้องกัน

• CSRF Tokens — สร้าง random token ในทุก form แล้ว verify ที่ server
• SameSite Cookies — ตั้งค่า SameSite=Strict หรือ SameSite=Lax
• Referer/Origin Check — ตรวจสอบว่า request มาจาก domain ที่ถูกต้อง

🔴 ช่องโหว่ #4: Broken Access Control (IDOR)

หลักการ

เว็บไม่ตรวจสอบว่า user มีสิทธิ์เข้าถึง resource นั้นหรือไม่ — attacker แค่เปลี่ยน ID ใน URL ก็เห็นข้อมูลคนอื่น

ตัวอย่าง:

• /invoice/1234 — invoice ของเรา
• /invoice/1235 — invoice ของคนอื่น (เปลี่ยนแค่ ID)

วิธีป้องกัน

• Server-side Authorization — ตรวจสอบสิทธิ์ทุกครั้งที่เข้าถึง resource
• Indirect References — ใช้ UUID แทน sequential ID
• Deny by Default — ไม่อนุญาตถ้าไม่ได้รับอนุญาตชัดเจน

🔴 ช่องโหว่ #5: Security Misconfiguration

ตัวอย่างที่พบบ่อย

• Default credentials (admin/admin) — ไม่เปลี่ยน
• Debug mode เปิดใน production — เห็น stack trace, internal paths
• Directory listing เปิด — เห็นไฟล์ทั้งหมด
• ไม่ปิด unnecessary services/ports
• Error messages เปิดเผยข้อมูล sensitive
• CORS misconfiguration — อนุญาต origin ใดๆ

วิธีป้องกัน

• Hardening — ปิดทุกอย่างที่ไม่จำเป็น
• Automated Scanning — ใช้ tools ตรวจสอบ configuration สม่ำเสมอ
• Minimal Information Disclosure — error messages ไม่ควรเปิดเผย internal details

🛠️ Tools สำหรับ Web App Testing

• Burp Suite — intercepting proxy สำหรับ web app testing (industry standard)
• OWASP ZAP — open source alternative ของ Burp Suite
• Nikto — web server vulnerability scanner
• SQLMap — automated SQL injection testing (ใช้เฉพาะระบบที่ได้รับอนุญาต)
• Dirb/Gobuster — directory bruteforce

📝 สรุปบทที่ 6

• SQLi — แทรก SQL ใน input → Parameterized Queries
• XSS — แทรก code ใน output → Output Encoding + CSP
• CSRF — หลอก browser ส่ง request → CSRF Tokens + SameSite
• IDOR — เปลี่ยน ID เข้าถึงข้อมูลคนอื่น → Server-side Authorization
• Misconfiguration — ตั้งค่าผิด → Hardening + Scanning

บทต่อไป: 🔴 Red Team 101 — บทที่ 7: Network Hacking เจาะเครือข่ายจากภายนอก

🦉 "ช่องโหว่ที่อันตรายที่สุดไม่ได้อยู่ที่เทคโนโลยี — อยู่ที่ความคิดที่ว่า 'มันไม่มีทางเกิดขึ้นกับเรา'"