เจาะลึก: จากช่องโหว่ XSS ธรรมดา สู่การยึดบัญชีผู้ใช้เบ็ดเสร็จ

เจาะลึก: จากช่องโหว่ XSS ธรรมดา สู่การยึดบัญชีผู้ใช้เบ็ดเสร็จ

ช่องโหว่ Cross-Site Scripting หรือ XSS เป็นหนึ่งในปัญหาด้านความปลอดภัยทางเว็บที่พบได้บ่อยครั้ง หลายคนอาจมองว่าเป็นแค่ช่องโหว่เล็กๆ น้อยๆ ที่ทำให้เว็บไซต์แสดงข้อความแปลกๆ หรือรันสคริปต์ได้เพียงชั่วครู่

แต่ในความเป็นจริงแล้ว ช่องโหว่ XSS แม้จะเป็นประเภทที่ดูไม่รุนแรงนัก ก็สามารถถูกยกระดับกลายเป็นเครื่องมือที่นำไปสู่การ ยึดครองบัญชีผู้ใช้ (Account Takeover) ได้อย่างสมบูรณ์ ลองมาดูกันว่าการโจมตีลักษณะนี้เกิดขึ้นได้อย่างไร


XSS คืออะไร และทำไมถึงอันตรายกว่าที่คิด?

XSS คือช่องโหว่ที่ผู้โจมตีสามารถฉีดโค้ดสคริปต์ (มักจะเป็น JavaScript) เข้าไปในเว็บไซต์ แล้วโค้ดนั้นจะถูกรันบนเบราว์เซอร์ของเหยื่อที่เข้ามาชมหน้าเว็บดังกล่าว

โดยทั่วไปแล้ว Reflected XSS เป็นประเภทหนึ่งที่โค้ดจะถูกสะท้อนกลับมาจากอินพุตของผู้ใช้ ซึ่งมักจะเห็นได้ชัดเจนหากใส่โค้ดใน URL แต่สำหรับ Post-based XSS นั้น โค้ดจะถูกส่งไปพร้อมกับการร้องขอแบบ POST เช่น ในฟอร์มต่างๆ ทำให้ดูเหมือนว่าการโจมตีจะทำได้ยากกว่า เพราะไม่สามารถส่ง URL ที่มีโค้ดไปให้เหยื่อคลิกได้โดยตรง

แต่ความเข้าใจที่ว่า Post-based XSS อันตรายน้อยกว่านั้นเป็นสิ่งที่ไม่ถูกต้อง เพราะมีเทคนิคที่จะเปลี่ยนช่องโหว่นี้ให้เป็นอาวุธร้ายแรงได้


ก้าวแรก: เจาะ Post-Based XSS ที่ถูกมองข้าม

ลองนึกภาพช่องโหว่ที่อยู่ในหน้า “ติดต่อเรา” ของเว็บไซต์แห่งหนึ่ง เมื่อผู้ใช้ส่งข้อความผ่านฟอร์มดังกล่าว ระบบจะนำข้อความนั้นไปแสดงผลในหน้าถัดไป หากข้อความนั้นไม่มีการตรวจสอบหรือกรองอย่างเหมาะสม ผู้โจมตีสามารถใส่โค้ด JavaScript เช่น <script>alert('XSS!')</script> ลงไปในช่องข้อความได้

เมื่อส่งฟอร์มไป เบราว์เซอร์จะรันโค้ดนั้นทันที เป็นการยืนยันว่ามีช่องโหว่ XSS จริง

ปัญหาคือการโจมตีเหยื่อนั้นไม่ง่ายนัก เพราะผู้โจมตีต้องส่งการร้องขอแบบ POST ซึ่งปกติจะต้องทำผ่านฟอร์ม นอกจากนี้ ฟอร์มส่วนใหญ่มักมีระบบ CSRF Token (Cross-Site Request Forgery Token) เพื่อป้องกันการโจมตีแบบปลอมแปลงการร้องขอ ทำให้ผู้โจมตีต้องหาวิธีจัดการกับสิ่งกีดขวางเหล่านี้


ปลดล็อกด้วยการหลบเลี่ยง CSRF Protection

