ความคิดเห็น: คำนำ: หลังจาก HTML5 ปรากฏขึ้นความปลอดภัยของเครือข่ายได้ดึงดูดความสนใจอย่างกว้างขวางมากขึ้น การปรับปรุงเว็บมีการปรับปรุงอะไรเพื่อความปลอดภัยของเครือข่าย เราจะเผชิญกับการฉ้อโกงทางไซเบอร์และการโจมตีที่อันตรายมากขึ้นได้อย่างไร? บทความต่อไปนี้พูดถึงวิธีแก้ปัญหาล่าสุดของ W3C สำหรับปัญหานี้ หากฉันมีโอกาสในอนาคตฉันจะดำเนินการเนื้อหา HTML5 ใน XSS, P3P, นโยบายที่คล้ายคลึงกัน, CORS (การแบ่งปันทรัพยากรข้ามโดเมน) และ CSP
นโยบายความปลอดภัยของเวิลด์ไวด์เว็บมีรากฐานมาจากนโยบายที่คล้ายคลึงกัน ตัวอย่างเช่นรหัสสามารถเข้าถึงข้อมูลเท่านั้น แต่ไม่มีสิทธิ์การเข้าถึง แต่ละแหล่งถูกแยกออกจากส่วนที่เหลือของเครือข่ายสร้างกล่องทรายที่ปลอดภัยสำหรับนักพัฒนา นี่เป็นทฤษฎีที่สมบูรณ์แบบ แต่ตอนนี้ผู้โจมตีได้พบวิธีที่ฉลาดในการทำลายระบบนี่คือการโจมตีสคริปต์ของ XSS Cross-Site โดยผ่านนโยบายที่คล้ายคลึงกันผ่านเนื้อหาปลอมและการคลิกที่หลอก นี่เป็นปัญหาใหญ่หากผู้โจมตีประสบความสำเร็จในการฉีดรหัสข้อมูลผู้ใช้จำนวนมากจะรั่วไหลออกมา
ตอนนี้เราแนะนำกลยุทธ์การป้องกันความปลอดภัยใหม่และมีประสิทธิภาพเพื่อลดความเสี่ยงนี้ซึ่งเป็นนโยบายความปลอดภัย (CSP)
Source Whitelist
แกนหลักของการโจมตี XSS คือเบราว์เซอร์ไม่สามารถบอกได้ว่าสคริปต์ถูกฉีดโดยบุคคลที่สามหรือเป็นส่วนหนึ่งของแอปพลิเคชันของคุณ ตัวอย่างเช่นปุ่ม Google +1 จะโหลดและเรียกใช้รหัสจาก https://apis.google.com/js/plusone.js แต่เราไม่สามารถคาดหวังที่จะบอกจากรูปภาพบนเบราว์เซอร์ว่ารหัสนั้นมาจาก apis.google.com หรือจาก apis.evil.example.com เบราว์เซอร์ดาวน์โหลดและดำเนินการขอหน้าสำหรับรหัสใด ๆ โดยไม่คำนึงถึงแหล่งที่มา
CSP กำหนดส่วนหัวนโยบายความปลอดภัยของเนื้อหาที่ให้ความสำคัญเพื่อให้คุณสามารถสร้างรายชื่อที่เชื่อถือได้ของแหล่งข้อมูลที่เชื่อถือได้เพื่อให้เบราว์เซอร์ดำเนินการเท่านั้นและแสดงทรัพยากรจากแหล่งข้อมูลเหล่านั้นแทนที่จะไว้วางใจทุกสิ่งที่เซิร์ฟเวอร์ แม้ว่าผู้โจมตีสามารถหาช่องโหว่ในการฉีดสคริปต์ได้ แต่ก็จะไม่ถูกดำเนินการเนื่องจากแหล่งที่มาไม่รวมอยู่ใน Whitelist
ปุ่ม Google +1 ด้านบนเป็นตัวอย่างเพราะเราเชื่อว่า APIS.Google.com มีรหัสที่ถูกต้องเช่นเดียวกับตัวเราเองเราสามารถกำหนดนโยบายที่อนุญาตให้เบราว์เซอร์เรียกใช้สคริปต์จากหนึ่งในสองแหล่งด้านล่าง
เนื้อหา-ความปลอดภัย-นโยบาย: script-src 'self' https://apis.google.com
มันไม่ง่ายมากเหรอ? Script-SRC สามารถควบคุมสิทธิ์ที่เกี่ยวข้องกับสคริปต์สำหรับหน้าเว็บที่ระบุ วิธีนี้เบราว์เซอร์จะดาวน์โหลดและเรียกใช้สคริปต์จากและจากหน้านี้เท่านั้น
เมื่อเรากำหนดนโยบายนี้เบราว์เซอร์จะโยนข้อผิดพลาดเมื่อตรวจพบรหัสที่ฉีด (บันทึกว่าเบราว์เซอร์คืออะไร)
นโยบายความปลอดภัยของเนื้อหาใช้กับทรัพยากรทั่วไปทั้งหมด
แม้ว่าทรัพยากรสคริปต์เป็นความเสี่ยงด้านความปลอดภัยที่ชัดเจนที่สุด CSP ยังมีชุดคำสั่งมากมายที่อนุญาตให้หน้าเว็บควบคุมการโหลดทรัพยากรประเภทต่างๆเช่นประเภทต่อไปนี้:
Content-SRC: จำกัด ประเภทของการเชื่อมต่อ (เช่น XHR, WebSockets และ EventsOrce)
FONT-SRC: ควบคุมแหล่งที่มาของฟอนต์เครือข่าย ตัวอย่างเช่นคุณสามารถใช้แบบอักษรเว็บของ Google ผ่าน font-src https://themes.googleusercontent.com
Frame-SRC: แสดงรายการแหล่งที่มาของเฟรมที่สามารถฝังได้ ตัวอย่างเช่น frame-src https://youtube.com อนุญาตให้ใช้วิดีโอที่ฝังอยู่ใน YouTube เท่านั้น -
IMG-SRC: กำหนดแหล่งที่มาของภาพที่สามารถโหลดได้
Media-SRC: จำกัด แหล่งที่มาของวิดีโอและเสียง
Object-SRC: จำกัด แหล่งที่มาของแฟลชและปลั๊กอินอื่น ๆ
Style-SRC: คล้ายกับ Script-SRC มันใช้งานได้กับไฟล์ CSS เท่านั้น
โดยค่าเริ่มต้นการตั้งค่าทั้งหมดจะเปิดโดยไม่มีข้อ จำกัด ใด ๆ คุณสามารถแยกคำแนะนำหลายคำแนะนำด้วย semicolons แต่คล้ายกับ script-src https: //host1.com; script-src https://host2.com คำสั่งที่สองจะถูกละเว้น วิธีที่ถูกต้องในการเขียนคือ script-src https://host1.com https://host2.com
ตัวอย่างเช่นคุณมีแอปพลิเคชันที่ต้องการโหลดทรัพยากรทั้งหมดจากเครือข่ายการกระจายเนื้อหา (CDN ตัวอย่างเช่น https://cdn.example.net) และรู้ว่าเนื้อหาที่ไม่จำเป็นต้องใช้เฟรมและปลั๊กอินกลยุทธ์ของคุณอาจมีลักษณะเช่นนี้:
เนื้อหา-ความปลอดภัย-นโยบาย: ค่าเริ่มต้น-src https://cdn.example.net; frame-src 'none'; Object-src 'none'
รายละเอียด
ส่วนหัว HTTP ที่ฉันใช้ในตัวอย่างของฉันคือนโยบายความปลอดภัยของเนื้อหา แต่เบราว์เซอร์ที่ทันสมัยได้ให้การสนับสนุนผ่านคำนำหน้า: Firefox ใช้ X-Content-Security-Comicy, WebKit ใช้ X-Webkit-CSP ในอนาคตมันจะค่อยๆเปลี่ยนเป็นมาตรฐานแบบครบวงจร
กลยุทธ์สามารถตั้งค่าสำหรับแต่ละหน้าแตกต่างกันซึ่งให้ความยืดหยุ่นมาก เนื่องจากบางหน้าในเว็บไซต์ของคุณอาจมีปุ่ม Google +1 ในขณะที่อื่น ๆ ไม่ได้
รายการแหล่งที่มาของแต่ละคำสั่งอาจมีความยืดหยุ่น คุณสามารถระบุรูปแบบ (data:, https :) หรือระบุชื่อโฮสต์ในช่วง (example.com ซึ่งตรงกับแหล่งใด ๆ โหมดใด ๆ และพอร์ตใด ๆ บนโฮสต์) หรือระบุ URI ที่สมบูรณ์ (https://example.com:443 โดยเฉพาะโปรโตคอล HTTPS
นอกจากนี้คุณยังสามารถใช้คำหลักสี่คำในรายการต้นทาง:
ไม่มี: คุณอาจคาดหวังว่าจะไม่ตรงกันอะไร
ตัวเอง: เหมือนกับแหล่งที่มาปัจจุบัน แต่ไม่มีโดเมนย่อย
ไม่ปลอดภัย: อนุญาตให้ใช้ JavaScript และ CSS แบบอินไลน์
unsafe-eval: กลไกที่อนุญาตให้ข้อความถึง JS เช่น eval
โปรดทราบว่าคำหลักเหล่านี้จำเป็นต้องได้รับการยกมา
กล่องทราย
มีคำแนะนำอื่นที่ควรค่าแก่การพูดคุยที่นี่: Sandbox มันค่อนข้างไม่สอดคล้องกับคำแนะนำอื่น ๆ ส่วนใหญ่ควบคุมพฤติกรรมที่ใช้ในหน้าแทนที่จะเป็นทรัพยากรที่หน้าสามารถโหลดได้ หากตั้งค่าคุณสมบัตินี้หน้าจะทำตัวเหมือนเฟรมที่มีชุดคุณสมบัติ Sandbox สิ่งนี้มีผลกระทบที่หลากหลายในหน้าเช่นการป้องกันการส่งแบบฟอร์ม ฯลฯ นี่เป็นขอบเขตของบทความนี้เพียงเล็กน้อย แต่คุณสามารถค้นหาข้อมูลเพิ่มเติมในส่วนการตั้งค่าโลโก้ Sandbox ของ HTML5
รหัสอินไลน์ที่เป็นอันตราย
CSP ขึ้นอยู่กับผู้ที่มีรายได้จากแหล่งที่มา แต่ไม่ได้แก้แหล่งที่มาของการโจมตี XSS ที่ใหญ่ที่สุด: การฉีดสคริปต์แบบอินไลน์ หากผู้โจมตีสามารถฉีดแท็กสคริปต์ที่มีรหัสที่เป็นอันตราย (<script> SendMyDatatoEvildotCom (); </script>) เบราว์เซอร์ไม่มีกลไกที่ดีในการแยกแยะแท็กนี้ CSP สามารถแก้ปัญหานี้ได้โดยการห้ามสคริปต์แบบอินไลน์อย่างสมบูรณ์
ข้อห้ามนี้รวมถึงแท็กสคริปต์ที่ฝังอยู่ในสคริปต์ แต่ยังรวมถึงตัวจัดการเหตุการณ์แบบอินไลน์และ Javascrpt: URL คุณต้องใส่เนื้อหาของแท็กสคริปต์ลงในไฟล์ภายนอกและแทนที่ JavaScript: และ <a … onClick = [JavaScript]> ด้วย addEventListener ที่เหมาะสม ตัวอย่างเช่นคุณอาจใส่แบบฟอร์มต่อไปนี้:
<script>
ฟังก์ชั่น doamazingthings () {
การแจ้งเตือน ('คุณน่าทึ่งมาก!');
-
</script>
<button> ฉันน่าทึ่งหรือไม่ </button>
เขียนใหม่ในแบบฟอร์มต่อไปนี้:
<!-amazing.html->
<script src = 'amazing.js'> </script>
<button> ฉันน่าทึ่งหรือไม่ </button>
// amazing.js
ฟังก์ชั่น doamazingthings () {
การแจ้งเตือน ('คุณน่าทึ่งมาก!');
-
document.addeventListener ('domcontentready', function () {
document.getElementById ('น่าทึ่ง')
.AddeventListener ('คลิก', doamazingthings);
-
ไม่ว่าคุณจะใช้ CSP หรือไม่ก็ตามรหัสข้างต้นจริง ๆ แล้วมีข้อได้เปรียบมากขึ้น JavaScript แบบอินไลน์ผสมโครงสร้างและพฤติกรรมอย่างสมบูรณ์คุณไม่ควรทำเช่นนั้น นอกจากนี้ทรัพยากรที่มีการเข้าถึงนั้นง่ายต่อการแคชในเบราว์เซอร์ง่ายขึ้นสำหรับนักพัฒนาที่จะเข้าใจและง่ายต่อการรวบรวมและบีบอัด หากคุณใช้รหัสเผยแพร่คุณจะเขียนโค้ดที่ดีกว่า
รูปแบบอินไลน์จำเป็นต้องประมวลผลในลักษณะเดียวกันทั้งคุณลักษณะสไตล์และแท็กสไตล์จะต้องสกัดลงในสไตล์ชีทภายนอก สิ่งนี้สามารถป้องกันการรั่วไหลของข้อมูลเวทย์มนตร์ทุกชนิด
หากคุณต้องมีสคริปต์และสไตล์แบบอินไลน์คุณสามารถตั้งค่า 'ค่าที่ไม่ปลอดภัยสำหรับแอตทริบิวต์ Script-SRC หรือ Style-SRC แต่อย่าทำเช่นนี้ Forbidding Inline Scripts เป็นการรับประกันความปลอดภัยสูงสุดโดย CSP ในเวลาเดียวกันการห้ามรูปแบบอินไลน์สามารถทำให้แอปพลิเคชันของคุณปลอดภัยและแข็งแกร่งยิ่งขึ้น มันเป็นการแลกเปลี่ยน แต่ก็คุ้มค่า
การประเมิน
แม้ว่าผู้โจมตีจะไม่สามารถฉีดสคริปต์ได้โดยตรงเขาอาจชักชวนแอปพลิเคชันของคุณเพื่อแปลงข้อความที่แทรกเป็นสคริปต์ที่ปฏิบัติการได้และดำเนินการเอง evaln (), newfunction (), settimeout ([String], ... ) และ setInterval ([String], ... ) ทั้งหมดสามารถกลายเป็นผู้ให้บริการที่เป็นอันตรายได้ กลยุทธ์สำหรับ CSP ในการกำหนดเป้าหมายความเสี่ยงนี้คือการบล็อกเวกเตอร์เหล่านี้โดยสิ้นเชิง
สิ่งนี้มีความหมายบางอย่างเกี่ยวกับวิธีการสร้างแอปของคุณ:
แยกวิเคราะห์ JSON ผ่าน json.parse ในตัวโดยไม่ต้องพึ่งพาการประเมิน เบราว์เซอร์หลังจาก IE8 สนับสนุนการดำเนินงาน JSON ในท้องถิ่นซึ่งปลอดภัยอย่างสมบูรณ์
เขียนวิธีการโทรของ SetTimeOut และ SetInterval โดยฟังก์ชั่นอินไลน์แทนสตริง ตัวอย่างเช่น:
settimeout (document.querySelector ('a'). style.display = 'none';, 10);
สามารถเขียนใหม่เป็น:
settimeout (function () {document.QuerySelector ('a'). style.display = 'none';}, 10);
หลีกเลี่ยงเทมเพลตแบบอินไลน์ที่รันไทม์: ไลบรารีแม่แบบจำนวนมากใช้ฟังก์ชันใหม่ () เพื่อเพิ่มความเร็วในการสร้างเทมเพลต นี่เป็นสิ่งที่ยอดเยี่ยมสำหรับโปรแกรมแบบไดนามิก แต่เป็นความเสี่ยงสำหรับข้อความที่เป็นอันตราย
รายงาน
CSP สามารถบล็อกทรัพยากรที่ไม่น่าเชื่อถือทางฝั่งเซิร์ฟเวอร์ซึ่งมีประโยชน์มากสำหรับผู้ใช้ แต่มันมีประโยชน์มากสำหรับเราที่จะได้รับการแจ้งเตือนต่าง ๆ ที่ส่งไปยังเซิร์ฟเวอร์เพื่อให้เราสามารถระบุและแก้ไขการฉีดสคริปต์ที่เป็นอันตรายได้ เพื่อจุดประสงค์นี้คุณสามารถสั่งให้เบราว์เซอร์ส่งรายงานการสกัดกั้นในรูปแบบ JSON ไปยังที่อยู่ผ่าน Directive Report-URI
นโยบายความปลอดภัยของเนื้อหา: ค่าเริ่มต้น-SRC 'self'; - Report-uri /my_amazing_csp_report_parser;
รายงานจะมีลักษณะเช่นนี้:
-
CSP-Report: {
Document-Uri:
ผู้อ้างอิง:
บล็อก-ยูริ:
ความรุนแรง-กำกับ: script-src 'self' https://apis.google.com
Original-policy: script-src 'self' https://apis.google.com; รายงาน-ยูริ
-
-
ข้อมูลที่มีอยู่ในนั้นจะช่วยให้คุณระบุสถานการณ์การปิดกั้นรวมถึง Document-URI ที่เกิดขึ้นหน้าอ้างอิงหน้าทรัพยากรที่ละเมิดนโยบายหน้าคำสั่งที่ละเมิดและนโยบายเดิมของเนื้อหาหน้าทั้งหมด
การใช้งานจริง
CSP มีให้บริการบนเบราว์เซอร์ Chrome 16+ และ Firefox 4+ และคาดว่าจะได้รับการสนับสนุนที่ จำกัด ใน IE10 Safari ยังไม่ได้รับการสนับสนุน แต่มีการสร้าง WebKit ทุกคืนดังนั้นจึงคาดว่าจะได้รับการสนับสนุน Safari ในการทำซ้ำด้านล่าง
ลองดูกรณีการใช้งานที่ใช้กันทั่วไปด้านล่าง:
กรณีจริง 1: วิดเจ็ตสื่อสังคมออนไลน์
ปุ่ม Google +1 รวมถึงสคริปต์จาก https://apis.google.com รวมถึง iframes ที่ฝังตัวจาก https://plusone.google.com นโยบายของคุณต้องรวมแหล่งข้อมูลเหล่านี้เพื่อใช้ปุ่ม Google+1 กลยุทธ์ที่ง่ายที่สุดคือ script-src https://apis.google.com; frame-src https://plusone.google.com คุณต้องตรวจสอบให้แน่ใจว่าชิ้นส่วน JS ที่จัดทำโดย Google จะถูกเก็บไว้ในไฟล์ JS ภายนอก
มีโซลูชันการใช้งานมากมายสำหรับปุ่มชอบของ Facebook ฉันขอแนะนำให้คุณยึดติดกับเวอร์ชัน iframe เพราะมันแยกได้ดีจากส่วนที่เหลือของเว็บไซต์ของคุณ สิ่งนี้ต้องใช้การใช้งาน Frame-SRC https://facebook.com Directive โปรดทราบว่าโดยค่าเริ่มต้นรหัส IFRAME ที่จัดทำโดย Facebook ใช้เส้นทางที่สัมพันธ์กัน //facebook.com โปรดแก้ไขรหัสนี้เป็น https://facebook.com ไม่จำเป็นต้องใช้ HTTP
ปุ่มทวีตของ Twitter ขึ้นอยู่กับสคริปต์และเฟรมทั้งจาก https://platform.twitter.com (Twitter จัดเตรียม URL สัมพัทธ์ตามค่าเริ่มต้นโปรดแก้ไขรหัสเมื่อคัดลอกเพื่อระบุว่าเป็น HTTPS)
แพลตฟอร์มอื่น ๆ มีสถานการณ์ที่คล้ายกันและสามารถแก้ไขได้ในทำนองเดียวกัน ฉันขอแนะนำให้ตั้งค่าเริ่มต้น-SRC เป็น NONE จากนั้นดูที่คอนโซลเพื่อตรวจสอบทรัพยากรที่คุณต้องใช้เพื่อให้แน่ใจว่าวิดเจ็ตทำงานได้อย่างถูกต้อง
การใช้วิดเจ็ตหลายตัวนั้นง่ายมาก: เพียงแค่รวมคำสั่งนโยบายทั้งหมดและอย่าลืมใส่การตั้งค่าคำสั่งเดียวกันเข้าด้วยกัน หากคุณต้องการใช้วิดเจ็ตสามตัวข้างต้นกลยุทธ์จะมีลักษณะเช่นนี้:
script-src https://apis.google.com https://platform.twitter.com; frame-src https://plusone.google.com https://facebook.com https://platform.twitter.com
กรณีที่แท้จริง 2: การป้องกัน
สมมติว่าคุณเยี่ยมชมเว็บไซต์ธนาคารและต้องการให้แน่ใจว่ามีเพียงทรัพยากรที่คุณต้องการเท่านั้น ในกรณีนี้เริ่มการตั้งค่าการอนุญาตเริ่มต้นเพื่อบล็อกทุกอย่าง (ค่าเริ่มต้น-SRC 'ไม่มี') และสร้างนโยบายตั้งแต่เริ่มต้น
ตัวอย่างเช่นเว็บไซต์ธนาคารจำเป็นต้องโหลดรูปภาพสไตล์และสคริปต์จาก CDN จาก https://cdn.mybank.net และเชื่อมต่อกับ https://api.mybank.com/ ผ่าน XHR เพื่อดึงข้อมูลต่าง ๆ นอกจากนี้ยังจำเป็นต้องใช้เฟรม แต่เฟรมทั้งหมดมาจากหน้าท้องถิ่นที่ไม่ใช่พรรคที่ไม่ใช่สาม ไม่มีแฟลชฟอนต์และเนื้อหาอื่น ๆ บนเว็บไซต์ ในกรณีนี้เราสามารถส่งส่วนหัว CSP ที่เข้มงวดที่สุดคือ:
นโยบายความปลอดภัยของเนื้อหา: ค่าเริ่มต้น-SRC 'ไม่มี'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; Connect-src https://api.mybank.com; frame-src 'self'
กรณีจริง 3: ใช้ SSL เท่านั้น
ผู้ดูแลระบบแหวนแต่งงานต้องการให้ทรัพยากรทั้งหมดโหลดอย่างปลอดภัย แต่ไม่ต้องการเขียนโค้ดมากเกินไป การเขียนสคริปต์และรูปแบบอินไลน์ของบุคคลที่สามจำนวนมากเป็นจำนวนมากเป็นจำนวนมากเกินความสามารถของเขา ดังนั้นกลยุทธ์ต่อไปนี้จะมีประโยชน์มาก:
นโยบายความปลอดภัยของเนื้อหา: ค่าเริ่มต้น SRC HTTPS :; Script-SRC HTTPS: 'Unsafe-Inline'; Style-SRC HTTPS: 'Unsafe-Inline'
แม้ว่าค่าเริ่มต้น SRC จะระบุ HTTPS แต่สคริปต์และสไตล์จะไม่ได้รับการสืบทอดโดยอัตโนมัติ แต่ละคำสั่งจะแทนที่ประเภททรัพยากรเริ่มต้นอย่างสมบูรณ์
อนาคต
คณะทำงานด้านความปลอดภัยของแอปพลิเคชันเว็บแอปพลิเคชันของ W3C กำลังพัฒนารายละเอียดของข้อกำหนดนโยบายความปลอดภัยของเนื้อหา เวอร์ชัน 1.0 จะเข้าสู่ขั้นตอนการแก้ไขสุดท้ายซึ่งใกล้เคียงกับสิ่งที่อธิบายไว้ในบทความนี้มาก Public-WebAppSec@ Email Group กำลังพูดถึงเวอร์ชัน 1.1 และผู้ผลิตเบราว์เซอร์ก็ทำงานอย่างหนักเพื่อรวมและปรับปรุงการใช้งาน CSP
CSP 1.1 มีสิ่งที่น่าสนใจเกี่ยวกับ artboard ที่คุ้มค่าที่จะแยกรายการแยกกัน:
การเพิ่มนโยบายผ่าน Meta Tags: วิธีที่ต้องการในการตั้งค่า CSP คือส่วนหัว HTTP ซึ่งมีประโยชน์มาก แต่มันจะตรงกว่าผ่านแท็กหรือสคริปต์ แต่ยังไม่ได้รับการสรุป WebKit ได้ใช้คุณสมบัติของการตั้งค่าการอนุญาตผ่านองค์ประกอบ Meta ดังนั้นตอนนี้คุณสามารถลองการตั้งค่าต่อไปนี้ใน Chrome: เพิ่ม <metahttp-equiv = x-webkit-csp เนื้อหา = [นโยบายไปที่นี่]> ลงในส่วนหัวเอกสาร
คุณสามารถเพิ่มนโยบายผ่านสคริปต์ที่รันไทม์
DOM API: หากคุณลักษณะนี้ถูกเพิ่มลงในการวนซ้ำครั้งต่อไปของ CSP คุณสามารถสอบถามนโยบายความปลอดภัยปัจจุบันของหน้าผ่าน JavaScript และปรับตามสถานการณ์ที่แตกต่างกัน ตัวอย่างเช่นหากมีการประเมิน () การใช้งานรหัสของคุณอาจแตกต่างกันเล็กน้อย สิ่งนี้มีประโยชน์มากสำหรับผู้เขียนกรอบ JS; และข้อกำหนด API ยังคงไม่แน่นอนมากคุณสามารถค้นหาการวนซ้ำล่าสุดในส่วนอินเทอร์เฟซสคริปต์ของข้อกำหนดร่าง
คำสั่งใหม่: คำสั่งใหม่จำนวนมากอยู่ภายใต้การสนทนารวมถึงสคริปต์-ไม่: สคริปต์แบบอินไลน์สามารถใช้ได้ก็ต่อเมื่อใช้องค์ประกอบสคริปต์ที่ระบุไว้อย่างชัดเจน ปลั๊กอินประเภท: สิ่งนี้จะ จำกัด ประเภทของปลั๊กอิน Form-Action: อนุญาตให้ส่งแบบฟอร์มไปยังแหล่งเฉพาะเฉพาะเท่านั้น
หากคุณมีความสนใจในการอภิปรายเกี่ยวกับคุณสมบัติในอนาคตเหล่านี้คุณสามารถอ่านที่เก็บถาวรของรายชื่อผู้รับจดหมายหรือเพิ่มลงในรายชื่อผู้รับจดหมาย
บทความนี้แปลจาก:
ข้อความที่ตัดตอนมาจาก: บล็อกของ Jiang Yujie