การโจมตีแบบ Cross-Site Scripting (XSS) คืออะไร มีกี่ประเภท?

https://www.wpexplorer.com/wp-content/uploads/wordpress-cross-site-scripting-guide-prevention.png

Cross-Site Scripting (XSS) เป็นรูปแบบหนึ่งของการ injection ซึ่ง Script ที่เป็นอันตรายจะถูก inject เข้าไปในเว็บไซต์ที่ปลอดภัยและเชื่อถือได้ การโจมตี XSS เกิดขึ้นเมื่อ Attacker ใช้ web applicaiton เพื่อส่ง code ที่เป็นอันตราย ซึ่งโดยทั่วไปจะอยู่ในรูปแบบของ script ฝั่งไว้บน browser ไปยัง user คนอื่น ข้อบกพร่องที่ช่วยให้การโจมตีเหล่านี้ประสบความสำเร็จนั้นค่อนข้างแพร่หลายและเกิดขึ้นได้ทุกที่ที่ web applicaiton ใช้ input จาก user ภายใน และ output ที่สร้างขึ้นโดยไม่ต้องตรวจสอบความถูกต้องหรือการเข้ารหัส

จะเป็นอย่างไรถ้าเหยื่อ เข้าWeb applicationนั้น ?

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

ประเภทของ XSS

ในปี 2005 Amit Klein ได้กำหนด XSS สามประเภท ซึ่ง Amit เป็นผู้บัญญัติศัพท์ DOM Based XSS XSS ดังนี้:

1.Reflected XSS (AKA Non-Persistent or Type II)

Reflected XSSเกิดขึ้นเมื่อ Attacker ส่ง Javascript ผ่านช่องรับข้อมูล แล้วให ้User ป้อนข้อมูล ด้วยการ search หรือ URL แล้วข้อมูลจะถูกส่ง return กลับทันทีโดย web application ของข้อความจะแสดง Error ,ผลการค้นหา หรือการตอบสนองอื่น ๆ โดยที่ข้อมูลที่ไม่ปลอดภัยจะแสดงบน browser ซึ่งใช้เป็นส่วนของ back-end ในการแสดงผล และไม่มีการจัดเก็บข้อมูลลงใน database ในบางกรณีข้อมูลที่ user ให้มาอาจไม่เคย logout ออกจาก browser เลย

การโจมตีแบบ Reflected XSS

1.Attacker จะค้นหา Website ที่มีช่องโหว่ซึ่งสามารถใช้ในการโจมตีได้ เมื่อเว็บไซต์ ถูกระบุว่ามีความเสี่ยง Attackerจะพยายามแทรก Code/Script ลงใน website และตรวจสอบว่า script ถูกส่งกลับเป็นรูปแบบเดิมหรือไม่ กระบวนการนี้สามารถทำได้ด้วยตนเองหรือโดยอัตโนมัติ ขึ้นอยู่กับ web application

2.รหัสที่เป็นอันตราย (JavaScript) สามารถจัดส่งใน URL ในรูปแบบที่ encoded format หรือ HTTP POST request วิดีโอ Flash drive หรือรูปภาพ

3.ส่งไปยัง user ซึ่ง user ไม่รู้ว่า Script นั้นเป็นอันตราย แล้วจึงเข้าเว็บไซต์ปกติ

4.script ที่เป็นอันตราย ถูก runโดย user คนนั้น Attacker สามารถที่จะขโมย cookies session tokens หรือข้อมูลที่ละเอียดอ่อนที่ browser เก็บไว้และใช้กับ website นั้นได้

2.Stored XSS (AKA Persistent or Type I)

โดยทั่วไปแล้ว Stored XSS เกิดขึ้นเมื่อข้อมูลของ user ถูกจัดเก็บไว้บน server ลงใน database ของ web application ที่ Attacker ได้ทำการใส่ Javascript ลงไปใน Database เป้าหมาย หลังจากนั้นUser จะดึงข้อมูลที่เก็บไว้ที่เป็นอันตรายจาก web application ผ่านทาง ช่อง Forum ข้อความ ช่องแสดงความคิดเห็น ฯลฯ

การโจมตีแบบ Stored XSS

1. Attacker โพสต์หัวข้อและแทรก Scriptที่เป็นอันตราย บนเว็บแอปพลิเคชัน

2. หลังจากนั้น scriptนั้นถูกฝั่งลงใน database

3. เมื่อUserเข้ามาใช้งานเว็บแอปพลิเคชันที่มีช่องโหว่ก็จะได้รับ Script ที่เป็นอันตรายจากเว็บแอปพลิเคชันนั้นค่ะ เพราะว่าtopicที่attackerได้ฝังไว้ ถูกโหลดแล้วเนื้อหาจะถูกส่งไปยัง browser ของเหยื่อและทำการ payload หรือ อีกวิธีหนึ่ง Attacker อาจสร้างเครื่องมือที่โพสต์เกี่ยวกับเนื้อหาที่เป็นอันตรายเพื่อตอบกลับ อัตโนมัติ ได้ค่ะ

