XSS ในรีแอ็กต์: dangerouslySetInnerHTML และสคริปต์จากบุคคลที่สาม

React จะเอสเคปค่าทั้งหมดที่แสดงผลผ่าน JSX โดยอัตโนมัติก่อนแทรกค่าลงใน DOM เมื่อเขียน {userInput} ใน JSX React จะเรียกใช้การกำหนดค่าแบบเดียวกับ textContent โดยถือว่าค่านั้นเป็นข้อความ ไม่ใช่ HTML วิธีนี้ช่วยป้องกันการโจมตี XSS ส่วนใหญ่ในแอปพลิเคชัน React ได้โดยค่าเริ่มต้น

dangerouslySetInnerHTML={{ __html: htmlString }} เป็นช่องทางยกเว้นการเอสเคปของ React ที่ข้ามการเอสเคปอัตโนมัติ ชื่อนี้ตั้งใจให้ฟังดูน่ากังวล เพื่อเตือนว่าคุณต้องรับผิดชอบต่อความปลอดภัยของสตริง HTML เอง React จะกำหนดค่าให้กับ innerHTML โดยตรง ซึ่งทำให้ HTML ใด ๆ รวมถึงสคริปต์และตัวจัดการเหตุการณ์ทำงานได้

คุณจำเป็นต้องใช้ dangerouslySetInnerHTML อย่างแท้จริงเมื่อแสดงผล HTML ที่มาจากเครื่องมือแก้ไขข้อความแบบจัดรูปแบบ (เช่น TipTap หรือ Quill), CMS ที่จัดเก็บ HTML หรือเครื่องมือแปลงมาร์กดาวน์เป็น HTML แหล่งข้อมูลเหล่านี้สร้างมาร์กอัป HTML จริงที่ต้องแสดงผลเป็น HTML ไม่ใช่ข้อความที่ถูกเอสเคป

หากสตริง HTML มี <script>stealCookies()</script> หรือ <img src=x onerror="stealData()"> การกำหนดสตริงดังกล่าวให้เป็น innerHTML จะทำให้โค้ดของผู้โจมตีทำงาน เนื้อหาที่ผู้ใช้ส่งมาและถูกส่งตรงไปยัง dangerouslySetInnerHTML โดยไม่ผ่านการทำให้ปลอดภัย ถือเป็นช่องโหว่ XSS ระดับวิกฤต

DOMPurify เป็นตัวกรอง HTML มาตรฐานของอุตสาหกรรมสำหรับเบราว์เซอร์ โดยจะแยกวิเคราะห์สตริง HTML ในบริบทแบบแซนด์บ็อกซ์ ลบองค์ประกอบและแอตทริบิวต์ที่เป็นอันตราย (แท็กสคริปต์ ตัวจัดการเหตุการณ์ และ URL ที่ใช้ javascript:) แล้วส่งคืนสตริง HTML ที่ปลอดภัย การใช้งานคือ DOMPurify.sanitize(dirtyHtml) ก่อนส่งค่าให้กับ dangerouslySetInnerHTML

สคริปต์จากบุคคลที่สาม (การวิเคราะห์ข้อมูล วิดเจ็ตสนทนา เครือข่ายโฆษณา) ทำงานด้วยสิทธิ์เดียวกับ JavaScript ของแอปพลิเคชัน สคริปต์ของบุคคลที่สามที่ถูกเจาะหรือเป็นอันตรายอาจอ่าน document.cookie เข้าถึง localStorage อ่านข้อมูลที่ป้อนในแบบฟอร์ม และส่งคำขอไปยังเซิร์ฟเวอร์ภายนอกได้ทั้งหมดโดยที่ผู้ใช้ไม่ทันสังเกต

นโยบายความปลอดภัยของเนื้อหาเป็นส่วนหัว HTTP ที่ประกาศว่าสคริปต์ใดได้รับอนุญาตให้ทำงาน แม้จะมีการแทรกเพย์โหลด XSS ลงใน DOM แต่ CSP ที่กำหนดค่าอย่างเหมาะสมก็สามารถบล็อกการทำงานของเพย์โหลดได้ด้วยการจำกัดสคริปต์แบบอินไลน์ และอนุญาตเฉพาะแหล่งที่มาของสคริปต์ในรายการอนุญาต CSP เป็นแนวป้องกันชั้นที่สองหลังจากการทำให้ข้อมูลที่ป้อนปลอดภัย

แพ็กเกจ npm เป็นช่องทางการโจมตี XSS ที่เกิดขึ้นได้จริง การพึ่งพาอาจมีโค้ดอันตรายที่ลักลอบส่งออกตัวแปรสภาพแวดล้อมหรือข้อมูลผู้ใช้ เหตุการณ์ node-ipc ในปี 2022 และการถูกเจาะของ ua-parser-js ในปี 2021 แสดงให้เห็นว่าแพ็กเกจที่มีผู้ใช้งานอย่างแพร่หลายอาจถูกยึดและแทรกโค้ดอันตรายได้ ตรวจสอบการพึ่งพาด้วย npm audit และใช้ไฟล์ล็อก

การโจมตี XSS ที่สำเร็จเปิดโอกาสให้ผู้โจมตีขโมยโทเค็น JWT ของผู้ใช้จาก sessionStorage (ส่งโทเค็นไปยังเซิร์ฟเวอร์ที่ผู้โจมตีควบคุม) ดำเนินการในฐานะผู้ใช้ที่ผ่านการยืนยันตัวตน (เรียก API โดยใช้เซสชันของผู้ใช้) แก้ไข DOM เพื่อแสดงเนื้อหาฟิชชิง หรือบันทึกการกดแป้นพิมพ์ทุกครั้งที่ผู้ใช้ทำในแอปพลิเคชัน

API Trusted Types ของเบราว์เซอร์กำหนดให้จุดรับข้อมูลเข้าสู่ DOM ทั้งหมด (innerHTML, eval, script.src) ต้องรับออบเจ็กต์ที่มีชนิดข้อมูลเฉพาะแทนสตริงดิบ วิธีนี้ป้องกันไม่ให้เพย์โหลด XSS ที่อยู่ในรูปสตริงไปถึง DOM ได้ในระดับแพลตฟอร์ม React กำลังพัฒนาไปสู่การรองรับ Trusted Types และ CSP สามารถบังคับใช้ข้อกำหนดนี้ได้

เมื่อเรียกใช้ DOMPurify.sanitize(htmlString) DOMPurify จะทำอะไร

React จะเอสเคปค่า JSX โดยอัตโนมัติ ซึ่งช่วยป้องกัน XSS ส่วนใหญ่ dangerouslySetInnerHTML ข้ามการป้องกันนี้เพื่อแสดงผล HTML ที่จำเป็นต่อการใช้งานจริง ดังนั้นต้องทำให้ข้อมูลที่ป้อนปลอดภัยด้วย DOMPurify ก่อนเสมอ สคริปต์จากบุคคลที่สามและแพ็กเกจ npm ที่ถูกเจาะเป็นช่องทาง XSS จากห่วงโซ่อุปทาน นโยบายความปลอดภัยของเนื้อหาเป็นชั้นป้องกันที่สอง การโจมตี XSS ที่สำเร็จทำให้เกิดการขโมยโทเค็น การสวมรอย และฟิชชิงได้