นโยบายรักษาความปลอดภัยเนื้อหา (CSP) ช่วยให้มั่นใจว่าเจ้าของเว็บไซต์เชื่อถือเนื้อหาที่โหลดในหน้าเว็บ CSP จะช่วยลดการโจมตีด้วย Cross-site Scripting (XSS) เนื่องจากสามารถบล็อกสคริปต์ที่ไม่ปลอดภัยซึ่งผู้โจมตีแทรกเข้ามาได้ อย่างไรก็ตาม CSP สามารถเลี่ยงได้โดยง่ายหากไม่เข้มงวดพอ ดูข้อมูลเพิ่มเติมที่หัวข้อลดความเสี่ยงจาก Cross-site Scripting (XSS) ด้วยนโยบายรักษาความปลอดภัยเนื้อหา (CSP) ที่เข้มงวด Lighthouse จะรวบรวม CSP ที่บังคับใช้ในเอกสารหลัก และรายงานปัญหาจาก CSP Evaluator หากมีการหลบเลี่ยง CSP
แนวทางปฏิบัติที่จำเป็นสำหรับ CSP ที่ไม่สามารถข้ามได้
ใช้แนวทางปฏิบัติต่อไปนี้เพื่อให้แน่ใจว่าไม่มีใครข้าม CSP ได้ หากข้าม CSP ได้ Lighthouse จะแสดงคำเตือนความรุนแรงสูง
CSP กำหนดเป้าหมาย XSS
หากต้องการกำหนดเป้าหมาย XSS CSP ควรมีคำสั่ง script-src, object-src และ base-uri CSP ไม่ควรมีข้อผิดพลาดทางไวยากรณ์ด้วย
script-src และ object-src ช่วยให้หน้าเว็บปลอดภัยจากสคริปต์และปลั๊กอินที่ไม่ปลอดภัยตามลำดับ หรือจะใช้ default-src เพื่อกําหนดค่านโยบายแบบกว้างแทนคําสั่งหลายรายการ ซึ่งรวมถึง script-src และ object-src ก็ได้
base-uri ป้องกันไม่ให้แท็ก <base> ที่ไม่ได้รับอนุญาตแทรก ซึ่งอาจใช้เพื่อเปลี่ยนเส้นทาง URL สัมพัทธ์ทั้งหมด (เช่น สคริปต์) ไปยังโดเมนที่ผู้โจมตีควบคุม
CSP ใช้ nonces หรือ hashes เพื่อหลีกเลี่ยงการข้ามรายการที่อนุญาต
CSP ที่กําหนดค่ารายการที่อนุญาตสําหรับ script-src จะถือว่าการตอบกลับทั้งหมดที่มาจากโดเมนที่เชื่อถือนั้นปลอดภัย และสามารถเรียกใช้เป็นสคริปต์ได้ อย่างไรก็ตาม สมมติฐานนี้ใช้ไม่ได้กับแอปพลิเคชันสมัยใหม่ รูปแบบทั่วไปที่ไม่เป็นอันตรายบางรูปแบบ เช่น การแสดงอินเทอร์เฟซ JSONP และการโฮสต์สำเนาของไลบรารี AngularJS ช่วยให้ผู้โจมตีหลบเลี่ยงข้อจำกัดของ CSP ได้
ในทางปฏิบัติ แม้ว่าผู้เขียนแอปพลิเคชันอาจไม่ทราบว่าผู้โจมตีที่มีข้อบกพร่อง XSS สามารถหลบเลี่ยงscript-srcรายการที่อนุญาตส่วนใหญ่ และการป้องกันการแทรกสคริปต์มีเพียงเล็กน้อย ในทางตรงกันข้าม แนวทางที่อิงตาม Nonce และอิงตามแฮชจะไม่มีปัญหาเหล่านี้ และทำให้การนำนโยบายที่ปลอดภัยยิ่งขึ้นมาใช้และดูแลรักษาได้ง่ายขึ้น
ตัวอย่างเช่น โค้ดนี้ใช้ปลายทาง JSONP ที่โฮสต์ในโดเมนที่เชื่อถือได้เพื่อแทรกสคริปต์ที่ผู้โจมตีควบคุม
CSP:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
CSP ควรอนุญาตสคริปต์แต่ละรายการโดยใช้ nonces หรือ hashes และใช้ "strict-dynamic" แทนรายการที่อนุญาตเพื่อหลีกเลี่ยงการหลบเลี่ยง
คำแนะนำเพิ่มเติมสำหรับ CSP ที่ปลอดภัย
ใช้แนวทางปฏิบัติต่อไปนี้เพื่อเพิ่มความปลอดภัยและความสามารถในการใช้งานร่วมกัน หาก CSP ไม่ปฏิบัติตามคําแนะนําอย่างใดอย่างหนึ่ง Lighthouse จะแสดงคําเตือนระดับปานกลาง
กำหนดค่าการรายงาน CSP
การกำหนดค่าปลายทางการรายงานจะช่วยตรวจสอบการหยุดทำงาน คุณสามารถตั้งค่าปลายทางการรายงานได้โดยใช้คําสั่ง report-uri หรือ report-to ปัจจุบันเบราว์เซอร์สมัยใหม่บางรุ่นยังไม่รองรับ report-to จึงขอแนะนำให้ใช้ทั้ง 2 รายการหรือใช้เพียง report-uri
หากเนื้อหาละเมิด CSP เบราว์เซอร์จะส่งรายงานไปยังปลายทางที่กำหนดค่าไว้ ตรวจสอบว่าคุณได้กำหนดค่าแอปพลิเคชันที่ปลายทางนี้ให้จัดการรายงานเหล่านี้แล้ว
กําหนด CSP ในส่วนหัว HTTP
คุณกำหนด CSP ในเมตาแท็กได้ดังนี้
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
อย่างไรก็ตาม คุณควรกำหนด CSP ในส่วนหัวการตอบกลับ HTTP หากทำได้ แทรกก่อนเมตาแท็กจะข้าม CSP นอกจากนี้ ระบบยังไม่รองรับ frame-ancestors, sandbox และการรายงานใน CSP ของเทมาต็ก
ตรวจสอบว่า CSP ใช้งานย้อนหลังได้
เบราว์เซอร์บางรายการไม่รองรับ nonces/hashes ของ CSP เราจึงขอแนะนำให้เพิ่ม unsafe-inline ไว้เป็นทางเลือกสำรองสำหรับเบราว์เซอร์ที่ไม่เป็นไปตามข้อกำหนด หากเบราว์เซอร์รองรับ nonces/hashes ระบบจะไม่สนใจ unsafe-inline
ในทํานองเดียวกัน เบราว์เซอร์บางรุ่นก็ไม่รองรับ strict-dynamic เราขอแนะนำให้ตั้งค่ารายการที่อนุญาตเป็นทางเลือกสําหรับเบราว์เซอร์ที่ไม่เป็นไปตามข้อกําหนด ระบบจะไม่สนใจรายการที่อนุญาตในเบราว์เซอร์ที่รองรับ strict-dynamic
วิธีพัฒนา CSP ที่เข้มงวด
ด้านล่างนี้คือตัวอย่างการใช้ CSP ที่เข้มงวดกับนโยบายที่อิงตาม Nonce
CSP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
random123 คือสตริง base64 ที่สร้างขึ้นฝั่งเซิร์ฟเวอร์ทุกครั้งที่โหลดหน้าเว็บ เบราว์เซอร์สมัยใหม่จะไม่สนใจ unsafe-inline และ https: เนื่องจากมี Nonce และ strict-dynamic ดูข้อมูลเพิ่มเติมเกี่ยวกับการนำ CSP แบบเข้มงวดมาใช้ได้ในคู่มือ CSP แบบเข้มงวด
คุณสามารถตรวจสอบ CSP เพื่อหาการหลบเลี่ยงที่อาจเกิดขึ้นได้โดยใช้ Lighthouse และ CSP Evaluator หากต้องการทดสอบ CSP ใหม่โดยไม่เสี่ยงที่จะทำให้หน้าเว็บที่มีอยู่ใช้งานไม่ได้ ให้กำหนด CSP ในโหมดรายงานเท่านั้นโดยใช้ Content-Security-Policy-Report-Only เป็นชื่อส่วนหัว ซึ่งจะส่งการละเมิด CSP ไปยังปลายทางการรายงานที่คุณกําหนดค่าด้วย report-to และ report-uri แต่ไม่บังคับใช้ CSP