Cross-site Scripting (XSS) ความสามารถในการแทรกสคริปต์ที่เป็นอันตรายลงในเว็บแอปถือเป็นหนึ่งใน ช่องโหว่ด้านความปลอดภัยที่ใหญ่ที่สุดของเว็บ มากว่า 10 ปี
นโยบายรักษาความปลอดภัยเนื้อหา (CSP)
เป็นการรักษาความปลอดภัยอีกชั้นหนึ่งที่ช่วยลด XSS วิธีกำหนดค่า CSP
เพิ่มส่วนหัว HTTP ของ Content-Security-Policy
ลงในหน้าเว็บและตั้งค่าที่
ควบคุมทรัพยากรที่ User Agent โหลดได้สำหรับหน้าเว็บนั้น
หน้านี้จะอธิบายวิธีใช้ CSP ที่อิงตาม nonces หรือแฮชเพื่อบรรเทา XSS แทน CSP ที่อนุญาตตามโฮสต์ซึ่งใช้กันโดยทั่วไปซึ่งมักจะออกจากหน้าเว็บ แสดง XSS เนื่องจากอาจถูกข้ามในการกำหนดค่าส่วนใหญ่
คำศัพท์สำคัญ: nonce คือตัวเลขสุ่มที่ใช้เพียงครั้งเดียวเท่านั้นที่คุณสามารถใช้เพื่อทำเครื่องหมาย
แท็ก <script>
ว่าเชื่อถือได้
คำศัพท์สำคัญ: ฟังก์ชันแฮชเป็นฟังก์ชันทางคณิตศาสตร์ที่แปลงอินพุต
เป็นค่าตัวเลขที่บีบอัดซึ่งเรียกว่า hash คุณใช้แฮชได้
(เช่น SHA-256) เพื่อทำเครื่องหมายในหน้า
แท็ก <script>
ว่าเชื่อถือได้
นโยบายรักษาความปลอดภัยเนื้อหาที่อ้างอิง nonces หรือ Hash มักเรียกกันว่าเป็น CSP ที่เข้มงวด เมื่อแอปพลิเคชันใช้ CSP ที่เข้มงวด ผู้โจมตีที่พบว่า HTML ข้อบกพร่องในการแทรกมักไม่สามารถใช้เพื่อบังคับให้เบราว์เซอร์ทำงาน สคริปต์ที่เป็นอันตรายในเอกสารที่มีช่องโหว่ เพราะ CSP ที่เข้มงวดเท่านั้น อนุญาตสคริปต์หรือสคริปต์ที่แฮชซึ่งมีค่า Nonce ที่ถูกต้อง ดังนั้นผู้โจมตีจึงไม่สามารถเรียกใช้สคริปต์ได้ถ้าไม่ทราบค่า Nonce ที่ถูกต้อง สำหรับคำตอบหนึ่งๆ
เหตุใดคุณจึงควรใช้ CSP ที่เข้มงวด
หากเว็บไซต์มี CSP ที่มีลักษณะคล้ายกับ script-src www.googleapis.com
อยู่แล้ว
วิธีนี้อาจไม่มีประสิทธิภาพสำหรับข้ามเว็บไซต์ CSP ประเภทนี้เรียกว่า
CSP ที่อนุญาต ต้องมีการปรับแต่งอย่างมากและ
หลบเลี่ยงได้โดยผู้โจมตี
CSP ที่เข้มงวดซึ่งอิงตามการเข้ารหัสหรือแฮชที่ไม่เข้ารหัสจะช่วยหลีกเลี่ยงหลุมพรางเหล่านี้
โครงสร้าง CSP ที่เข้มงวด
นโยบายรักษาความปลอดภัยเนื้อหาที่เข้มงวดขั้นพื้นฐานจะใช้การตอบกลับ HTTP รายการใดรายการหนึ่งต่อไปนี้ ส่วนหัว:
CSP ที่ไม่ใช่แบบเข้มงวด
Content-Security-Policy:
script-src 'nonce-{RANDOM}' 'strict-dynamic';
object-src 'none';
base-uri 'none';
![](https://web.dev/static/articles/strict-csp/image/er4BaGCJzBwDaESFKfZd.jpg?authuser=1&hl=th)
CSP ที่เข้มงวดที่ใช้แฮช
Content-Security-Policy:
script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
object-src 'none';
base-uri 'none';
พร็อพเพอร์ตี้ต่อไปนี้ทำให้ CSP มีลักษณะแบบนี้ "เข้มงวด" ดังนั้นจึงปลอดภัยด้วย
- โดยใช้ nonces
'nonce-{RANDOM}'
หรือแฮช'sha256-{HASHED_INLINE_SCRIPT}'
เพื่อระบุว่าแท็ก<script>
ใดที่นักพัฒนาของเว็บไซต์เชื่อถือให้เรียกใช้ เบราว์เซอร์ของผู้ใช้ - ตั้งค่า
'strict-dynamic'
เพื่อลดความจำเป็นในการติดตั้งใช้งาน CSP แบบ Nonce หรือแฮชโดยอัตโนมัติ อนุญาตให้เรียกใช้สคริปต์ที่สคริปต์ที่เชื่อถือได้สร้างขึ้น ยัง เลิกบล็อกการใช้ไลบรารีและวิดเจ็ต JavaScript ของบุคคลที่สามส่วนใหญ่ - บริการนี้ไม่ได้อิงตามรายการ URL ที่อนุญาต ดังนั้นจึงไม่ได้รับผลกระทบจาก การข้าม CSP ทั่วไป
- โหมดนี้จะบล็อกสคริปต์ในหน้าที่ไม่น่าเชื่อถือ เช่น เครื่องจัดการเหตุการณ์ในบรรทัดหรือ
javascript:
URI - จำกัดไม่ให้
object-src
ปิดใช้ปลั๊กอินที่เป็นอันตราย เช่น Flash - จะจำกัด
base-uri
เพื่อบล็อกการแทรกแท็ก<base>
วิธีนี้จะช่วย ผู้โจมตีจากการเปลี่ยนตำแหน่งของสคริปต์ที่โหลดจาก URL สัมพัทธ์
ใช้ CSP ที่เข้มงวด
หากต้องการใช้ CSP ที่เข้มงวด คุณต้องทำดังนี้
- เลือกว่าแอปพลิเคชันควรตั้งค่า CSP แบบ Nonce หรือแฮช
- คัดลอก CSP จากส่วนโครงสร้าง CSP ที่เข้มงวดแล้วตั้งค่า เป็นส่วนหัวการตอบกลับในแอปพลิเคชันของคุณ
- เปลี่ยนโครงสร้างภายในโค้ดของเทมเพลต HTML และโค้ดฝั่งไคลเอ็นต์เพื่อนำรูปแบบที่ ไม่สามารถใช้ร่วมกับ CSP
- ทำให้ CSP ใช้งานได้
คุณสามารถใช้ Lighthouse
(เวอร์ชัน 7.3.0 และสูงกว่าพร้อมแฟล็ก --preset=experimental
) การตรวจสอบแนวทางปฏิบัติแนะนำ
ตลอดกระบวนการนี้เพื่อตรวจสอบว่าเว็บไซต์ของคุณมี CSP หรือไม่ และ
เข้มงวดพอที่จะใช้กับ XSS
![ประภาคาร
รายงานคำเตือนว่าไม่พบ CSP ในโหมดบังคับใช้](https://web.dev/static/articles/strict-csp/image/lighthouse-report-warning-74f66e2ef76dc.png?authuser=1&hl=th)
ขั้นตอนที่ 1: ตัดสินใจว่าต้องใช้ CSP แบบ Nonce หรือแฮช
การทำงานของ CSP ที่เข้มงวดทั้ง 2 ประเภทมีดังนี้
CSP แบบ Nonce
เมื่อใช้ CSP ที่อิงค่า Nonce คุณจะสร้างตัวเลขแบบสุ่มขณะรันไทม์ แล้วรวมไว้ใน CSP ของคุณ และเชื่อมโยงกับแท็กสคริปต์ทุกแท็กในหน้าเว็บของคุณ ผู้โจมตี ไม่สามารถรวมหรือเรียกใช้สคริปต์ที่เป็นอันตรายในหน้าเว็บของคุณได้ เนื่องจากจะต้อง ทายหมายเลขสุ่มที่ถูกต้องสำหรับสคริปต์นั้น วิธีนี้ใช้ได้ผลดีในกรณีที่หมายเลข ไม่สามารถคาดเดาได้ และจะได้รับการสร้างขึ้นใหม่ในช่วงรันไทม์สำหรับคำตอบทุกครั้ง
ใช้ CSP แบบ Nonce สำหรับหน้า HTML ที่แสดงผลบนเซิร์ฟเวอร์ สำหรับหน้าเหล่านี้ คุณสามารถสร้างตัวเลขสุ่มใหม่สำหรับทุกคำตอบ
CSP ที่อิงตามแฮช
สำหรับ CSP ที่ใช้แฮช ระบบจะเพิ่มแฮชของแท็กสคริปต์ในหน้าทุกแท็กลงใน CSP แต่ละสคริปต์มีแฮชต่างกัน ผู้โจมตีจะรวมหรือเรียกใช้เครื่องมือที่เป็นอันตรายไม่ได้ ในหน้าเว็บของคุณ เพราะแฮชของสคริปต์นั้นต้องอยู่ใน CSP จะทำงาน
ใช้ CSP ที่อิงตามแฮชสำหรับหน้า HTML ที่แสดงแบบคงที่ หรือหน้าที่ต้อง แคช ตัวอย่างเช่น คุณสามารถใช้ CSP ที่อิงตามแฮชสำหรับเว็บหน้าเดียว แอปพลิเคชันที่สร้างด้วยกรอบการทำงาน เช่น Angular, React หรืออื่นๆ ที่ แสดงแบบคงที่โดยไม่มีการแสดงผลฝั่งเซิร์ฟเวอร์
ขั้นตอนที่ 2: กำหนด CSP ที่เข้มงวดและเตรียมสคริปต์
เมื่อตั้งค่า CSP คุณจะมี 3 ตัวเลือกดังนี้
- โหมดรายงานเท่านั้น (
Content-Security-Policy-Report-Only
) หรือโหมดการบังคับใช้ (Content-Security-Policy
) ในโหมดรายงานเท่านั้น CSP จะไม่บล็อก ทรัพยากรมากขึ้น เพื่อให้ไซต์ไม่ทำงาน แต่คุณเห็นข้อผิดพลาดและ รายงานใดๆ ก็ตามที่อาจถูกบล็อก ในระดับท้องถิ่น เมื่อคุณ การตั้งค่า CSP ของคุณ สิ่งนี้ไม่ใช่เรื่องสำคัญ เพราะทั้ง 2 โหมดจะแสดง ในคอนโซลเบราว์เซอร์ หากมีสิ่งใด โหมดการบังคับใช้จะช่วยคุณค้นหาได้ ทรัพยากรที่ CSP ฉบับร่างได้บล็อก เนื่องจากการบล็อกทรัพยากรอาจทำให้ ดูเหมือนไม่ได้อัปเดต โหมดรายงานเท่านั้นจะมีประโยชน์มากที่สุดในขั้นตอนนี้ (ดูขั้นตอนที่ 5) - ส่วนหัวหรือแท็ก HTML
<meta>
สําหรับการพัฒนาในเครื่อง แท็ก<meta>
อาจมีค่ามากกว่า ซึ่งสะดวกในการปรับแต่ง CSP และดูผลกระทบที่มีต่อเว็บไซต์ได้อย่างรวดเร็ว อย่างไรก็ตาม- เมื่อทำให้ CSP ใช้งานได้จริงในภายหลัง เราขอแนะนำให้ตั้งค่าเป็น ส่วนหัว HTTP
- หากคุณต้องการตั้งค่า CSP ในโหมดรายงานเท่านั้น คุณจะต้องตั้งค่า CSP เป็น เนื่องจากเมตาแท็ก CSP ไม่รองรับโหมดรายงานเท่านั้น
ตั้งค่าการตอบกลับ HTTP ของ Content-Security-Policy
ต่อไปนี้
ส่วนหัวในแอปพลิเคชันของคุณ
Content-Security-Policy: script-src 'nonce-{RANDOM}' 'strict-dynamic'; object-src 'none'; base-uri 'none';
สร้าง Nonce สำหรับ CSP
Nonce คือหมายเลขสุ่มที่ใช้เพียงครั้งเดียวต่อการโหลดหน้าเว็บ ค่าที่ได้จากการสุ่ม CSP จะลด XSS ได้ก็ต่อเมื่อผู้โจมตีคาดเดาค่า Nonce ไม่ได้ ต Nonce ของ CSP ต้องเป็น
- ค่าแบบสุ่มที่มีการเข้ารหัสที่รัดกุม (ถ้าจะให้ดีควรมีความยาว 128 บิตขึ้นไป)
- สร้างใหม่สําหรับทุกคําตอบ
- เข้ารหัส Base64
ต่อไปนี้คือตัวอย่างบางส่วนของวิธีเพิ่ม Nonce ของ CSP ในเฟรมเวิร์กฝั่งเซิร์ฟเวอร์
- Django (งูหลาม)
- Express (JavaScript):
const app = express(); app.get('/', function(request, response) { // Generate a new random nonce value for every response. const nonce = crypto.randomBytes(16).toString("base64"); // Set the strict nonce-based CSP response header const csp = `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`; response.set("Content-Security-Policy", csp); // Every <script> tag in your application should set the `nonce` attribute to this value. response.render(template, { nonce: nonce }); });
เพิ่มแอตทริบิวต์ nonce
ลงในองค์ประกอบ <script>
เมื่อใช้ CSP แบบ Nonce เอลิเมนต์ <script>
ทั้งหมดจะต้อง
มีแอตทริบิวต์ nonce
ที่ตรงกับค่าที่ได้จากการสุ่ม
ที่ระบุในส่วนหัวของ CSP สคริปต์ทั้งหมดสามารถมี
Nonce ขั้นตอนแรกคือให้เพิ่มแอตทริบิวต์เหล่านี้ลงในสคริปต์ทั้งหมดเพื่อให้
ซึ่ง CSP อนุญาต
ตั้งค่าการตอบกลับ HTTP ของ Content-Security-Policy
ต่อไปนี้
ส่วนหัวในแอปพลิเคชันของคุณ
Content-Security-Policy: script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic'; object-src 'none'; base-uri 'none';
สำหรับสคริปต์ในหน้าหลายรายการ ไวยากรณ์จะเป็นดังนี้
'sha256-{HASHED_INLINE_SCRIPT_1}' 'sha256-{HASHED_INLINE_SCRIPT_2}'
โหลดสคริปต์ที่มีแหล่งที่มาแบบไดนามิก
เนื่องจากแฮช CSP จะทำได้ในเบราว์เซอร์ กับสคริปต์ในหน้าเท่านั้น คุณต้องโหลดสคริปต์ของบุคคลที่สามทั้งหมดแบบไดนามิกโดยใช้สคริปต์ในหน้า แฮชสําหรับสคริปต์ที่มีแหล่งที่มาไม่รองรับการใช้งานร่วมกันในเบราว์เซอร์ต่างๆ
![](https://web.dev/static/articles/strict-csp/image/B2YsfJDYw8PRI6kJI7Bs.jpg?authuser=1&hl=th)
<script> var scripts = [ 'https://example.org/foo.js', 'https://example.org/bar.js']; scripts.forEach(function(scriptUrl) { var s = document.createElement('script'); s.src = scriptUrl; s.async = false; // to preserve execution order document.head.appendChild(s); }); </script>
{HASHED_INLINE_SCRIPT}
ตัวยึดตําแหน่ง หากต้องการลดจำนวนแฮช คุณสามารถผสานทั้งหมดในบรรทัด
เป็นสคริปต์เดียวได้ หากต้องการดูการใช้งานจริง โปรดดู
ตัวอย่าง
และโค้ด
<script src="https://example.org/foo.js"></script> <script src="https://example.org/bar.js"></script>
ข้อควรพิจารณาเกี่ยวกับการโหลดสคริปต์
ตัวอย่างสคริปต์ในหน้าจะเพิ่ม s.async = false
เพื่อให้
ที่ foo
จะดำเนินการก่อน bar
แม้ว่า
bar
โหลดก่อน ในข้อมูลโค้ดนี้ s.async = false
ไม่บล็อกโปรแกรมแยกวิเคราะห์ขณะโหลดสคริปต์ เนื่องจากสคริปต์
แบบไดนามิก โปรแกรมแยกวิเคราะห์จะหยุดเฉพาะเมื่อสคริปต์ทำงาน
กับสคริปต์ async
รายการ แต่ด้วยข้อมูลโค้ดนี้
ข้อควรทราบมีดังนี้
-
สคริปต์ 1 หรือทั้งคู่อาจทำงานก่อนที่เอกสารจะเสร็จสิ้น
กำลังดาวน์โหลด ถ้าต้องการให้เอกสารพร้อมก่อนถึงเวลา
รันสคริปต์แล้ว โปรดรอให้ เหตุการณ์
DOMContentLoaded
ปรากฏก่อน คุณจะเพิ่มสคริปต์ต่อท้าย หากการดำเนินการนี้ทำให้เกิดปัญหาด้านประสิทธิภาพเนื่องจาก สคริปต์ไม่เริ่มดาวน์โหลดเร็วพอ ให้ใช้โหลดแท็กล่วงหน้าก่อนในหน้าเว็บ -
defer = true
ไม่ทำอะไรเลย ถ้าต้องการแบบนั้น ให้เรียกใช้สคริปต์ด้วยตนเองเมื่อจำเป็น
ขั้นตอนที่ 3: เปลี่ยนโครงสร้างภายในโค้ดของเทมเพลต HTML และโค้ดฝั่งไคลเอ็นต์
เครื่องจัดการเหตุการณ์ในบรรทัด (เช่น onclick="…"
, onerror="…"
) และ URI ของ JavaScript
(<a href="javascript:…">
) เพื่อเรียกใช้สคริปต์ ซึ่งหมายความว่า
ผู้โจมตีที่พบข้อบกพร่อง XSS สามารถแทรก HTML ประเภทนี้และเรียกใช้
JavaScript CSP ที่ใช้ค่า Nonce หรือแฮชไม่อนุญาตให้ใช้มาร์กอัปประเภทนี้
หากเว็บไซต์ใช้รูปแบบเหล่านี้ คุณจะต้องเปลี่ยนโครงสร้างภายในโค้ดให้ปลอดภัยยิ่งขึ้น
ทางเลือก
หากเปิดใช้ CSP ในขั้นตอนก่อนหน้า คุณจะเห็นการละเมิด CSP ใน คอนโซลนี้ทุกครั้งที่ CSP บล็อกรูปแบบที่ใช้ร่วมกันไม่ได้
![รายงานการละเมิด CSP ในคอนโซลของนักพัฒนาซอฟต์แวร์ Chrome](https://web.dev/static/articles/strict-csp/image/csp-violation-reports-th-ff599b24b17be.jpg?authuser=1&hl=th)
ในกรณีส่วนใหญ่ การแก้ไขจะไม่ซับซ้อน:
เปลี่ยนโครงสร้างของเครื่องจัดการเหตุการณ์ในบรรทัด
<span id="things">A thing.</span> <script nonce="${nonce}"> document.getElementById('things').addEventListener('click', doThings); </script>
<span onclick="doThings();">A thing.</span>
เปลี่ยนโครงสร้างภายใน URI javascript:
ใหม่
<a id="foo">foo</a> <script nonce="${nonce}"> document.getElementById('foo').addEventListener('click', linkClicked); </script>
<a href="javascript:linkClicked()">foo</a>
นำ eval()
ออกจาก JavaScript ของคุณ
หากแอปพลิเคชันใช้ eval()
เพื่อแปลงการเรียงอันดับสตริง JSON เป็น JS
คุณควรเปลี่ยนโครงสร้างภายในโค้ดของอินสแตนซ์ดังกล่าวเป็น JSON.parse()
ซึ่งเป็น
เร็วขึ้น
หากนําการใช้งาน eval()
ทั้งหมดออกไม่ได้ คุณจะยังตั้งค่าตาม Nonce แบบเข้มงวดได้
CSP แต่คุณต้องใช้คีย์เวิร์ด 'unsafe-eval'
CSP ซึ่งทำให้
นโยบายมีความปลอดภัยน้อยกว่าเล็กน้อย
คุณดูตัวอย่างเหล่านี้และตัวอย่างการเปลี่ยนโครงสร้างภายในโค้ดได้ใน CSP ที่เข้มงวดนี้ Codelab:
ขั้นตอนที่ 4 (ไม่บังคับ): เพิ่มเบราว์เซอร์สำรองเพื่อรองรับเบราว์เซอร์เวอร์ชันเก่า
หากคุณต้องการรองรับเบราว์เซอร์เวอร์ชันเก่า ให้ทำดังนี้
- การใช้
strict-dynamic
จำเป็นต้องมีการเพิ่มhttps:
เป็นทางเลือกสำหรับก่อนหน้านี้ Safari เวอร์ชันต่างๆ เมื่อคุณทำดังนี้- เบราว์เซอร์ทั้งหมดที่รองรับ
strict-dynamic
จะไม่สนใจhttps:
สำรอง วิธีนี้ไม่ได้ลดคุณภาพของนโยบาย - ในเบราว์เซอร์รุ่นเก่า สคริปต์ที่มาจากภายนอกจะโหลดได้ต่อเมื่อสคริปต์มาจาก
ต้นทาง HTTPS วิธีนี้มีความปลอดภัยน้อยกว่า CSP ที่เข้มงวด
ป้องกันสาเหตุทั่วไปของ XSS บางอย่าง เช่น การแทรก URI
javascript:
- เบราว์เซอร์ทั้งหมดที่รองรับ
- เพื่อให้สามารถทำงานร่วมกับเบราว์เซอร์เวอร์ชันเก่ามาก (มากกว่า 4 ปี) คุณสามารถเพิ่ม
unsafe-inline
เป็นตัวสำรอง เบราว์เซอร์ล่าสุดทั้งหมดจะไม่สนใจunsafe-inline
หากมี Nonce หรือแฮชของ CSP
Content-Security-Policy:
script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
ขั้นตอนที่ 5: ทำให้ CSP ใช้งานได้
หลังจากยืนยันว่า CSP ของคุณไม่ได้บล็อกสคริปต์ที่ถูกต้องใน สภาพแวดล้อมการพัฒนาซอฟต์แวร์ภายในของคุณเอง คุณสามารถทำให้ CSP ใช้งานได้ในการทดลองใช้ สภาพแวดล้อมของเวอร์ชันที่ใช้งานจริง:
- (ไม่บังคับ) ทำให้ CSP ใช้งานได้ในโหมดรายงานเท่านั้นโดยใช้
ส่วนหัว
Content-Security-Policy-Report-Only
โหมดรายงานเท่านั้นมีประโยชน์ ทดสอบการเปลี่ยนแปลงที่อาจส่งผลกับส่วนอื่นอย่าง CSP ใหม่ในเวอร์ชันที่ใช้งานจริงก่อน เริ่มบังคับใช้ข้อจำกัดของ CSP ในโหมดรายงานเท่านั้น CSP จะไม่ ส่งผลต่อลักษณะการทำงานของแอป แต่เบราว์เซอร์ยังคงสร้างข้อผิดพลาดของคอนโซล และรายงานการละเมิดเมื่อพบรูปแบบที่เข้ากันไม่ได้กับ CSP เพื่อให้คุณดูได้ว่าปัญหาเกิดจากอะไรสำหรับผู้ใช้ปลายทาง สำหรับข้อมูลเพิ่มเติม โปรดดูข้อมูลใน Reporting API - เมื่อคุณมั่นใจว่า CSP จะไม่ทำให้เว็บไซต์เสียหายสำหรับผู้ใช้ปลายทาง
ทำให้ CSP ใช้งานได้โดยใช้ส่วนหัวการตอบกลับ
Content-Security-Policy
พ ขอแนะนำให้ตั้งค่า CSP โดยใช้ส่วนหัว HTTP จากฝั่งเซิร์ฟเวอร์เพราะ ปลอดภัยกว่าแท็ก<meta>
หลังจากทำขั้นตอนนี้เสร็จแล้ว CSP จะเริ่มต้น การปกป้องแอปของคุณจาก XSS
ข้อจำกัด
โดยทั่วไป CSP ที่เข้มงวดจะช่วยเพิ่มความปลอดภัยอีกชั้น ซึ่งจะช่วย
ลด XSS ในกรณีส่วนใหญ่ CSP จะลดพื้นที่ในการโจมตีลงอย่างมาก
การปฏิเสธรูปแบบที่เป็นอันตราย เช่น URI ของ javascript:
อย่างไรก็ตาม ทั้งนี้ขึ้นอยู่กับประเภท
ของ CSP ที่คุณใช้อยู่ (nonces, แฮชที่มีหรือไม่มี 'strict-dynamic'
)
คือกรณีที่ CSP ไม่ปกป้องแอปของคุณด้วยเช่นกัน
- หากคุณระบุสคริปต์ แต่มีการแทรกเข้าไปในเนื้อหาโดยตรงหรือ
พารามิเตอร์
src
ขององค์ประกอบ<script>
ดังกล่าว - หากมีการแทรกลงในตำแหน่งของสคริปต์ที่สร้างขึ้นแบบไดนามิก
(
document.createElement('script')
) รวมถึงฟังก์ชันต่างๆ ของไลบรารี ที่สร้างโหนด DOMscript
โหนดตามค่าของอาร์กิวเมนต์ ช่วงเวลานี้ มี API ทั่วไปบางส่วน เช่น.html()
ของ jQuery รวมถึง.get()
และ.post()
ใน jQuery < 3.0 - หากมีการแทรกเทมเพลตในแอปพลิเคชัน AngularJS แบบเก่า ผู้โจมตี ที่สามารถแทรกลงในเทมเพลต AngularJS สามารถใช้เพื่อ สั่งการ JavaScript ที่กำหนดเอง
- หากนโยบายมี
'unsafe-eval'
การแทรกในeval()
setTimeout()
และ API อื่นๆ ที่ไม่ค่อยใช้งาน
นักพัฒนาซอฟต์แวร์และวิศวกรด้านความปลอดภัยควรให้ความสำคัญกับเรื่องนี้เป็นพิเศษ ระหว่างการตรวจสอบโค้ดและการตรวจสอบความปลอดภัย คุณสามารถดูรายละเอียดเพิ่มเติมเกี่ยวกับ ในกรณีเหล่านี้ในนโยบายรักษาความปลอดภัยเนื้อหา: การสื่อสารที่ประสบความสำเร็จระหว่างการปิดช่องโหว่และการบรรเทาปัญหา
อ่านเพิ่มเติม
- CSP ตายแล้ว แค่ CSP เล่นนาน เกี่ยวกับความไม่ปลอดภัยของรายการที่อนุญาตพิเศษและอนาคตของนโยบายรักษาความปลอดภัยเนื้อหา
- ผู้ประเมิน CSP
- การประชุม LocoMoco: นโยบายรักษาความปลอดภัยเนื้อหา - ความวุ่นวายที่ประสบความสำเร็จระหว่างการปิดช่องโหว่และการบรรเทาปัญหา
- พูดคุยเรื่อง Google I/O: การรักษาความปลอดภัยเว็บแอปด้วยฟีเจอร์แพลตฟอร์มสมัยใหม่