CSRF Token คือรหัสลับเฉพาะที่เว็บไซต์สร้างขึ้นเพื่อยืนยันว่าการร้องขอมาจากผู้ใช้จริง ไม่ใช่จากเว็บไซต์อันตรายที่แอบส่งข้อมูล

วิธีที่ผู้โจมตีใช้ในการข้ามผ่าน CSRF Token สำหรับ Post-based XSS คือการสร้างหน้าเว็บปลอมขึ้นมา

หน้าเว็บปลอมนี้จะมี iframe ที่ซ่อนอยู่ ซึ่งโหลดหน้า “ติดต่อเรา” ที่มีช่องโหว่ของเว็บไซต์เป้าหมาย หน้าเว็บปลอมจะใช้ JavaScript ดึงค่า CSRF Token ที่อยู่ใน iframe นั้นออกมา จากนั้น จะสร้าง ฟอร์มซ่อน ที่มีการร้องขอแบบ POST ไปยังเว็บไซต์เป้าหมาย ฟอร์มนี้จะถูกเติมด้วยโค้ด XSS ที่ต้องการ และ CSRF Token ที่เพิ่งถูกดึงมา

เมื่อเหยื่อเข้าเยี่ยมชมหน้าเว็บปลอม ฟอร์มซ่อนก็จะถูกส่งออกไปโดยอัตโนมัติ ทำให้โค้ด XSS ถูกรันบนเบราว์เซอร์ของเหยื่อได้สำเร็จ


จากการรันสคริปต์ สู่การควบคุมบัญชีเต็มรูปแบบ

เมื่อ XSS ถูกรันบนเบราว์เซอร์ของเหยื่อแล้ว ผู้โจมตีมีอำนาจในการสั่งให้ JavaScript ทำอะไรก็ได้ในบริบทของเว็บไซต์นั้น

ในขั้นแรก ผู้โจมตีอาจพยายาม ขโมยคุกกี้เซสชัน ของเหยื่อผ่าน document.cookie เพื่อใช้เข้าสู่ระบบเป็นเหยื่อ แต่บ่อยครั้งที่คุกกี้เซสชันถูกตั้งค่าด้วยแฟล็ก HttpOnly ซึ่งจะป้องกันไม่ให้ JavaScript เข้าถึงได้โดยตรง

อย่างไรก็ตาม มีวิธีที่ซับซ้อนกว่านั้น

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

ขั้นตอนคือ JavaScript ของผู้โจมตีจะไป ดึง CSRF Token ที่อยู่ในฟอร์มเปลี่ยนรหัสผ่านหรือเปลี่ยนอีเมลของเหยื่อ จากนั้นจะสร้างการร้องขอแบบ POST โดยอัตโนมัติ เพื่อส่งข้อมูลที่เปลี่ยนแปลงอีเมลหรือรหัสผ่านของเหยื่อไปเป็นของผู้โจมตี โดยเบราว์เซอร์ของเหยื่อจะแนบคุกกี้เซสชันที่มี HttpOnly ไปให้เองโดยธรรมชาติ ทำให้การเปลี่ยนแปลงนี้ดูเหมือนเป็นการกระทำของเหยื่อ

เมื่อสำเร็จ บัญชีของเหยื่อก็จะตกไปอยู่ในการควบคุมของผู้โจมตีอย่างสมบูรณ์


บทเรียนสำคัญสำหรับความปลอดภัย

การโจมตีประเภทนี้แสดงให้เห็นว่า การพึ่งพากลไกป้องกันเพียงอย่างเดียวอาจไม่เพียงพอ ช่องโหว่ที่ดูเล็กน้อยสามารถกลายเป็นการโจมตีครั้งใหญ่ได้ หากมีช่องโหว่หลายจุดเชื่อมโยงกัน

สิ่งสำคัญคือการ ตรวจสอบความปลอดภัยอย่างครอบคลุม ตั้งแต่การกรองอินพุตและการเข้ารหัสเอาต์พุต (Output Encoding) เพื่อป้องกัน XSS ไปจนถึงการใช้ CSRF Token ที่แข็งแกร่ง และการตั้งค่า HttpOnly และ Secure สำหรับคุกกี้เซสชัน การทำความเข้าใจภาพรวมของการโจมตีจะช่วยให้ผู้พัฒนาสามารถสร้างระบบที่มีภูมิคุ้มกันที่ดีขึ้นได้

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