XSS ผ่าน innerHTML และวิธีป้องกัน

การกำหนด el.innerHTML = userInput จะวิเคราะห์สตริงนั้นเป็น HTML หาก userInput มีแท็ก <script> หรือแอตทริบิวต์ตัวจัดการเหตุการณ์ (onclick, onerror) เบราว์เซอร์จะตีความแท็กเหล่านั้นและเรียกใช้โค้ดที่ผู้โจมตีควบคุมบนหน้าเว็บ

โค้ดใดก็ตามที่นำข้อมูลผู้ใช้ไปแทรกใน HTML — ไม่ว่าจะเป็นแม่แบบฝั่งเซิร์ฟเวอร์หรือการแสดงผลฝั่งไคลเอนต์ — ล้วนเสี่ยงต่อ XSS หากไม่ได้ทำการหลีกข้อมูล แอปแบบหน้าเดียวที่สร้าง innerHTML จากการตอบกลับของส่วนต่อประสานโปรแกรมประยุกต์มีความเสี่ยงเป็นพิเศษเมื่อการตอบกลับเหล่านั้นมีเนื้อหาจากผู้ใช้

ชื่อผู้ใช้ "Bob<img src=x onerror=alert(1)>" ที่กำหนดผ่าน div.innerHTML = `Welcome, ${user}` จะเรียกใช้ alert(1) เมื่อ img โหลดไม่สำเร็จ ข้อมูลเดียวกันในรูปข้อความธรรมดา (ผ่าน textContent) ไม่ก่ออันตราย — เบราว์เซอร์จะเห็นเพียงอักขระ ไม่ใช่แท็ก

textContent กำหนดเฉพาะข้อความ — อักขระพิเศษของ HTML จะแสดงเป็นอักขระตามตัวอักษรและไม่กลายเป็นแท็ก นี่เป็นเครื่องมือที่เหมาะสมใน 90% ของกรณี เปลี่ยนไปใช้ innerHTML เฉพาะเมื่อจำเป็นต้องแสดงมาร์กอัปจริง ๆ ไม่ใช่เพียงข้อความ

หากต้องการสร้างองค์ประกอบพร้อมข้อมูลผู้ใช้ ให้สร้างด้วย createElement และ textContent: const li = document.createElement("li"); li.textContent = name; ul.appendChild(li); ผลลัพธ์มีโครงสร้างเหมือนกับ innerHTML ทุกประการ แต่ปลอดภัยจาก XSS ตั้งแต่ขั้นตอนการสร้าง

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

หากผู้ใช้ส่งข้อความรูปแบบสมบูรณ์ (เช่น ในเครื่องมือแก้ไขความคิดเห็นหรือการแสดงผลมาร์กดาวน์) ให้ทำความสะอาดก่อนกำหนดค่าให้ innerHTML: el.innerHTML = DOMPurify.sanitize(richHtml) DOMPurify จะลบแท็กและแอตทริบิวต์ที่เป็นอันตราย แต่ยังคงรูปแบบที่ปลอดภัย เช่น <b>, <em> และ <a>

el.insertAdjacentHTML("beforeend", html) จะวิเคราะห์สตริง HTML — มีพื้นผิวการโจมตี XSS แบบเดียวกับ innerHTML ใช้กฎเดียวกัน: ห้ามป้อนข้อมูลผู้ใช้โดยตรง ให้ทำความสะอาดหรือใช้เมธอด DOM เช่นเดียวกันนี้กับ document.write ด้วย แม้ปัจจุบันไม่ควรมีใครใช้แล้ว

React, Vue, Svelte และ Angular จะทำการหลีกข้อความที่นำมาแทรกโดยค่าเริ่มต้น — {name} จึงปลอดภัย เฟรมเวิร์กเหล่านี้มีช่องทางข้ามการป้องกัน (dangerouslySetInnerHTML ใน React และ v-html ใน Vue) ซึ่งมีความเสี่ยงต่อ XSS แบบเดียวกัน ควรใช้เท่าที่จำเป็นและทำความสะอาดข้อมูลก่อน

แม้แต่ค่าของแอตทริบิวต์ก็อาจเป็นช่องทางโจมตีได้: <a href={url}> เมื่อ url="javascript:alert(1)" จะเรียกใช้โค้ดเมื่อถูกคลิก ตรวจสอบรูปแบบโครงแบบของ URL ทีละแบบ (อนุญาตเฉพาะ http:, https:, mailto: และ tel:) ก่อนนำข้อมูลที่ผู้ใช้ป้อนมาใส่ใน href, src หรือแอตทริบิวต์อื่นที่มี URL

เบราว์เซอร์รุ่นใหม่รองรับ Trusted Types: กำหนดค่า CSP ด้วย require-trusted-types-for 'script' แล้ว innerHTML จะปฏิเสธสตริงดิบ — มีเพียงค่าที่หุ้มด้วยนโยบายเท่านั้นที่ผ่านได้ วิธีนี้ทำให้ XSS เป็นไปไม่ได้ด้วยกลไกของ API แทนที่จะอาศัยวินัยของผู้พัฒนา

ไม่มีชั้นใดชั้นหนึ่งเพียงอย่างเดียวที่เพียงพอ ควรใช้หลายวิธีร่วมกัน ได้แก่ ตรวจสอบข้อมูลเข้าที่เซิร์ฟเวอร์ หลบอักขระพิเศษของผลลัพธ์ขณะแสดงผล ใช้ CSP เพื่อบล็อกสคริปต์ที่ถูกแทรก ใช้ประเภทข้อมูลที่เชื่อถือได้เพื่อปฏิเสธสตริงดิบ และตรวจสอบความปลอดภัยสำหรับการใช้ innerHTML ทุกจุด การป้องกันหลายชั้นยังคงรับมือได้แม้ชั้นใดชั้นหนึ่งจะมีข้อผิดพลาด

เหตุใด el.textContent = userInput จึงปลอดภัยจาก XSS ขณะที่ el.innerHTML = userInput เป็นอันตราย

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