โมเดลความปลอดภัยของเว็บมีการรูทในนโยบายต้นทางเดียวกัน โค้ดจาก https://mybank.com
ควรมีสิทธิ์เข้าถึงข้อมูลของ https://mybank.com
เท่านั้น และ https://evil.example.com
ไม่ควรจะได้รับอนุญาตให้เข้าถึงแน่นอน
ต้นทางแต่ละแห่งจะแยกออกจากส่วนอื่นๆ ในเว็บ ทำให้นักพัฒนาซอฟต์แวร์มีแซนด์บ็อกซ์ที่ปลอดภัยสำหรับสร้างและเล่น ในทางทฤษฎี สิ่งนี้สุดยอดจริงๆ ในทางปฏิบัติ ผู้โจมตีพบวิธีการที่ชาญฉลาดในการโค่นล้มระบบ
ตัวอย่างเช่น การโจมตีแบบ cross-site Scripting (XSS) ข้ามนโยบายต้นทางเดียวกันโดยหลอกลวงให้เว็บไซต์ส่งโค้ดที่เป็นอันตรายไปพร้อมกับเนื้อหาที่ตั้งใจ นี่เป็นปัญหาใหญ่เนื่องจากเบราว์เซอร์เชื่อถือโค้ดทั้งหมดที่แสดงบนหน้าเว็บว่าเป็นส่วนหนึ่งของต้นทางด้านความปลอดภัยของหน้าเว็บโดยชอบธรรม ข้อมูลโกง XSS เป็นข้อมูลเก่าและเป็นตัวแทนของวิธีการที่ผู้โจมตีอาจใช้เพื่อละเมิดความไว้วางใจนี้โดยการแทรกโค้ดที่เป็นอันตราย ถ้าผู้โจมตีแทรกโค้ดใดๆ ลงไปได้ ก็ถือว่าจบเกมมากทีเดียว ข้อมูลเซสชันของผู้ใช้จะถูกบุกรุก และข้อมูลที่ควรเก็บไว้เป็นความลับจะถูกขโมยไปโดย BadGuys ซึ่งแน่นอนว่าเราต้องป้องกันหากทำได้
ภาพรวมนี้ไฮไลต์การป้องกันที่สามารถลดความเสี่ยงและผลกระทบจากการโจมตี XSS ในเบราว์เซอร์สมัยใหม่ได้อย่างมาก: นโยบายรักษาความปลอดภัยเนื้อหา (CSP)
สรุปคร่าวๆ
- ใช้รายการที่อนุญาตเพื่อบอกลูกค้าว่าสินค้าใดได้รับอนุญาตให้ขาย และสินค้าใดที่ไม่ได้รับอนุญาต
- ดูคำสั่งที่ใช้ได้
- เรียนรู้เกี่ยวกับคีย์เวิร์ดที่พวกเขาใช้
- โค้ดในบรรทัดและ
eval()
ถือว่าเป็นอันตราย - รายงานการละเมิดนโยบายให้เซิร์ฟเวอร์ทราบก่อนที่จะบังคับใช้
รายการที่อนุญาตสำหรับแหล่งที่มา
ปัญหาที่ถูกโจมตีจากการโจมตี XSS คือการที่เบราว์เซอร์ไม่สามารถแยกแยะระหว่างสคริปต์ที่เป็นส่วนหนึ่งของแอปพลิเคชันของคุณและสคริปต์ที่แทรกเข้ามาอย่างมุ่งร้ายโดยบุคคลที่สาม ตัวอย่างเช่น ปุ่ม Google +1 ที่ด้านล่างของหน้าจะโหลดและเรียกใช้โค้ดจาก https://apis.google.com/js/plusone.js
ในบริบทของต้นทางของหน้านี้ เราเชื่อถือโค้ดนั้นได้ แต่ไม่อาจคาดหวังได้ว่าเบราว์เซอร์จะรู้ด้วยตัวเองว่าโค้ดจาก apis.google.com
เป็นโค้ดที่ยอดเยี่ยม ส่วนโค้ดจาก apis.evil.example.com
อาจจะไม่ใช่โค้ดดังกล่าว เบราว์เซอร์จะดาวน์โหลดและเรียกใช้โค้ดที่หน้าเว็บร้องขอ
โดยไม่คำนึงถึงแหล่งที่มา
CSP จะกำหนดส่วนหัว HTTP ของ Content-Security-Policy
ซึ่งจะให้คุณสร้างรายการแหล่งที่มาของเนื้อหาที่เชื่อถือได้ที่อนุญาต และสั่งให้เบราว์เซอร์เรียกใช้หรือแสดงผลเฉพาะทรัพยากรจากแหล่งที่มาเหล่านั้น แทนการค่อยๆ เชื่อทุกอย่างที่เซิร์ฟเวอร์ส่งมา แม้ว่าผู้โจมตีจะหาช่องโหว่ให้แทรกสคริปต์ได้ แต่สคริปต์จะไม่ตรงกับรายการที่อนุญาตและจะไม่ถูกเรียกใช้
เนื่องจากเราเชื่อมั่นว่า apis.google.com
จะส่งโค้ดที่ถูกต้อง และเราเชื่อมั่นว่าจะทำเช่นเดียวกัน เราจึงกำหนดนโยบายที่อนุญาตให้สคริปต์ทำงานเฉพาะเมื่อสคริปต์มาจากแหล่งที่มา 1 ใน 2 แหล่งที่มาต่อไปนี้
Content-Security-Policy: script-src 'self' https://apis.google.com
ง่ายใช่ไหม คุณคงพอจะเดาได้ว่า script-src
เป็นคำสั่งที่ควบคุมชุดสิทธิ์ที่เกี่ยวข้องกับสคริปต์ของหน้าหนึ่งๆ เราได้ระบุ 'self'
เป็นแหล่งที่มาที่ถูกต้องของสคริปต์แหล่งหนึ่ง และระบุ https://apis.google.com
เป็นอีกแหล่งที่มาหนึ่ง เบราว์เซอร์จะดาวน์โหลดและเรียกใช้ JavaScript อย่างถูกต้องจาก apis.google.com
ผ่าน HTTPS รวมถึงจากต้นทางของหน้าปัจจุบัน
เมื่อกำหนดนโยบายนี้แล้ว เบราว์เซอร์จะแสดงข้อผิดพลาดแทนที่จะโหลดสคริปต์จากแหล่งที่มาอื่น เมื่อผู้โจมตีที่ชาญฉลาดแทรกโค้ดลงในเว็บไซต์ของคุณ ผู้โจมตีจะพบกับข้อความแสดงข้อผิดพลาดแทนความสำเร็จที่พวกเขาคาดหวังไว้
นโยบายมีผลกับแหล่งข้อมูลที่หลากหลาย
แม้ว่าทรัพยากรสคริปต์จะเป็นความเสี่ยงด้านความปลอดภัยที่เห็นได้ชัดเจนที่สุด แต่ CSP มีชุดคำสั่งนโยบายที่สมบูรณ์ซึ่งช่วยให้ควบคุมทรัพยากรที่หน้าเว็บอนุญาตให้โหลดได้อย่างละเอียด คุณได้เห็น script-src
แล้ว แนวคิดจึงควรชัดเจน
มาดูคำสั่งทรัพยากรที่เหลือกันอย่างคร่าวๆ รายการด้านล่างแสดงสถานะของคำสั่งในระดับ 2 มีการเผยแพร่ข้อกำหนดระดับ 3 แล้ว แต่ไม่ได้นำไปใช้งานส่วนใหญ่ในเบราว์เซอร์หลัก
base-uri
จำกัด URL ที่ปรากฏในองค์ประกอบ<base>
ของหน้าchild-src
แสดงรายการ URL ของผู้ปฏิบัติงานและเนื้อหาเฟรมแบบฝัง ตัวอย่างเช่นchild-src https://youtube.com
จะเปิดใช้การฝังวิดีโอจาก YouTube แต่ไม่ได้เปิดใช้จากต้นทางอื่นๆconnect-src
จำกัดต้นทางที่คุณเชื่อมต่อได้ (ผ่าน XHR, WebSockets และ EventSource)font-src
ระบุต้นทางที่แสดงแบบอักษรของเว็บได้ เปิดใช้แบบอักษรเว็บของ Google ได้ผ่านfont-src https://themes.googleusercontent.com
form-action
แสดงรายการปลายทางที่ถูกต้องสำหรับการส่งจากแท็ก<form>
frame-ancestors
ระบุแหล่งที่มาที่สามารถฝังหน้าปัจจุบันได้ คำสั่งนี้ใช้กับแท็ก<frame>
,<iframe>
,<embed>
และ<applet>
คำสั่งนี้ใช้ได้ในแท็ก<meta>
ไม่ได้ และจะใช้กับทรัพยากรที่ไม่ใช่ HTML เท่านั้นframe-src
เลิกใช้งานแล้วในระดับ 2 แต่ได้รับการกู้คืนในระดับ 3 หากไม่ได้นำเสนอ ระบบจะยังกลับไปใช้child-src
เหมือนเดิมimg-src
กำหนดจุดเริ่มต้นสำหรับการโหลดรูปภาพmedia-src
จำกัดต้นทางที่อนุญาตให้ส่งวิดีโอและเสียงobject-src
ช่วยให้ควบคุม Flash และปลั๊กอินอื่นๆ ได้plugin-types
จำกัดประเภทของปลั๊กอินที่หน้าเว็บอาจเรียกใช้report-uri
ระบุ URL ที่เบราว์เซอร์จะส่งรายงานเมื่อมีการละเมิดนโยบายรักษาความปลอดภัยเนื้อหา ใช้คำสั่งนี้ในแท็ก<meta>
ไม่ได้style-src
เป็นคู่ของscript-src
สำหรับสไตล์ชีตupgrade-insecure-requests
จะสั่งให้ User Agent เขียนรูปแบบ URL ใหม่ ซึ่งจะเปลี่ยน HTTP เป็น HTTPS คำสั่งนี้มีไว้สำหรับเว็บไซต์ที่มี URL เก่าจำนวนมากซึ่งต้องเขียนใหม่worker-src
เป็นคำสั่ง CSP ระดับ 3 ที่จำกัด URL ที่อาจโหลดในฐานะผู้ปฏิบัติงาน ผู้ปฏิบัติงานที่แชร์ หรือ Service Worker คำสั่งนี้มีการติดตั้งใช้งานแบบจำกัดตั้งแต่เดือนกรกฎาคม 2017 เป็นต้นไป
คำสั่งจะเปิดอยู่โดยค่าเริ่มต้น หากคุณไม่ได้กำหนดนโยบายที่เฉพาะเจาะจงสำหรับคำสั่ง เช่น font-src
คำสั่งนั้นจะทำงานโดยค่าเริ่มต้นแม้ว่าคุณจะระบุ *
เป็นแหล่งที่มาที่ถูกต้อง (เช่น คุณจะโหลดแบบอักษรได้จากทุกที่โดยไม่มีข้อจำกัด)
คุณลบล้างลักษณะการทำงานเริ่มต้นนี้ได้โดยระบุคำสั่ง default-src
คำสั่งนี้จะกำหนดค่าเริ่มต้นสำหรับคำสั่งส่วนใหญ่ที่คุณไม่ระบุไว้ โดยทั่วไป การตั้งค่านี้จะมีผลกับคำสั่งที่ลงท้ายด้วย -src
หากตั้งค่า default-src
เป็น https://example.com
และคุณระบุคำสั่ง font-src
ไม่สำเร็จ คุณจะโหลดแบบอักษรจาก https://example.com
ได้โดยไม่ต้องโหลดที่อื่น เราระบุเพียง script-src
ในตัวอย่างก่อนหน้านี้ ซึ่งหมายความว่าคุณจะโหลดรูปภาพ แบบอักษร และอื่นๆ จากต้นทางใดก็ได้
คำสั่งต่อไปนี้ไม่ได้ใช้ default-src
เป็นคำสั่งสำรอง จำไว้ว่า
การไม่ตั้งค่าสิ่งต่างๆ ก็เหมือนกับการ
อนุญาตทุกอย่าง
base-uri
form-action
frame-ancestors
plugin-types
report-uri
sandbox
คุณจะใช้คำสั่งเหล่านี้กี่รายการก็ได้เท่าที่เหมาะสมสำหรับแอปพลิเคชันนั้นๆ เพียงระบุคำสั่งแต่ละรายการในส่วนหัวของ HTTP โดยคั่นด้วยเครื่องหมายอัฒภาค ตรวจสอบว่าได้ระบุทรัพยากรที่จำเป็นทั้งหมดของประเภทที่เฉพาะเจาะจงไว้ในคำสั่ง single แล้ว ถ้าคุณเขียนบางอย่าง เช่น script-src https://host1.com; script-src https://host2.com
ระบบจะไม่สนใจคำสั่งที่ 2 ตัวอย่างวิธีต่อไปนี้
จะระบุให้ต้นทางทั้ง 2 แห่งถูกต้อง
script-src https://host1.com https://host2.com
ตัวอย่างเช่น หากคุณมีแอปพลิเคชันที่โหลดทรัพยากรทั้งหมดจากเครือข่ายนำส่งข้อมูล (เช่น https://cdn.example.net
) และทราบว่าคุณไม่จำเป็นต้องใช้เนื้อหาหรือปลั๊กอินที่เฟรม นโยบายของคุณอาจมีลักษณะดังต่อไปนี้
Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'
รายละเอียดการใช้งาน
คุณจะเห็นส่วนหัว X-WebKit-CSP
และ X-Content-Security-Policy
ในบทแนะนำต่างๆ บนเว็บ ตั้งแต่นี้เป็นต้นไป คุณควรเพิกเฉยต่อส่วนหัวที่มีคำนำหน้าเหล่านี้ เบราว์เซอร์ที่ทันสมัย (ยกเว้น IE) รองรับส่วนหัว Content-Security-Policy
ที่ไม่มีคำนำหน้า ซึ่งเป็นส่วนหัวที่คุณควรใช้
ไม่ว่าคุณจะใช้ส่วนหัวแบบใดก็ตาม ระบบจะกำหนดนโยบายแบบหน้าต่อหน้า คุณจะต้องส่งส่วนหัวของ HTTP ไปพร้อมกับทุกคำตอบที่ต้องการเพื่อให้แน่ใจว่าจะได้รับการป้องกัน วิธีนี้มีความยืดหยุ่นมาก เพราะคุณสามารถปรับแต่งนโยบายสำหรับหน้าเว็บที่เฉพาะเจาะจงตามความต้องการที่เฉพาะเจาะจงได้ บางหน้าเว็บอาจมีหน้าหนึ่งในเว็บไซต์ของคุณมีปุ่ม +1 ในขณะที่บางชุดไม่มี คุณอาจอนุญาตให้โค้ดปุ่มโหลดเมื่อจำเป็นเท่านั้น
รายการแหล่งที่มาในแต่ละคำสั่งมีความยืดหยุ่น คุณระบุแหล่งที่มาตามรูปแบบ (data:
, https:
) หรือช่วงความจำเพาะจากชื่อโฮสต์เท่านั้นได้ (example.com
ซึ่งจะตรงกับต้นทางในโฮสต์นั้น เช่น ชุดรูปแบบ พอร์ตใดก็ได้) ไปจนถึง URI แบบเต็ม (https://example.com:443
ซึ่งจับคู่กับ HTTPS เท่านั้น, เฉพาะ example.com
และพอร์ต 443 เท่านั้น) ระบบยอมรับไวลด์การ์ด แต่ต้องอยู่ในรูปแบบรูปแบบ พอร์ต หรือในตำแหน่งด้านซ้ายสุดของชื่อโฮสต์เท่านั้น *://*.example.com:*
จะจับคู่โดเมนย่อยทั้งหมดของ example.com
(แต่ไม่ใช่ example.com
เอง) โดยใช้รูปแบบใดก็ได้บนพอร์ตใดก็ได้
รายการแหล่งที่มายังยอมรับคีย์เวิร์ด 4 คำต่อไปนี้ด้วย
- ส่วน
'none'
จะไม่มีข้อมูลที่ตรงกัน อย่างที่คุณอาจคาดไว้ 'self'
จะจับคู่ต้นทางปัจจุบัน แต่ไม่จับคู่กับโดเมนย่อย'unsafe-inline'
อนุญาตให้ใช้ JavaScript และ CSS ในหน้าได้ (เราจะพูดถึงเรื่องนี้อย่างละเอียด อีกเล็กน้อย)'unsafe-eval'
อนุญาตกลไกการแปลงข้อความเป็น JavaScript เช่นeval
(เราจะพูดถึงเรื่องนี้เช่นกัน)
คีย์เวิร์ดเหล่านี้ต้องใช้เครื่องหมายคำพูดเดี่ยว ตัวอย่างเช่น script-src 'self'
(มีเครื่องหมายคำพูด) ให้สิทธิ์การเรียกใช้ JavaScript จากโฮสต์ปัจจุบัน script-src self
(ไม่มีเครื่องหมายคำพูด) อนุญาตให้ใช้ JavaScript จากเซิร์ฟเวอร์ชื่อ "self
" (และ ไม่ใช่ จากโฮสต์ปัจจุบัน) ซึ่งอาจจะไม่ใช่อย่างที่คุณต้องการ
แซนด์บ็อกซ์
มีคำสั่งอีก 1 อย่างที่ควรพูดถึงคือ sandbox
หน้าจะแตกต่างจากโปรแกรมอื่นๆ ที่เราดูแล้วเล็กน้อย เนื่องจากจะวางข้อจำกัดเกี่ยวกับการดำเนินการต่างๆ ที่หน้าเว็บนั้นสามารถทำได้ แทนที่จะเป็นทรัพยากรที่หน้าเว็บนั้นสามารถโหลดได้ หากมีคำสั่ง sandbox
อยู่ ระบบจะถือว่าหน้าเว็บโหลดภายใน <iframe>
ที่มีแอตทริบิวต์ sandbox
ซึ่งอาจส่งผลกระทบที่หลากหลายต่อหน้าเว็บ ได้แก่ การบังคับให้หน้ามีต้นทางที่ไม่ซ้ำ การป้องกันไม่ให้ส่งแบบฟอร์ม และอื่นๆ แม้ว่าบทความนี้จะอยู่นอกเหนือขอบเขตของบทความนี้เล็กน้อย แต่คุณสามารถดูรายละเอียดทั้งหมดเกี่ยวกับแอตทริบิวต์แซนด์บ็อกซ์ที่ถูกต้องได้ในส่วน "แซนด์บ็อกซ์" ของข้อกำหนด HTML5
เมตาแท็ก
กลไกการนำส่งที่ต้องการของ CSP คือส่วนหัว HTTP อย่างไรก็ตาม การตั้งค่านโยบายในหน้าเว็บในมาร์กอัปโดยตรงอาจเป็นประโยชน์ ให้ใช้แท็ก <meta>
ที่มีแอตทริบิวต์ http-equiv
ดังนี้
<meta
http-equiv="Content-Security-Policy"
content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"
/>
ใช้ไม่ได้กับ frame-ancestors
, report-uri
หรือ sandbox
โค้ดในบรรทัดถือว่าเป็นอันตราย
ควรชัดเจนว่า CSP อิงตามต้นทางในรายการที่อนุญาต เนื่องจากเป็นวิธีการที่ชัดเจนในการสั่งให้เบราว์เซอร์จัดการชุดทรัพยากรบางอย่างให้อยู่ในระดับที่ยอมรับได้และต้องปฏิเสธทรัพยากรที่เหลือ รายการที่อนุญาตตามต้นทางจะไม่แก้ไขภัยคุกคามที่ใหญ่ที่สุดที่เกิดจากการโจมตี XSS ซึ่งก็คือการแทรกสคริปต์ในหน้า
หากผู้โจมตีสามารถแทรกแท็กสคริปต์ที่มีเพย์โหลดที่เป็นอันตราย (<script>sendMyDataToEvilDotCom();</script>
) โดยตรง เบราว์เซอร์จะไม่มีกลไกในการแยกเบราว์เซอร์จากแท็กสคริปต์ในหน้าที่ถูกต้อง CSP แก้ไขปัญหานี้โดยแบนสคริปต์แบบในหน้าทั้งหมด
นี่เป็นวิธีเดียวที่แน่ใจได้
การแบนนี้ไม่เพียงแค่สคริปต์ที่ฝังในแท็ก script
โดยตรง แต่ยังรวมถึงเครื่องจัดการเหตุการณ์ในบรรทัดและ URL javascript:
คุณจะต้องย้ายเนื้อหาของแท็ก script
ไปยังไฟล์ภายนอก และแทนที่ javascript:
URL และ <a ... onclick="[JAVASCRIPT]">
ด้วยการเรียก addEventListener()
ที่เหมาะสม ตัวอย่างเช่น คุณอาจเขียนคำสั่งต่อไปนี้ใหม่
<script>
function doAmazingThings() {
alert('YOU AM AMAZING!');
}
</script>
<button onclick="doAmazingThings();">Am I amazing?</button>
ไปเป็นแบบอื่นๆ เช่น
<!-- amazing.html -->
<script src="amazing.js"></script>
<button id="amazing">Am I amazing?</button>
<div style="clear:both;"></div>
// amazing.js
function doAmazingThings() {
alert('YOU AM AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
document.getElementById('amazing').addEventListener('click', doAmazingThings);
});
โค้ดที่เขียนใหม่มีข้อดีเหนือและมากกว่าการทำงานกับ CSP ได้ดี เนื่องจากเป็นแนวทางปฏิบัติที่ดีที่สุดอยู่แล้ว ไม่ว่าคุณจะใช้ CSP แบบใดก็ตาม โครงสร้างและลักษณะการทำงานของการผสมผสาน JavaScript ในบรรทัดในแบบที่คุณไม่ควรทำ เบราว์เซอร์สามารถแคชทรัพยากรภายนอกได้ง่ายขึ้น ทำให้นักพัฒนาซอฟต์แวร์เข้าใจได้มากขึ้น อีกทั้งช่วยให้มีการคอมไพล์และการลดขนาดลงด้วย คุณจะเขียนโค้ดได้ดีขึ้นหากคุณดำเนินการย้ายโค้ดไปยังทรัพยากรภายนอก
สไตล์อินไลน์จะมีการจัดการในลักษณะเดียวกัน นั่นคือควรรวมแอตทริบิวต์ style
และแท็ก style
ไว้ในสไตล์ชีตภายนอกเพื่อป้องกันวิธีการขโมยข้อมูลที่ชาญฉลาดอย่างไม่น่าเชื่อหลายแบบที่ CSS เปิดใช้
หากต้องมีสคริปต์และรูปแบบในหน้า ก็เปิดใช้ได้โดยการเพิ่ม 'unsafe-inline'
เป็นแหล่งที่มาที่อนุญาตในคำสั่ง script-src
หรือ style-src
คุณสามารถใช้ Nonce หรือแฮชก็ได้ (ดูด้านล่าง) แต่จริงๆ แล้วไม่ควรทำ
การแบนสคริปต์ในบรรทัดเป็นการรักษาความปลอดภัยของ CSP ที่ใหญ่ที่สุด และแบนรูปแบบอินไลน์จะทำให้แอปพลิเคชันของคุณแข็งแกร่งขึ้นเช่นกัน เราจะต้องใช้ความพยายามเล็กน้อยเพื่อให้แน่ใจว่าสิ่งต่างๆ ทำงานได้อย่างถูกต้องหลังจากที่ย้ายโค้ดทั้งหมดออกไปจากที่อื่น แต่ก็เป็นสิ่งตอบแทนที่คุ้มค่า
หากคุณจำเป็นต้องใช้
CSP ระดับ 2 มีความเข้ากันได้แบบย้อนหลังสำหรับสคริปต์แบบในหน้า โดยให้คุณเพิ่มสคริปต์แบบในหน้าที่เจาะจงลงในรายการที่อนุญาตได้โดยใช้ค่า Nonce ของการเข้ารหัส (จำนวนที่ใช้ครั้งเดียว) หรือแฮช แม้วิธีนี้อาจยุ่งยาก แต่ก็ช่วยได้
หากต้องการใช้ค่า Nonce ให้ระบุแอตทริบิวต์ Nonce ให้แท็กสคริปต์ ค่าของ URL ต้องตรงกับ แหล่งที่มาในรายการแหล่งที่มาที่เชื่อถือได้ เช่น
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
// Some inline code I can't remove yet, but need to asap.
</script>
ตอนนี้ ให้เพิ่ม Nonce ลงในคำสั่ง script-src
ต่อท้ายคีย์เวิร์ด nonce-
Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
อย่าลืมว่าต้องสร้าง nonces สำหรับทุกๆ คำขอหน้าเว็บและต้องคาดเดาไม่ได้
แฮชจะทำงานในลักษณะเดียวกัน แทนที่จะเพิ่มโค้ดลงในแท็กสคริปต์ ให้สร้างแฮช SHA ของสคริปต์แล้วเพิ่มลงในคำสั่ง script-src
เช่น สมมติว่าหน้าเว็บมีเนื้อหาต่อไปนี้
<script>
alert('Hello, world.');
</script>
นโยบายของคุณจะประกอบด้วย:
Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='
มี 2-3 อย่างที่ควรทราบที่นี่ คำนำหน้า sha*-
จะระบุอัลกอริทึมที่สร้างแฮช ในตัวอย่างด้านบน ระบบใช้ sha256-
นอกจากนี้ CSP ยังรองรับ sha384-
และ sha512-
ด้วย ขณะสร้างแฮช โปรดอย่ารวมแท็ก <script>
นอกจากนี้ การใช้อักษรตัวพิมพ์ใหญ่และการเว้นวรรค รวมถึงช่องว่างนำหน้าหรือต่อท้าย
การค้นหาใน Google เกี่ยวกับการสร้างแฮช SHA จะนำคุณไปยังโซลูชันในภาษาต่างๆ เมื่อใช้ Chrome 40 ขึ้นไป คุณจะเปิดเครื่องมือสำหรับนักพัฒนาเว็บแล้วโหลดหน้าเว็บซ้ำได้ แท็บคอนโซลจะมีข้อความแสดงข้อผิดพลาดพร้อมแฮช sha256 ที่ถูกต้องสำหรับสคริปต์ในหน้าแต่ละรายการ
ประเมินด้วย
แม้ว่าผู้โจมตีจะแทรกสคริปต์โดยตรงไม่ได้ พวกเขาก็อาจหลอกให้แอปพลิเคชันแปลงข้อความเฉื่อยเป็น JavaScript ที่เป็นไฟล์ปฏิบัติการได้ และเรียกใช้งานในนามของตนได้ eval()
, new
Function() , setTimeout([string], ...)
และ
setInterval([string], ...)
คือเวกเตอร์ทั้งหมดที่ข้อความที่แทรกเข้ามาอาจทำให้เกิดการดำเนินการที่เป็นอันตรายโดยไม่คาดคิด การตอบสนองเริ่มต้นของ CSP ต่อความเสี่ยงนี้คือการบล็อกเวกเตอร์เหล่านี้ทั้งหมด
ซึ่งมีผลกระทบมากกว่า 2-3 อย่างเกี่ยวกับวิธีสร้างแอปพลิเคชัน ดังนี้
- คุณต้องแยกวิเคราะห์ JSON ผ่าน
JSON.parse
ในตัวแทนที่จะใช้eval
การดำเนินการของ JSON แบบดั้งเดิมมีให้ใช้งานในทุกเบราว์เซอร์ตั้งแต่ IE8 และมีความปลอดภัยมากที่สุด - เขียนการเรียก
setTimeout
หรือsetInterval
ที่คุณกำลังทำอยู่ด้วยฟังก์ชันในบรรทัดใหม่แทนสตริง เช่น
setTimeout("document.querySelector('a').style.display = 'none';", 10);
ควรเขียนให้ดีขึ้นดังนี้:
setTimeout(function () {
document.querySelector('a').style.display = 'none';
}, 10);
- หลีกเลี่ยงการกำหนดเทมเพลตในหน้าขณะรันไทม์: ไลบรารีที่มีเทมเพลตจำนวนมากใช้
new Function()
อย่างอิสระเพื่อให้สร้างเทมเพลตได้เร็วขึ้นในระหว่างรันไทม์ เป็นการใช้งานโปรแกรมแบบไดนามิกที่ดี แต่ก็มีความเสี่ยงที่จะประเมินข้อความที่เป็นอันตราย บางเฟรมเวิร์กรองรับ CSP อยู่แล้ว แต่กลับไปใช้โปรแกรมแยกวิเคราะห์ที่มีประสิทธิภาพแทนเมื่อไม่มีeval
คำสั่ง ng-csp ของ AngularJS เป็นตัวอย่างที่ดี
อย่างไรก็ตาม ตัวเลือกที่ดีกว่าควรใช้ภาษาเทมเพลตที่มีฟังก์ชันการคอมไพล์ (ตัวอย่างเช่น แฮนเดิลบาร์มี) การคอมไพล์เทมเพลตล่วงหน้าจะทำให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่เร็วขึ้นกว่าการใช้รันไทม์ที่เร็วที่สุด และยังปลอดภัยด้วย หาก eval และตัวแปรที่แปลงข้อความเป็น JavaScript เป็นสิ่งจำเป็นต่อแอปพลิเคชัน คุณจะเปิดใช้ได้โดยการเพิ่ม 'unsafe-eval'
เป็นแหล่งที่มาที่อนุญาตในคำสั่ง script-src
แต่เราไม่แนะนำให้ทำเช่นนี้ การแบนความสามารถในการเรียกใช้สตริงทำให้ผู้โจมตีเรียกใช้โค้ดที่ไม่ได้รับอนุญาตในเว็บไซต์ได้ยากขึ้นมาก
การรายงาน
ความสามารถของ CSP ในการบล็อกทรัพยากรที่ไม่น่าเชื่อถือฝั่งไคลเอ็นต์เป็นสิ่งที่ได้ผลอย่างยิ่งสำหรับผู้ใช้ แต่การส่งการแจ้งเตือนบางอย่างกลับไปยังเซิร์ฟเวอร์อาจเป็นประโยชน์มาก เพื่อให้คุณสามารถระบุและตรวจหาข้อบกพร่องใดๆ ที่ทำให้เกิดการแทรกที่เป็นอันตรายได้ตั้งแต่แรก ด้วยเหตุนี้ คุณสั่งให้เบราว์เซอร์POST
รายงานการละเมิดรูปแบบ JSON ไปยังตำแหน่งที่ระบุในคำสั่ง report-uri
ได้
Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
รายงานเหล่านี้จะมีหน้าตาดังนี้
{
"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer": "http://evil.example.com/",
"blocked-uri": "http://evil.example.com/evil.js",
"violated-directive": "script-src 'self' https://apis.google.com",
"original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
}
}
ซึ่งประกอบด้วยข้อมูลจำนวนมากที่จะช่วยให้คุณติดตามสาเหตุที่เฉพาะเจาะจงของการละเมิดได้ รวมถึงหน้าที่เกิดการละเมิด (document-uri
), ผู้อ้างอิงของหน้าดังกล่าว (โปรดทราบว่าต่างจากช่องส่วนหัว HTTP ตรงที่คีย์ไม่ได้สะกดผิด), ทรัพยากรที่ละเมิดนโยบายของหน้าเว็บ (blocked-uri
), คำสั่งเฉพาะเจาะจงที่ละเมิด
(violated-directive
) และนโยบายที่สมบูรณ์ของหน้าเว็บ (original-policy
)
รายงานเท่านั้น
หากคุณเพิ่งเริ่มต้นกับ CSP คุณควรประเมินสถานะปัจจุบันของแอปพลิเคชันก่อนที่จะใช้นโยบายจริงกับผู้ใช้
เพื่อให้การทำให้ใช้งานได้เสร็จสมบูรณ์ คุณสามารถขอให้เบราว์เซอร์ตรวจสอบนโยบาย รายงานการละเมิด แต่ไม่บังคับใช้ข้อจำกัด ส่งส่วนหัว Content-Security-Policy-Report-Only
แทนการส่งส่วนหัว Content-Security-Policy
Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
โดยนโยบายที่ระบุในโหมดรายงานเท่านั้นจะไม่บล็อกทรัพยากรที่ถูกจำกัด แต่จะส่งรายงานการละเมิดไปยังตำแหน่งที่คุณระบุ คุณจะส่งส่วนหัวทั้ง 2 รายการและบังคับใช้นโยบายใดนโยบายหนึ่งไปพร้อมๆ กับตรวจสอบอีกนโยบายหนึ่งได้ นี่เป็นวิธีที่ยอดเยี่ยมในการประเมินผลกระทบของการเปลี่ยนแปลง CSP ของแอปพลิเคชัน นั่นคือ การเปิดการรายงานสำหรับนโยบายใหม่ ตรวจสอบรายงานการละเมิด และแก้ไขข้อบกพร่องใดๆ ที่เกิดขึ้น เมื่อคุณพอใจกับผลของการเปลี่ยนแปลงแล้ว ให้เริ่มบังคับใช้นโยบายใหม่
การใช้งานในชีวิตจริง
CSP 1 ค่อนข้างใช้งานได้ใน Chrome, Safari และ Firefox แต่ IE 10 รองรับได้อย่างจำกัดมาก คุณดูข้อมูลที่เฉพาะเจาะจงได้ที่ caniuse.com CSP ระดับ 2 พร้อมใช้งานใน Chrome ตั้งแต่เวอร์ชัน 40 เว็บไซต์ขนาดใหญ่อย่าง Twitter และ Facebook ได้นำส่วนหัวนี้ไปใช้ (กรณีศึกษาของ Twitter เป็นสิ่งที่คุ้มค่าแก่การอ่าน) และมาตรฐานนี้ก็พร้อมช่วยให้คุณเริ่มนำไปใช้ในเว็บไซต์ของคุณเองได้
ขั้นตอนแรกในการสร้างนโยบายสำหรับแอปพลิเคชันคือการประเมินทรัพยากรที่คุณกำลังโหลดจริง เมื่อคุณคิดว่าเข้าใจวิธีการรวบรวมสิ่งต่างๆ ในแอปแล้ว ให้ตั้งค่านโยบายตามข้อกำหนดเหล่านั้น ลองมาดู Use Case ทั่วไป 2-3 อย่างเพื่อหาวิธีที่เราจะช่วยเหลือกรณีที่อยู่ในขอบเขตการป้องกันของ CSP ได้ดีที่สุด
กรณีการใช้งานที่ 1: วิดเจ็ตโซเชียลมีเดีย
ปุ่ม +1 ของ Google มีสคริปต์จาก
https://apis.google.com
และฝัง<iframe>
จากhttps://plusone.google.com
คุณต้องมีนโยบายที่มีต้นทางทั้ง 2 รายการนี้จึงจะฝังปุ่มได้ นโยบายขั้นต่ำคือscript-src https://apis.google.com; child-src https://plusone.google.com
นอกจากนี้ คุณยังต้องตรวจสอบว่าได้ดึงข้อมูลโค้ด JavaScript ที่ Google ให้มาไว้ในไฟล์ JavaScript ภายนอกแล้ว หากคุณมีนโยบายระดับ 1 ที่ใช้frame-src
ระดับ 2 กำหนดให้คุณต้องเปลี่ยนเป็นchild-src
สิ่งนี้ไม่จำเป็นใน CSP ระดับ 3 อีกต่อไปปุ่มชอบของ Facebook มีตัวเลือกการใช้งานมากมาย เราขอแนะนําให้ใช้เวอร์ชัน
<iframe>
ต่อไป เนื่องจากเวอร์ชันนี้ได้รับการแซนด์บ็อกซ์อย่างปลอดภัยจากส่วนที่เหลือของเว็บไซต์ และต้องใช้คำสั่งchild-src https://facebook.com
เพื่อให้ทำงานได้อย่างถูกต้อง โปรดทราบว่าโดยค่าเริ่มต้น รหัส<iframe>
ที่ Facebook ให้ไว้จะโหลด URL แบบสัมพัทธ์//facebook.com
เปลี่ยนเป็นระบุ HTTPS อย่างชัดแจ้ง:https://facebook.com
ไม่มีเหตุผลที่จะใช้ HTTP หากคุณไม่จำเป็นปุ่มทวีตของ Twitter ต้องใช้การเข้าถึงสคริปต์และเฟรม โดยทั้ง 2 อย่างโฮสต์อยู่ที่
https://platform.twitter.com
(ในทำนองเดียวกัน Twitter จะให้ URL สัมพัทธ์โดยค่าเริ่มต้น แก้ไขโค้ดเพื่อระบุ HTTPS เมื่อคัดลอก/วางในเครื่อง) คุณจะใช้script-src https://platform.twitter.com; child-src https://platform.twitter.com
ได้ตราบใดที่ย้ายข้อมูลโค้ด JavaScript ที่ Twitter ให้ไปไว้ในไฟล์ JavaScript ภายนอกแพลตฟอร์มอื่นๆ มีข้อกำหนดที่คล้ายกันและแก้ไขในลักษณะเดียวกันได้ เราขอแนะนำให้ตั้งค่า
default-src
เป็น'none'
และดูคอนโซลเพื่อกำหนดทรัพยากรที่คุณต้องเปิดใช้เพื่อให้วิดเจ็ตทำงานได้
การรวมวิดเจ็ตหลายรายการนั้นทำได้ง่าย เพียงรวมคำสั่งของนโยบาย เช่น รวมทรัพยากรทั้งหมดประเภทเดียวไว้ในคำสั่งเดียว หากคุณต้องการวิดเจ็ตโซเชียลมีเดียทั้ง 3 แบบ นโยบายจะมีลักษณะดังนี้
script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com
กรณีการใช้งานที่ 2: การปิดล็อก
สมมติว่าคุณมีเว็บไซต์ธนาคารและต้องการตรวจสอบว่า
มีทรัพยากรที่คุณเขียนขึ้นเองเท่านั้นที่สามารถโหลดได้ ในสถานการณ์นี้ ให้เริ่มต้นด้วยนโยบายเริ่มต้นที่บล็อกทุกสิ่งทุกอย่าง (default-src 'none'
) และสร้างจากที่นั่น
สมมติว่าธนาคารโหลดรูปภาพ รูปแบบ และสคริปต์ทั้งหมดจาก CDN ที่ https://cdn.mybank.net
และเชื่อมต่อผ่าน XHR ไปยัง https://api.mybank.com/
เพื่อดึงข้อมูลต่างๆ ลงมา เฟรมจะใช้สำหรับเฉพาะหน้าเว็บที่เชื่อมโยงกับเว็บไซต์เท่านั้น (ไม่มีต้นทางของบุคคลที่สาม) ในเว็บไซต์ไม่มี Flash
ไม่มีแบบอักษร ไม่ใช้องค์ประกอบเพิ่มเติม ส่วนหัว CSP ที่จำกัดที่สุดที่เราสามารถส่งได้คือ
Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'
กรณีการใช้งานที่ 3: SSL เท่านั้น
ผู้ดูแลระบบฟอรัมอภิปรายงานแต่งงานต้องการดูแลให้ทรัพยากรทั้งหมดโหลดผ่านช่องทางที่ปลอดภัยเท่านั้น แต่ไม่ได้เขียนโค้ดมากนัก การเขียนซอฟต์แวร์ฟอรัมของบุคคลที่สามจำนวนมากให้มีสคริปต์และสไตล์แบบอินไลน์เป็นสิ่งที่เกินความสามารถของเขา นโยบายต่อไปนี้จะมีผล
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'
แม้ว่าจะระบุ https:
ใน default-src
แต่สคริปต์และรูปแบบคำสั่งจะไม่รับค่าแหล่งที่มานั้นโดยอัตโนมัติ คำสั่งแต่ละรายการจะเขียนทับค่าเริ่มต้นสำหรับประเภททรัพยากรที่ระบุโดยสมบูรณ์
อนาคต
นโยบายรักษาความปลอดภัยเนื้อหาระดับ 2 เป็น คำแนะนำของผู้สมัคร คณะทำงานด้านการรักษาความปลอดภัยสำหรับเว็บแอปพลิเคชันของ W3C ได้เริ่มดำเนินการปรับปรุงนโยบายรักษาความปลอดภัยเนื้อหาระดับที่ 3 ของข้อกำหนดใหม่แล้ว
หากคุณสนใจในการพูดคุยเกี่ยวกับคุณลักษณะที่กำลังจะมีขึ้นเหล่านี้ ดูข้อมูลที่เก็บรายชื่ออีเมลแบบสาธารณะ-webappsec@ หรือเข้าร่วมด้วยตนเอง