4. หลังจากนั้น attackerก็ได้รับข้อมูลส่วนตัวของUser ค่ะ

3.DOM Based XSS (AKA Type-0)

DOM XSS ย่อมาจาก Document Object Model-based Cross-site Scripting การโจมตี XSS แบบ DOM มันจะทำได้ถ้า Web application เขียนข้อมูลไปยัง Document Object Model โดยไม่มีการดูแล Attacker สามารถจัดการข้อมูลนี้เพื่อรวม content XSS บนหน้าเว็บ เช่น code JavaScript ที่เป็นอันตราย

Document Object Model เป็นแบบแผนที่ใช้ในการแสดงและทำงานกับ Objectใน HTML document ซึ่ง HTML document ทั้งหมดมี DOM เกี่ยวข้องซึ่งประกอบด้วย Object ที่แสดงถึงคุณสมบัติของ document จากมุมมองของ Browser เมื่อมีการเรียกใช้ script ฝั่งclient จะใช้ DOM บนหน้า HTML แล้ว script ทำงาน โดย script สามารถเข้าถึงคุณสมบัติต่างๆ ของ page และเปลี่ยนค่าได้ด้วยนะ

Attacker ใช้ DOM object หลาย object เพื่อสร้างการโจมตีแบบ Cross-site Scripting object ยอดนิยมจากวิธีนี้คือ document.url, document.location และ document.referrer

การโจมตีแบบDOM Based XSS

ตัวอย่าง URL http://www.example.com/userdashboard.html page

Attacker เข้ารหัส user name ใน URL นี้และใช้ในการเข้าเว็บไซต์โดยตรงได้ผลลัพธ์ต่อไปนี้:

https://www.acunetix.com/blog/articles/dom-xss-explained/

ถ้าให้ URL http://www.example.com/userdashboard.html?context=Mary เป็น dashboard ที่ปรับแต่งสำหรับ Mary ประกอบด้วย string Main Dashboard

Attacker โจมตีวิธี DOM XSS ต่อไปนี้:

1. ผู้โจมตีฝัง script ที่เป็นอันตรายใน URL: http://www.example.com/userdashboard.html#context=<script>SomeFunction(somevariable)</script>
2. Browser ของเหยื่อได้รับ URL นี้ ส่งคำขอ HTTP ไปที่ http://www.example.com และรับ static HTML page
3. Browser เริ่มสร้าง DOM ของหน้าและเติมคุณสมบัติ document.URL ด้วย URL จากขั้นตอนที่ 1
4. Browser จะแยกวิเคราะห์ (parses ) หน้า HTML เข้าถึง script และ run โดยแยก content ที่เป็นอันตรายออกจากคุณสมบัติ document.URL
5. Browser จะ update HTML body ของหน้าให้มี: Main Dashboard สำหรับ <script>SomeFunction(somevariable)</script>
6. Browser จะค้นหาcode JavaScript ใน HTML body และ executes

ในความเป็นจริง Attacker จะเข้ารหัส payload ของ URL เพื่อเหยื่อรู้ว่ามี script ที่อันตราย อยู่ browser บางตัวอาจเข้ารหัสอักขระ < และ > ใน URL ทำให้การโจมตีล้มเหลว อย่างไรก็ตาม มีสถานการณ์อื่นๆ ที่ไม่ต้องการอักขระเหล่านี้ หรือการฝัง code ลงใน URL โดยตรง ดังนั้น browser เหล่านี้จึงไม่สามารถป้องกัน DOM XSS ได้ทั้งหมด

สรุปอีกรอบง่ายๆนะคะก็คือ

1. Stored XSS

• Attackerเขียน script javascript ลงใน Database ของWeb application ของเหยื่อ

2.Reflected XSS

• Attacker ส่ง Javascript ผ่านช่องทางรับข้อมูล หรือ การ search หรือผ่านทางURL
• ใช้ back-end (PHP/ruby/python/java) ในการแสดงผลข้อมูล Javascript
• ไม่เก็บลงใน database

3.DOM XSS

• Attacker ส่ง Javascript ผ่านช่องทางรับข้อมูล หรือ การ search หรือผ่านทาง UR เหมือนกับ Reflected XSS แต่ไม่ใช้ร่วมกับ back-end ในการแสดงผล Javascript
• จะแสดงผลแบบ Document Object

