Defaults.Exposed › การแก้ไข › Content-Security-Policy (CSP)

วิธีแก้ไข Content-Security-Policy (CSP)

Content Security Policy คือกฎความปลอดภัยที่เว็บไซต์ของคุณส่งให้เบราว์เซอร์ของผู้เข้าชมทุกคน บอกอย่างแน่ชัดว่าโค้ดใดได้รับอนุญาตให้รัน หากไม่มี หากมีอะไรเป็นอันตรายเคยลงบนหน้า — ผ่านช่องความคิดเห็น ปลั๊กอินที่ถูกแฮ็ก หรือสคริปต์ของบุคคลที่สาม — เบราว์เซอร์จะรันมันได้อย่างอิสระ รวมถึงโค้ดที่คัดลอกหมายเลขบัตรและรหัสผ่านของลูกค้าเงียบๆ ขณะที่พวกเขาพิมพ์ โดยยังคงแสดงกุญแจอยู่

สรุปสำหรับธุรกิจของคุณ: หากเว็บไซต์ของคุณถูกดัดแปลง โค้ดที่เป็นอันตรายสามารถอ่านรายละเอียดบัตรชำระเงินและการเข้าสู่ระบบของลูกค้าจากหน้าชำระเงินของคุณเองในขณะที่ทุกอย่างดูปกติอย่างสมบูรณ์ — ทำให้คุณมีชาร์จแบ็ค การเรียกร้องการฉ้อโกง การละเมิดข้อมูลที่ต้องรายงาน และความล้มเหลวในการตรวจสอบที่ทีมความปลอดภัยของลูกค้ารายใหญ่ใช้เพื่อหยุดหรือยกเลิกดีล

สิ่งนี้อาจทำให้คุณเสียค่าใช้จ่าย

• โค้ดที่ซ่อนอยู่แอบเข้าไปในหน้าหนึ่งของคุณและคัดลอกหมายเลขบัตรและรหัสผ่านที่ลูกค้าป้อนในหน้าชำระเงินทุกใบเงียบๆ ส่งไปยังผู้โจมตีในเวลาจริง เว็บไซต์ของคุณดูและทำงานปกติอย่างสมบูรณ์ คุณค้นพบมันสัปดาห์ต่อมาเมื่อผู้ให้บริการชำระเงินโทรมาเกี่ยวกับกลุ่มรายงานการฉ้อโกงที่ติดตามกลับมาที่ร้านค้าของคุณ
• นักต้มตุ๋นฉีดแบบฟอร์ม 'ชำระที่นี่' ปลอมลงบนเว็บไซต์จริงของคุณที่บันทึกการชำระเงินเข้าบัญชีของพวกเขา ลูกค้าเชื่อว่าพวกเขาจ่ายคุณ โทษคุณเมื่อสินค้าไม่มา และเรียกร้องเงินคืน
• ทีมความปลอดภัยของผู้มีโอกาสเป็นลูกค้ารายใหญ่สแกนเว็บไซต์ของคุณ เห็นว่าการป้องกันพื้นฐานนี้ปิดอยู่ และตั้งค่าสถานะมัน — หยุดหรือสูญเสียสัญญาจนกว่าคุณจะพิสูจน์ว่าแก้ไขแล้ว
• การละเมิดที่ติดตามกลับไปยังมาตรการป้องกันมาตรฐานที่ขาดหายไปกลายเป็นเหตุการณ์ที่ต้องรายงาน: คำถามจากผู้กำกับดูแล การแจ้งเตือนลูกค้า และความเสียหายต่อชื่อเสียงที่มีค่าใช้จ่ายมากกว่าการแก้ไขฟรีมาก

เหตุใดจึงสำคัญ กุญแจพิสูจน์ว่าการเชื่อมต่อกับเว็บไซต์ของคุณเป็นส่วนตัว แต่ไม่ได้ทำอะไรเพื่อควบคุมว่าโค้ดใดรันเมื่อผู้เข้าชมอยู่บนหน้า Content Security Policy คือมาตรการป้องกันที่ทำ — มันบอกเบราว์เซอร์ให้เพิกเฉยสคริปต์ใดๆ ที่ไม่ได้มาจากแหล่งที่คุณไว้วางใจ ดังนั้นฟิลด์ที่ถูกดัดแปลง โฆษณา หรือปลั๊กอินเดียวไม่สามารถเปลี่ยนเป็นเครื่องมือขโมยเงินและข้อมูลของลูกค้าได้ มันเป็นการตรวจสอบที่มีคะแนนบนสกอร์การ์ดของคุณ มีคะแนนจริง และเป็นหนึ่งในสิ่งแรกที่การตรวจสอบความปลอดภัยระดับมืออาชีพมองหา

มันคืออะไรในคำพูดธรรมดา

