Skip to main content

เนื้อหาภาษาไทย / Thai content

System guide Content reviewed

การใช้ Content Security Policy (CSP)

บทความนี้กล่าวถึง Content Security Policy (CSP) ซึ่งเป็นกลไกสำคัญในการป้องกันเว็บไซต์จากการโจมตี Cross-Site Scripting (XSS) โดย CSP ช่วยควบคุมแหล่งที่มาของทรัพย...

การใช้ Content Security Policy (CSP)

หลังจากที่เราได้เรียนรู้เกี่ยวกับการตรวจสอบความปลอดภัยของฐานข้อมูล (Monitoring Database Security) ในบทความก่อนหน้าแล้ว อีกหนึ่งมาตรการสำคัญในการป้องกันเว็บไซต์ของเราจากการโจมตีคือการใช้ Content Security Policy (CSP) ซึ่งเป็นกลไกที่ช่วยควบคุมแหล่งที่มาของทรัพยากรต่างๆ ที่เว็บไซต์ของเราสามารถโหลดได้ เช่น สคริปต์ รูปภาพ สไตล์ชีต และอื่นๆ การใช้งาน CSP อย่างถูกต้องจะช่วยลดความเสี่ยงจาก Cross-Site Scripting (XSS) ได้อย่างมีประสิทธิภาพ

CSP คืออะไร?

Content Security Policy (CSP) คือ HTTP header ที่ช่วยให้เรากำหนดนโยบายความปลอดภัยสำหรับเว็บไซต์ของเรา โดยการระบุแหล่งที่มาที่เว็บไซต์สามารถโหลดทรัพยากรได้ หากเบราว์เซอร์ตรวจพบว่าทรัพยากรใดๆ ที่พยายามโหลดไม่ได้อยู่ในรายการที่อนุญาต เบราว์เซอร์จะบล็อกการโหลดทรัพยากรนั้น และอาจรายงานการละเมิดนโยบาย (CSP violation) ไปยังเซิร์ฟเวอร์

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

ทำไมต้องใช้ CSP?

เหตุผลหลักในการใช้ CSP คือการป้องกัน Cross-Site Scripting (XSS) ซึ่งเป็นช่องโหว่ที่ผู้โจมตีสามารถแทรกสคริปต์ที่เป็นอันตรายเข้าไปในเว็บไซต์ของเราได้ เมื่อผู้ใช้เข้าชมเว็บไซต์ สคริปต์ที่เป็นอันตรายจะถูกรันในเบราว์เซอร์ของผู้ใช้ ทำให้ผู้โจมตีสามารถเข้าถึงข้อมูลส่วนตัวของผู้ใช้ หรือทำการเปลี่ยนแปลงบนเว็บไซต์ในนามของผู้ใช้ได้

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

การตั้งค่า CSP header

การตั้งค่า CSP ทำได้โดยการเพิ่ม HTTP header ชื่อ Content-Security-Policy ลงใน response header ของเว็บไซต์ของเรา ค่าของ header นี้จะเป็นสตริงที่ประกอบด้วย directives ต่างๆ ที่กำหนดนโยบายความปลอดภัย

รูปแบบทั่วไปของ CSP header คือ:

Content-Security-Policy: directive1 value1; directive2 value2; ...

โดยที่ directive คือคำสั่งที่กำหนดนโยบาย และ value คือค่าที่ระบุแหล่งที่มาที่อนุญาต

ตัวอย่างเช่น หากเราต้องการอนุญาตให้โหลดสคริปต์จากโดเมนของตัวเอง ('self') และจาก https://cdn.example.com เราสามารถตั้งค่า CSP header ได้ดังนี้:

Content-Security-Policy: script-src 'self' https://cdn.example.com;

ใน PHP เราสามารถตั้งค่า CSP header ได้โดยใช้ฟังก์ชัน header():

<?php
header("Content-Security-Policy: script-src 'self' https://cdn.example.com;");
?>

Directives ที่สำคัญ

ต่อไปนี้คือ directives ที่สำคัญบางส่วนที่ใช้ในการตั้งค่า CSP:

  • default-src: กำหนดแหล่งที่มาเริ่มต้นสำหรับทรัพยากรทั้งหมด หากไม่ได้กำหนด directive เฉพาะสำหรับทรัพยากรนั้นๆ
  • script-src: กำหนดแหล่งที่มาที่อนุญาตสำหรับสคริปต์
  • style-src: กำหนดแหล่งที่มาที่อนุญาตสำหรับสไตล์ชีต
  • img-src: กำหนดแหล่งที่มาที่อนุญาตสำหรับรูปภาพ
  • connect-src: กำหนดแหล่งที่มาที่อนุญาตสำหรับการเชื่อมต่อเครือข่าย (เช่น AJAX, WebSocket)
  • font-src: กำหนดแหล่งที่มาที่อนุญาตสำหรับฟอนต์
  • media-src: กำหนดแหล่งที่มาที่อนุญาตสำหรับไฟล์เสียงและวิดีโอ
  • object-src: กำหนดแหล่งที่มาที่อนุญาตสำหรับปลั๊กอิน (เช่น Flash)
  • base-uri: กำหนด URI ที่อนุญาตให้ใช้ในแท็ก <base>
  • form-action: กำหนด URI ที่อนุญาตให้ส่งฟอร์ม
  • frame-ancestors: กำหนดแหล่งที่มาที่อนุญาตให้ฝังเว็บไซต์ของเราใน <frame>, <iframe>, หรือ <object>
  • report-uri: กำหนด URI ที่เบราว์เซอร์จะส่งรายงานการละเมิดนโยบาย (CSP violation)