แต่หลายปีที่ผ่านมา คนส่วนใหญ่คิดว่าสิ่งเหล่านี้ (Stored, Reflected, DOM) เป็น XSS ที่แตกต่างกันสามประเภท แต่ในความเป็นจริง มันทับซ้อนกัน สามารถมีทั้ง Stored และ Reflected DOM Based XSS และยังสามารถมี XSS แบบ Stored and Reflected Non-DOM Based ได้อีกด้วย แต่นั่นก็ทำให้สับสน ดังนั้น เริ่มตั้งแต่กลางปี 2012 ชุมชนการวิจัยได้เสนอและเริ่มใช้คำศัพท์ใหม่สองคำเพื่อช่วยจัดระเบียบประเภทของ XSS ที่เกิดขึ้นได้ดังนี้:

1.Server XSS เกิดขึ้นเมื่อระบุข้อมูลโดย user ข้อมูลที่ไม่น่าเชื่อถือจะอยู่รวมกันใน HTTP response ที่สร้างโดย Server source ข้อมูลนี้อาจมาจากคำขอหรือจาก stored location ดังนั้นสามารถมีทั้ง Reflected Server XSS และ Stored Server XSS

ในกรณีนี้ ช่องโหว่ทั้งหมดอยู่ใน server-side code และ browser จะแสดงการตอบสนองและเรียกใช้ script embedded อยู่ในนั้น

2.Client XSSเกิดขึ้นเมื่อ user ใช้ข้อมูลที่ไม่น่าเชื่อถือในการอัปเดต DOM ด้วยการเรียก JavaScript ที่ไม่ปลอดภัย
การเรียก JavaScript ไม่ปลอดภัย ถ้าสามารถนำมาใช้เพื่อแนะนำ JavaScript ที่ valid ใน DOM source นี้อาจมาจาก DOM หรือ server ส่งผ่านการเรียก AJAX หรือการ page load source ของข้อมูลอาจมาจากคำขอ หรือ จากstored location ใน Client หรือ Server ดังนั้น สามารถมีทั้ง Reflected Client XSS และ Stored Client XSS

ด้วยคำจำกัดความใหม่เหล่านี้ คำจำกัดความของ DOM Based XSS จะไม่เปลี่ยนแปลง DOM Based XSS เป็นเพียงส่วนย่อยของ Client XSS โดยที่ source อยู่ที่ใดที่หนึ่งใน DOM แทนที่จะเป็นจาก server
เนื่องจาก Server XSS and Client XSS สามารถStored หรือ Reflectedได้

การป้องกัน XSS ของ Server

ในส่วนนี้ เราจะอธิบายหลักการทั่วไปในการป้องกันช่องโหว่ของ Cross-Site Scripting สามารถทำได้ผ่าน 2 layer นี้

1.Encode data on output

ควรใช้การเข้ารหัสโดยตรงก่อนที่ ข้อมูลของ user จะถูกเขียนลงในเพจ เนื่องจากบริบทที่ user เขียนจะเป็นตัวกำหนดประเภทของการเข้ารหัสที่ user ต้องการใช้ ตัวอย่างเช่น ค่าภายในstringของ JavaScript ต้องใช้ค่า Escape ประเภทอื่นไปยังค่าใน HTML context

ใน HTML context ควรแปลงค่าที่ไม่อนุญาตเป็นเอนทิตี HTML:

• < แปลงเป็น: &lt;
• > แปลงเป็น: &gt;

ในบริบทstringของ JavaScript ค่าที่ไม่ใช่ตัวอักษรและตัวเลขควรเป็น Unicode-escaped

• < แปลงเป็น: \u003c
• > แปลงเป็น: \u003e

บางครั้ง จะต้องใช้การเข้ารหัสหลาย layer ในลำดับที่ถูกต้อง ตัวอย่างเช่น ในการฝัง input ของ user อย่างปลอดภัยภายในตัวจัดการเหตุการณ์ ต้องจัดการกับทั้งบริบท JavaScript และบริบท HTML ดังนั้นคุณต้องหลีกเลี่ยง Unicode ก่อนจากนั้นจึงเข้ารหัส HTML:

2.ตรวจสอบความถูกต้องของ input เมื่อได้รับค่า

ตัวอย่างของการตรวจสอบ input ได้แก่:

• ถ้า user ส่ง URL ที่ return คืนเป็นการตอบกลับ เริ่มต้นด้วยตรวจสอบ URL protocol ที่ปลอดภัย เช่นHTTPS ถ้าไม่เช่นนั้น Attacker อาจใช้ประโยชน์จาก Website ของเราได้ ด้วย protocol ที่เป็นอันตราย เช่น Javascript
• ถ้า user ระบุค่าที่คาดว่าจะเป็นตัวเลขให้ตรวจสอบว่าค่านั้นเป็นจำนวนเต็ม( integer)จริง ๆหรือไม่

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

Reference :

What Is Persistent XSS | Acunetix

Cross Site Scripting Prevention - OWASP Cheat Sheet Series

Types of XSS

What is Cross-site Scripting and How Can You Fix it?

How to prevent XSS | Web Security Academy