เมื่อมีคนเข้าเว็บไซต์ของคุณ เบราว์เซอร์ดาวน์โหลดหน้าของคุณและรันโค้ดใดๆ ที่อยู่บนมัน — สคริปต์ที่ทำให้เมนูแสดง ปุ่มทำงาน แบบฟอร์มการชำระเงินส่ง ฯลฯ โดยค่าเริ่มต้น เบราว์เซอร์ไว้วางใจทั้งหมดนั้น ไม่มีทางรู้ว่าโค้ดใดเป็นของคุณจริงๆ และโค้ดใดที่มีคนแอบใส่เข้ามา

Content Security Policy (มักย่อเป็น CSP) คือรายการกฎสั้นๆ ที่เว็บไซต์ของคุณแนบกับทุกหน้า บอกเบราว์เซอร์: “รันโค้ดจากแหล่งเหล่านี้ที่ฉันได้อนุมัติเท่านั้น และปฏิเสธทุกอย่างอื่น” มันความแตกต่างระหว่างไนท์คลับที่ปล่อยให้ทุกคนเข้าและไนท์คลับที่มีรายชื่อผู้เข้าชมที่ประตู

สาเหตุที่สำคัญมากคือเว็บไซต์ถูกดัดแปลงอย่างต่อเนื่อง — ไม่ใช่เสมอผ่านการแฮ็กเซิร์ฟเวอร์ แต่ผ่านประตูหลังที่เว็บไซต์ส่วนใหญ่ทิ้งเปิดไว้: ช่องความคิดเห็น ช่องค้นหา ปลั๊กอินที่ล้าสมัย สคริปต์ของบุคคลที่สามสำหรับโฆษณาหรือการวิเคราะห์ หรือวิดเจ็ตแชท Content Security Policy ปิดประตูนั้นโดยปฏิเสธที่จะรันอะไรก็ตามจากแหล่งที่คุณไม่ได้อนุมัติ

สิ่งนี้อาจทำให้คุณสูญเสียอะไร

นี่ไม่ใช่สิ่งที่เป็นนามธรรม การโจมตีที่ Content Security Policy ป้องกัน — โค้ดที่ฉีดเข้าในหน้าที่ขโมยข้อมูลจากลูกค้าของคุณเอง — อยู่เบื้องหลังการละเมิดการขโมยบัตรที่ใหญ่ที่สุดในบันทึก

• เครื่องข้าม checkout ที่มองไม่เห็น ผู้โจมตีแอบโค้ดไม่กี่บรรทัดบนหน้าชำระเงินผ่านปลั๊กอินที่มีช่องโหว่ หมายเลขบัตรและ CVV ทุกอย่างที่ลูกค้าพิมพ์ถูกคัดลอกและส่งไปยังผู้โจมตีในเวลาจริง เว็บไซต์ของคุณดูและทำงานปกติอย่างสมบูรณ์

• แบบฟอร์มการชำระเงินปลอม นักต้มตุ๋นฉีดกล่อง “ชำระที่นี่” ที่น่าเชื่อถือลงบนเว็บไซต์จริงของคุณ ลูกค้าป้อนรายละเอียดโดยเชื่อถือแบรนด์ของคุณ เงินและข้อมูลไปหาผู้โจมตี

• สัญญาที่หายไป ทีมความปลอดภัยของผู้มีโอกาสเป็นลูกค้ารายใหญ่รันการสแกนอัตโนมัติบนเว็บไซต์ของคุณ Content Security Policy ที่หายไปแสดงขึ้นทันทีเป็นช่องว่างที่มีความรุนแรงสูง

• การละเมิดที่ต้องรายงาน เมื่อการละเมิดข้อมูลถูกติดตามกลับไปยังมาตรการป้องกันมาตรฐานฟรีที่หายไป มันหยุดเป็นโชคร้ายและเริ่มดูเหมือนความประมาท

• โฆษณาหรือวิดเจ็ตที่ถูกบุกรุก หลายเว็บไซต์โหลดโค้ดจากบุคคลภายนอก หากใดหนึ่งในนั้นถูกละเมิด โค้ดที่เป็นอันตรายจะไปที่หน้าของคุณโดยตรง

มันคืออะไรจริงๆ (รายละเอียด)

Content Security Policy ถูกส่งเป็น HTTP response header เดียว ค่าของมันคือชุดของ directives แต่ละอย่างตั้งชื่อประเภทของเนื้อหาและแหล่งที่มาที่ได้รับอนุญาต ตัวอย่าง:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

ในคำพูดธรรมดา นั่นหมายความว่า: โดยค่าเริ่มต้นโหลดเฉพาะสิ่งต่างๆ จากเว็บไซต์ของฉันเอง รันสคริปต์จากเว็บไซต์ของฉันเอง ไม่อนุญาตปลั๊กอินเก่า และไม่ให้เว็บไซต์อื่นฝังของฉันในเฟรม

สิ่งที่ “ดี” ดูเหมือน นโยบายที่แข็งแกร่ง:

• ตั้งฐานที่ จำกัด (default-src 'self') และขยายเฉพาะสำหรับบุคคลที่สามที่เชื่อถือได้เฉพาะที่คุณใช้จริงๆ
• หลีกเลี่ยงช่องโหว่ ไม่ใช้ 'unsafe-inline' หรือ 'unsafe-eval' สำหรับสคริปต์ และไม่ใช้ wildcard (*) หรือแหล่งที่มาแบบ scheme ล้วน
• ล็อกการแสดงผลในเฟรมด้วย frame-ancestors 'self' และปิดใช้งานปลั๊กอินเก่าด้วย object-src 'none'
• บังคับใช้ ไม่ใช่ report-only header Content-Security-Policy-Report-Only เฝ้าดูเท่านั้น ไม่ให้การป้องกันรันไทม์

วิธีแก้ไข (ฟรี ประมาณ 1–2 ชั่วโมง)

ส่งสิ่งนี้ให้ฝ่าย IT หรือใครก็ตามที่รันเว็บไซต์ของคุณ — การแก้ไขเองฟรีอย่างสมบูรณ์ เราเรียกเก็บเงินสำหรับการตรวจสอบว่ามันยังคงอยู่และถูกต้องตามเวลาเท่านั้น สาเหตุที่ใช้เวลาหนึ่งหรือสองชั่วโมงแทนที่จะเป็นนาทีคือขั้นตอนทดลองอย่างระมัดระวังที่หยุดไม่ให้บล็อกส่วนต่างๆ ของเว็บไซต์ของคุณเองโดยไม่ตั้งใจ

1. เริ่มในโหมด report-only — อย่าบังคับใช้ก่อน เพิ่ม header Content-Security-Policy-Report-Only สิ่งนี้เฝ้าดูและบันทึกสิ่งที่จะถูกบล็อกโดยไม่บล็อกอะไรจริงๆ (สำคัญ: report-only ด้วยตัวเองไม่ให้การป้องกันผู้เข้าชม)

2. สร้างนโยบายจากสิ่งที่เว็บไซต์ของคุณใช้จริงๆ ตรวจสอบรายงานเพื่อค้นหาทุกแหล่งที่มาที่ถูกต้องของสคริปต์ สไตล์ ฟอนต์ และรูปภาพ

3. หลีกเลี่ยงช่องโหว่ที่ขัดกับจุดประสงค์ทั้งหมด หลีกเลี่ยง 'unsafe-inline' และ 'unsafe-eval' สำหรับสคริปต์ และหลีกเลี่ยงแหล่ง wildcard

4. ล็อกการแสดงผลในเฟรมและปลั๊กอิน เพิ่ม frame-ancestors 'self' และ object-src 'none'

5. สลับจาก report-only เป็นบังคับใช้ เมื่อรายงานสะอาดและเว็บไซต์ทำงาน เปลี่ยนชื่อ header จาก Content-Security-Policy-Report-Only เป็น Content-Security-Policy นี่คือขั้นตอนที่ให้การป้องกันจริง

   ตั้ง header:

   • Cloudflare: Rules → Transform Rules → Modify Response Header
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"

6. ตรวจสอบโดเมนของคุณใหม่ ยืนยันว่านโยบายแสดงว่าเปิดและบังคับใช้ โดยไม่มีช่องโหว่ที่อ่อนแอ

ข้อผิดพลาดทั่วไป

• หยุดที่ report-only ข้อผิดพลาดเดียวที่พบบ่อยที่สุด: นโยบายถูกเพิ่มในโหมด report-only ทุกคนก้าวต่อไป และเว็บไซต์ไม่ได้รับการป้องกันจริงๆ เลย Report-only ไม่บล็อกอะไร คุณต้องสลับไปยังการบังคับใช้
• ใช้ 'unsafe-inline' เพื่อทำให้ “แค่ทำงาน” เมื่อนโยบายบล็อกสคริปต์ inline ที่ถูกกฎหมาย การแก้ไขด่วนคืออนุญาตสคริปต์ inline ทั้งหมด — แต่นั่นเปิดช่องโหว่ที่นโยบายควรปิดอีกครั้ง ใช้ nonce หรือ hash แทน
• ใช้ wildcard เครื่องหมาย * ล้วน (หรือ https:) ใน script-src อนุญาตสคริปต์จากทุกที่ ซึ่งหมายความว่านโยบายให้การป้องกันน้อยมากและยังคงให้คะแนนต่ำ
• ลืมแหล่งที่มาของบุคคลที่สาม การบังคับใช้นโยบายที่เข้มงวดโดยไม่แสดงรายการบริการภายนอกที่ถูกกฎหมายที่คุณใช้สามารถทำลายส่วนต่างๆ ของเว็บไซต์ของคุณเอง
• ตั้งมันเฉพาะบนหน้าแรก นโยบายต้องครอบคลุมทุกหน้า โดยเฉพาะหน้าชำระเงิน เข้าสู่ระบบ และบัญชี
• ถือว่ามันแทนที่กุญแจ Content Security Policy และ HTTPS/HSTS ปกป้องสิ่งต่างๆ คุณต้องการทั้งหมด

คำถามที่พบบ่อย