ค่าที่ใช้กับ directives เหล่านี้อาจเป็น:

  • 'self': โดเมนปัจจุบัน
  • 'none': ไม่อนุญาตให้โหลดทรัพยากรใดๆ
  • 'unsafe-inline': อนุญาตให้ใช้สคริปต์และสไตล์ชีตแบบ inline (ไม่แนะนำ)
  • 'unsafe-eval': อนุญาตให้ใช้ฟังก์ชัน eval() (ไม่แนะนำ)
  • data:: อนุญาตให้ใช้ data URI (เช่น รูปภาพที่ฝังอยู่ใน HTML)
  • https://example.com: โดเมนที่ระบุ

ตัวอย่างการตั้งค่า CSP

ต่อไปนี้คือตัวอย่างการตั้งค่า CSP ที่ครอบคลุมมากขึ้น:

<?php
header("Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' data:; font-src 'self' https://fonts.gstatic.com; connect-src 'self'; report-uri /csp-report.php;");
?>

ในตัวอย่างนี้:

  • default-src 'self': อนุญาตให้โหลดทรัพยากรทั้งหมดจากโดเมนของตัวเองเป็นค่าเริ่มต้น
  • script-src 'self' https://cdn.example.com: อนุญาตให้โหลดสคริปต์จากโดเมนของตัวเองและ https://cdn.example.com
  • style-src 'self' https://fonts.googleapis.com: อนุญาตให้โหลดสไตล์ชีตจากโดเมนของตัวเองและ https://fonts.googleapis.com
  • img-src 'self' data:: อนุญาตให้โหลดรูปภาพจากโดเมนของตัวเองและ data URI
  • font-src 'self' https://fonts.gstatic.com: อนุญาตให้โหลดฟอนต์จากโดเมนของตัวเองและ https://fonts.gstatic.com
  • connect-src 'self': อนุญาตให้ทำการเชื่อมต่อเครือข่ายจากโดเมนของตัวเอง
  • report-uri /csp-report.php: กำหนดให้เบราว์เซอร์ส่งรายงานการละเมิดนโยบายไปยัง /csp-report.php

การรายงาน CSP violation

เมื่อเบราว์เซอร์ตรวจพบการละเมิดนโยบาย CSP เบราว์เซอร์จะส่งรายงานไปยัง URI ที่ระบุใน directive report-uri รายงานนี้จะเป็น JSON object ที่มีข้อมูลเกี่ยวกับการละเมิด เช่น URI ของทรัพยากรที่ถูกบล็อก และ directive ที่ถูกละเมิด

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

ตัวอย่างโค้ด PHP สำหรับจัดการรายงาน CSP violation (csp-report.php):

<?php
$report = json_decode(file_get_contents('php://input'), true);

if ($report && isset($report['csp-report'])) {
  // Log the CSP violation
  error_log("CSP Violation: " . json_encode($report['csp-report']));

  // You might also want to send an email notification
  // mail('admin@example.com', 'CSP Violation', json_encode($report['csp-report']));
}
?>

โค้ดนี้จะอ่าน JSON object จาก request body และบันทึกข้อมูลการละเมิดนโยบายลงใน log file นอกจากนี้เรายังสามารถส่งอีเมลแจ้งเตือนไปยังผู้ดูแลระบบได้

ข้อควรระวังในการใช้งาน CSP

การตั้งค่า CSP อาจทำให้เว็บไซต์ของเราทำงานผิดปกติได้ หากเราไม่ได้กำหนดนโยบายอย่างถูกต้อง ตัวอย่างเช่น หากเราบล็อกการโหลดสคริปต์จาก CDN ที่เราใช้ เว็บไซต์ของเราอาจแสดงผลไม่ถูกต้อง

ดังนั้น เราควรทดสอบ CSP อย่างละเอียดก่อนที่จะนำไปใช้ใน production environment เราสามารถใช้เครื่องมือต่างๆ เช่น CSP Evaluator เพื่อช่วยในการตรวจสอบและปรับปรุงนโยบาย CSP ของเรา

นอกจากนี้ เราควรเริ่มต้นด้วยนโยบายที่ผ่อนคลายก่อน และค่อยๆ เพิ่มความเข้มงวดขึ้นเมื่อเรามั่นใจว่าเว็บไซต์ของเราทำงานได้อย่างถูกต้อง

สรุป

Content Security Policy (CSP) เป็นเครื่องมือที่มีประสิทธิภาพในการป้องกัน Cross-Site Scripting (XSS) โดยการควบคุมแหล่งที่มาของทรัพยากรต่างๆ ที่เว็บไซต์ของเราสามารถโหลดได้ การตั้งค่า CSP อย่างถูกต้องจะช่วยลดความเสี่ยงจาก XSS และเพิ่มความปลอดภัยให้กับเว็บไซต์ของเรา

ในบทความถัดไป เราจะพูดถึง Subresource Integrity (SRI) ซึ่งเป็นอีกหนึ่งมาตรการที่ช่วยให้เรามั่นใจได้ว่าทรัพยากรที่เราโหลดจาก CDN ไม่ถูกแก้ไขโดยผู้โจมตี

Office.in.th Custom Service

Want to build or adapt a system from this structure?

Office.in.th designs and develops enterprise web applications, API integrations, and public- and private-sector management systems, with long-term support.

See our software development service