ตรวจประเมินนโยบาย CSP
วาง header Content-Security-Policy แล้วดูว่า script source ตัวใดมีผลจริงหลังคิด fallback จาก default-src, unsafe-inline หรือ unsafe-eval ยังมีผลตรงไหน, wildcard หรือ scheme source ตัวใดเปิดให้ host ใดก็ได้, directive ใดไม่มีการสืบทอดเลย และ policy ที่แนะนำพร้อมคำอธิบายทุกการเปลี่ยน ทำงานในเบราว์เซอร์ทั้งหมด
Loading tool...
ตรวจประเมินนโยบาย CSP คืออะไร?
CSP Evaluator เป็น static analyzer สำหรับ Content-Security-Policy ที่คุณมีอยู่แล้ว วาง header แล้วเครื่องมือจะอ่านรายการ directive แบบเดียวกับที่เบราว์เซอร์ตีความ คือไล่ fallback จาก default-src สำหรับ fetch directive ให้ script-src-elem มีผลเหนือ script-src และแยกคีย์เวิร์ดที่ต้องใส่อัญประกาศกับ nonce หรือ hash ออกจากชื่อ host แล้วรายงานทีละกฎว่า policy เปิดอะไรไว้ ทุก finding มาพร้อมระดับความรุนแรง คำอธิบายว่าทำไมจึงสำคัญ และข้อเสนอแก้ ผลลัพธ์ปิดท้ายด้วย policy ที่แนะนำซึ่งสร้างจาก directive เดิมของคุณ โดยระบุทุกการเปลี่ยนที่ทำและทุกข้อเสนอที่ตั้งใจไม่ปรับให้ เครื่องมือนี้ไม่ส่ง request ไม่ได้สังเกตเบราว์เซอร์จริง และไม่ได้อ้างว่ารวบรวม bypass ได้ครบถ้วน มันคือชุดกฎที่ระบุไว้ และ policy ที่ไม่พบ finding ก็ยังไม่ถือว่าพิสูจน์แล้วว่าปลอดภัย
ประโยชน์หลัก
- เปลี่ยน header ที่ดูเหมือนปกติดีให้เป็นรายการชัดเจนว่ามันเปิดอะไรไว้ เพื่อไม่ให้ policy ที่อ่านดูเหมือนป้องกันถูกเข้าใจผิดว่าปลอดภัย
- ทำให้เห็นสายการสืบทอดจาก default-src ซึ่งเป็นจุดที่การไม่มี script-src ซ่อนกฎของ script ตัวจริงไว้อย่างเงียบ ๆ
- อธิบายว่าทำไม wildcard จึงยังควรเอาออกแม้ strict-dynamic ทำให้มันไม่มีผลในเบราว์เซอร์ปัจจุบัน เพราะเส้นทาง fallback ยังนับมันอยู่
- ทำให้ directive ที่ไม่สืบทอดจาก default-src ยังอยู่ตรงหน้าคุณ แทนที่จะปล่อยให้ default-src ที่เข้มงวดดูเหมือนครอบคลุมทั้งที่ไม่ได้ครอบคลุม
- ปิดท้ายด้วย policy ที่วางใช้ได้ทันที พร้อมบอกว่าการเปลี่ยนใดอาจทำให้ inline script พัง เพื่อให้คุณทดสอบก่อนแทนที่จะ deploy แบบเดา
กรณีการใช้งาน
- •ตรวจทาน Content-Security-Policy ก่อนเพิ่มความเข้มงวด เพื่อดูว่า policy ปัจจุบันอนุญาตอะไรอยู่แล้ว
- •ตรวจ policy ที่ประกอบจาก template หรือสร้างจากเครื่องมืออื่น ซึ่งรายการ directive อาจไม่ตรงกับที่แอปพลิเคชันต้องใช้จริง
- •ทำความเข้าใจว่าทำไมการทดลองแบบ report-only ยังมีการละเมิดอยู่ โดยหาว่า directive ใดทำได้น้อยกว่าที่ชื่อบอก
- •ใช้สอนเรื่องสายการสืบทอดและปฏิสัมพันธ์กับ strict-dynamic ด้วย header จริง พร้อมผลตอบกลับทีละกฎ
- •จัดทำเอกสารว่า policy ครอบคลุมและไม่ครอบคลุมอะไร สำหรับการรีวิวการเปลี่ยนแปลงหรือแบบสอบถามด้านความปลอดภัย
วิธีประเมิน header Content-Security-Policy
- วาง policy: วางค่า Content-Security-Policy จาก response header โดยจะมีหรือไม่มีชื่อ header ก็ได้ หรือเลือกตัวอย่างที่มีให้ วางหลายบรรทัดหรือตัวพิมพ์ปนกันก็ได้
- ดูว่าอะไรมีผลจริง: บล็อก script source ที่มีผลจริงจะบอกว่า directive ใดควบคุม script element และ inline event handler และบอกด้วยว่าสืบทอดมาจาก default-src แทนที่จะเขียนไว้ตรง ๆ หรือไม่
- ไล่ดู finding ทีละรายการ: แต่ละแถวบอกระดับความรุนแรง directive ที่เกี่ยวข้อง และเหตุผลที่มันสำคัญ ส่วนข้อเสนอที่เปลี่ยนพฤติกรรมจะแสดงเป็นคำแนะนำ เพื่อให้คุณตัดสินกับแอปของคุณเอง
- นำ policy ที่แนะนำไปใช้: คัดลอก policy ที่แนะนำกับรายการเปลี่ยนแปลง ตรวจทานทั้งสองกับแอปของคุณ แล้ว deploy และทดสอบในโหมด report-only ก่อนบังคับใช้จริง นี่เป็นตัวช่วยตรวจทาน ไม่ใช่สิ่งทดแทนการทดสอบเว็บของคุณ
คุณสมบัติหลัก
- ระบุ script source ที่มีผลจริง รวมถึงกรณีที่ไม่มี script-src แล้ว default-src ทำงานแทนอย่างเงียบ ๆ
- อธิบายปฏิสัมพันธ์กับ strict-dynamic อย่างถูกต้องว่า unsafe-inline และ scheme source จะไม่มีผลก็ต่อเมื่อมี nonce หรือ hash เปิดให้ strict-dynamic ทำงาน และยังมีผลเป็น fallback ให้ implementations เก่า
- ให้คะแนน wildcard และ scheme source ตามปริมาณการรัน script ที่แต่ละตัวเปิดไว้ แทนที่จะมอง wildcard ทุกตัวเป็น finding ระดับเดียวกัน
- แยก directive ที่ไม่มีการสืบทอดเลย เช่น base-uri, frame-ancestors, form-action และ sandbox ออกจากตัวที่สืบทอดจาก default-src
- คืน policy ที่แนะนำซึ่งสร้างจาก directive เดิมของคุณ พร้อมคำอธิบายทุกการเปลี่ยน และรายการที่เปลี่ยนพฤติกรรมจะให้เป็นคำแนะนำ ไม่ปรับให้เงียบ ๆ
- รายงาน directive ที่เลิกใช้หรือไม่เคยถูกนำไปใช้เป็นข้อมูล ไม่ใช่ error และระบุข้อจำกัดของตัวเองไว้ในรายงาน