นโยบายรักษาความปลอดภัยเนื้อหา (CSP) ช่วยให้มั่นใจว่าเจ้าของเว็บไซต์จะเชื่อถือเนื้อหาทั้งหมดที่โหลดในหน้า CSP ช่วยลดการโจมตีแบบ Cross-site Scripting (XSS) เนื่องจากสามารถบล็อกสคริปต์ที่ไม่ปลอดภัยที่ผู้โจมตีแทรกเข้ามาได้ อย่างไรก็ตาม คุณสามารถข้าม CSP ได้อย่างง่ายดายหากไม่เข้มงวดพอ ดูข้อมูลเพิ่มเติมได้ที่ลด Cross-site Scripting (XSS) ด้วยนโยบายรักษาความปลอดภัยเนื้อหา (CSP) ที่เข้มงวด Lighthouse รวบรวม CSP ที่บังคับใช้ในเอกสารหลัก และรายงานปัญหาจาก CSP Evaluator หากข้ามได้
แนวทางปฏิบัติที่จำเป็นสำหรับ 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 หรือแฮชเพื่อเลี่ยงการข้ามรายการที่อนุญาต
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 หรือแฮช รวมทั้งใช้ "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 นอกจากนี้ เมตาแท็ก CSP ยังไม่รองรับ frame-ancestors, sandbox และการรายงาน
ตรวจสอบว่า 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 จริง