Cross-Site Scripting (XSS) คืออะไร
Cross-Site Scripting (XSS) คือช่องโหว่ที่ผู้ไม่ประสงค์ดีสามารถแทรกชุดคำสั่ง Script และแสดงผลกลับมายังผู้ใช้งานได้ ซึ่งช่องโหว่นี้สามารถใช้เพื่อขโมยข้อมูลสำคัญของผู้ใช้งาน หรือใช้เพื่อการดำเนินการอื่น ๆ ที่เกิดอันตรายต่อผู้ใช้งานได้ โดยช่องโหว่ที่ถูกจัดเอาไว้ใน OWASP A07:2017-Cross-Site Scripting (XSS) ใน OWASP 2017 และถูกรวมเข้ากับหัวข้อ Injection ใน OWASP 2021 จึงถูกจัดเอาไว้ใน OWASP A03:2021-Injection ในวันนี้ผู้เขียนจะมาเล่าถึงหนึ่งใน Category ของ XSS นั่นคือ Mutation XSS
Mutation XSS คืออะไร
Mutation XSS คือการที่ Browser ของเราทำการแก้ไข Input จากผู้ใช้งานซึ่งเป็นโค้ดที่ไม่สมบูรณ์ ให้กลายเป็นโค้ดที่สมบูรณ์เพื่อนำมาแสดงผลได้อย่างถูกต้อง แต่เมื่อ Browser ของเราแก้ไข Input ดังกล่าวแล้ว กลับทำให้ Script ที่แทรกอยู่ใน Input นั้นสมบูรณ์ จึงทำให้ Script ที่แทรกอยู่ใน Input จากผู้ใช้งานสามารถทำงานได้
Mutation XSS เกิดขึ้นจากอะไร
Mutation XSS เกิดจากการที่ตัวกรอง XSS ที่ฝั่ง Client Side มองว่า Input จากผู้ใช้งานนั้นปลอดภัย แต่เมื่อส่งต่อมาให้ Browser ประมวลผลต่อ Browser มองว่า Input นั้นเป็น HTML ที่ไม่ถูกต้อง จึงมีการแก้ไข Input นั้นให้สมบูรณ์เพื่อนำมาแสดงผล แต่หลังจาก Browser แก้ไข Input ดังกล่าว ทำให้ JavaScript ที่อยู่ใน Input จากผู้ใช้งานทำงานขึ้นมาเกิดเป็นช่องโหว่ Mutation XSS
การประมวลผล HTML โค้ดที่เขียนมาไม่ถูกต้องของ Browser เราลองทดสอบดูด้วยตัวเองกันครับ
ตัวอย่างที่ 1
ทดลองสร้างไฟล์ HTML ที่มีโค้ดดังภาพขึ้นมา
ลองเปิดไฟล์ HTML ดังกล่าวด้วย Browser จะพบว่าโค้ดของเราจะถูกจัดการโดย Browser ทำให้มีหน้าตาที่เปลี่ยนแปลงไปเนื่องจาก Browser พบ div Tag และ script Tag Browser จึงใช้ HTML Parser เพื่อทำให้ Tag div และ Tag script สมบูรณ์ โดยการเพิ่มปิด script Tag และปิด div Tag เข้าไป จากนั้นจึงใส่โค้ดทั้งหมดเอาไว้ใน HTML Tag
ตัวอย่างที่ 2
ทดลองสร้างไฟล์ HTML ที่มีโค้ดดังภาพขึ้นมา
ลองเปิดไฟล์ HTML ดังกล่าวด้วย Browser จะพบว่าโค้ดของเราจะถูกจัดการโดย Browser ทำให้มีหน้าตาที่เปลี่ยนแปลงไปเนื่องจาก Browser พบ script Tag ก่อน Browser จึงเปลี่ยนจากการใช้งาน HTML Parser มาใช้ JavaScript Parser และมองว่าตั้งแต่เปิด script Tag จนถึงการปิด script Tag เป็นโค้ด JavaScript และหลังจากการปิด script Tag เป็นข้อความ จึงตัดโค้ดหลังการปิด script Tag ไปไว้ภายใน body Tag จากนั้นจึงใส่โค้ดทั้งหมดเอาไว้ใน HTML Tag
จากทั้งสองตัวอย่างเราพบว่าการใช้งาน HTML Parser และ JavaScript Parser นั้นทำให้ Browser แก้ไข HTML โค้ดที่เขียนมาไม่ถูกต้อง ด้วยวิธีที่ต่างกัน
ตัวอย่างที่ 3
Payload Mutation XSS ของ Masato Kinugawa ทดลองสร้างไฟล์ HTML ที่มีโค้ดดังภาพขึ้นมา
รู้จักกับ noscript Tag
HTML Document for noscript Tag: https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element
จาก html spec จะพบว่า noscript Tag จะมีการทำงานที่แตกต่างกันตามการเปิด/ปิด การใช้งาน script
เมื่อนำโค้ดดังกล่าวไปเปิดบน Browser ซึ่ง JavaScript เปิดใช้งาน พบว่ามีการตัดโค้ดหลังการเปิด noscript Tag ไปไว้ที่ Body ซึ่งเหมือนกับตัวอย่างที่ 2 แต่ตัวอย่างนี้โค้ดส่วนที่ถูกตัดไปนั้นเป็นโค้ด JavaScript จึงถูก Execute ซึ่งในกรณีนี้เป็นการแสดงกล่องโต้ตอบที่มีข้อความเป็นเลข 1
หากเราต้องการรู้ว่าจะเป็นอย่างไรถ้านำ Payload Mutation XSS ข้างต้นมาใช้งานในกรณีที่ปิดการใช้งาน script เราสามารถทดสอบได้โดยนำ Payload มาใส่ไว้ใน template element ซึ่งใน element นี้ JavaScript ถูกปิดการใช้งาน
เราจะพบว่าโค้ดของเราถูกแก้ไขกลายเป็นตามภาพด้านล่างซึ่งเหมือนกับตัวอย่างที่ 1 คือมีการเพิ่มปิด p Tag และเพิ่มปิด noscript Tag
ทำไมเราถึงสนใจว่าหาก Payload นี้ไปอยู่ที่ที่ไม่มีการใช้งาน script จะหน้าตาเป็นอย่างไร
เราต้องเข้าใจการทำงานของ DOMPurify ซึ่งเป็นตัวกรอง XSS จาก Input ของผู้ใช้งานก่อน
อธิบายง่ายๆคือ DOMPurify จะนำ Input ของผู้ใช้ไปไว้ใน template Tag ซึ่งปิดการใช้งาน JavaScript จากนั้นจึงทำการกรอง Attribute ที่อันตรายต่าง ๆ ออก แล้วจึงนำมาแสดงผลบนหน้าเว็ป
ดังนั้นการที่ noscript Tag ทำงานต่างกันเมื่อเปิด/ปิด script จึงทำให้สามารถหลอก DOMPurify ว่า Input นี้ปลอดภัยจากการตรวจสอบ Input บน template Tag ซึ่งปิดการใช้งาน JavaScript แต่เมื่อนำมาแสดงผลจริง ๆ บน Browser ซึ่งเปิดใช้งาน JavaScript ทำให้ Input นั้นถูกแก้ไขโดย Browser ให้กลายเป็นคำสั่ง JavaScript แทนได้
แล้วทำไมเราต้องสนใจ DOMPurify ด้วย Payload Mutation XSS ของ Masato Kinugawa นั้นถูกนำไปใช้อย่างไร
สามารถเข้าไปดูได้ที่ Channel LiveOverflow หรือที่ลิงก์ด้านล่างเลยครับ
