Bộ tạo CSP — Chính sách bảo mật nội dung, các điểm nguy hiểm được đánh dấu
Bộ tạo CSP
Chọn các chỉ thị và nguồn, và trang này sẽ lắp ghép một Content-Security-Policy một dòng đúng cho tiêu đề phản hồi hoặc thẻ <meta> của bạn — cùng các ghi chú quan trọng: chỉ thị nào không bao giờ quay vềdefault-src, khi nào một hash hoặc nonce âm thầm ghi đè unsafe-inline, và strict-dynamic tắt những gì. Bộ tạo hash SHA-256/384/512 tích hợp sẵn chuyển script và style nội tuyến thành nguồn 'sha256-…'. Mọi thứ chạy trong trình duyệt của bạn; không có gì được tải lên.
Chỉ thị fetch — nội dung có thể đến từ đâu
Các chỉ thị không được chọn đơn giản là không có trong chính sách; một ô được chọn mà không có nguồn nào thì bị bỏ qua. 'none' hủy các ô khác trong cùng hàng. Hộp nguồn bổ sung nhận danh sách cách nhau bằng dấu phẩy: tên máy chủ (cdn.example.com), lược đồ (https:), hash và nonce có hoặc không có dấu nháy.
chỉ thị
'self'
'none'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
data:
blob:
nguồn bổ sung
Chỉ thị tài liệu — trang tự nó được làm gì
Bốn chỉ thị này không quay về default-src: bỏ chúng đi nghĩa là “không hạn chế”, nên một chính sách đầy đủ phải đặt chúng một cách rõ ràng.
chỉ thị
'self'
'none'
nguồn bổ sung
Công tắc, nonce và báo cáo
nonce cho script
report-uri
report-to
Chính sách
Chưa có gì được tạo. Chọn một số nguồn và nhấn Tạo chính sách, hoặc tải mẫu chuẩn OWASP.
Bộ tạo hash cho script và style nội tuyến
Dán đúng nội dung nằm giữa <script> và </script> (hoặc khối style) — từng byte, không có xuống dòng đầu hay cuối — rồi chọn thuật toán. Kết quả là nguồn 'sha256-…' mà CSP 3 cần.
Kết quả hash sẽ hiển thị ở đây.
Triển khai dưới dạng tiêu đề, không phải thẻ meta, bất cứ khi nào có thể. Tiêu đề phản hồi là CSP đầy đủ: frame-ancestors, report-uri và report-to chỉ hoạt động ở đó, và tiêu đề được áp dụng trước byte HTML đầu tiên được phân tích. Thẻ meta là phương án dự phòng cho tệp tĩnh không có cấu hình máy chủ. Kiểm tra các tiêu đề mà trang của bạn thực sự gửi tại công cụ kiểm tra tiêu đề bảo mật, và phân tích các khối phản hồi thô tại bộ phân tích tiêu đề HTTP.
Tự kiểm tra Chạy lại bộ dựng với các trạng thái cố định: thứ tự nguồn, quan hệ loại trừ của 'none', chuỗi mẫu OWASP, cách đặt dấu nháy cho nonce và hash, các ghi chú không có mức quay về cho base-uri / form-action / frame-ancestors, unsafe-inline bị nonce hoặc hash ghi đè, các ghi chú strict-dynamic, tên tiêu đề Report-Only, các mục bị loại khỏi thẻ meta, bộ tạo hash đối chiếu với các vector SHA tính độc lập, và các đường đi tiêu cực. Không gửi gì đi đâu cả.
Chính sách bảo mật nội dung là gì?
Trong một câu: CSP là một danh sách cho phép mà máy chủ gửi kèm trang, cho trình duyệt biết chính xác script, style, ảnh và kết nối có thể đến từ đâu — nên dù kẻ tấn công chèn HTML, script được chèn vẫn không tải được, vì nguồn của nó không nằm trong danh sách.
có — chỉ thị không được chọn sẽ kế thừa default-src
Chỉ thị tài liệu
base-uri, form-action, frame-ancestors, sandbox
chính trang có thể làm gì (được nhúng, gửi biểu mẫu tới đâu, phân giải URL tương đối thế nào)
không — mỗi chỉ thị phải được đặt rõ ràng
Báo cáo và các mục khác
report-uri, report-to, upgrade-insecure-requests
báo cáo vi phạm được gửi đi đâu, và việc nâng cấp URL cũ
không (chúng không phải chỉ thị fetch)
Các điểm sắc nhất, mỗi mục một đoạn
'unsafe-inline' so với hash và nonce. Nếu một chỉ thị chứa nonce hoặc bất kỳ nguồn hash nào, CSP 3 nói 'unsafe-inline' bị bỏ qua — nó chỉ còn đó cho trình duyệt rất cũ. Đó là lý do “chúng tôi đã thêm nonce và giữ unsafe-inline cho an toàn” thực ra có nghĩa là trình duyệt hiện đại thi hành nonce. Bộ tạo đánh dấu tổ hợp này để nó là một quyết định, không phải tai nạn.
strict-dynamic vô hiệu hóa danh sách cho phép của bạn. Với strict-dynamic trong script-src, các nguồn máy chủ, lược đồ, 'self', 'unsafe-inline' và data: đều bị bỏ qua đối với script; chỉ nonce và hash có ý nghĩa, và các script mà chúng tải có thể tải thêm script. Đó là cách hiện đại để chạy các script nạp — nhưng khi đó phần còn lại của danh sách script-src chỉ còn là trang trí.
Thẻ meta là hạng hai.frame-ancestors, report-uri và report-to bị bỏ qua trong <meta http-equiv>. Bộ tạo cho thấy những phần nào của chính sách sẽ âm thầm không áp dụng.
Những lỗi thường gặp
Bắt đầu với default-src * cộng một danh sách dài ngoại lệ. Hãy làm ngược lại: một default-src 'self' chặt, rồi chỉ nới các chỉ thị cần nới. Chính sách hẹp báo lỗi rõ ràng khi kiểm thử; chính sách rộng hỏng âm thầm mãi mãi.
Triển khai script-src 'unsafe-inline' 'unsafe-eval' rồi cho là xong. Chính sách đó hầu như không chặn điều một tấn công XSS muốn làm. Hãy gắn nonce hoặc hash cho script, thêm strict-dynamic, và giữ report-only chạy trong môi trường production để bắt các hồi quy.
Quên rằng default-src không bao phủ mọi thứ.base-uri, form-action, frame-ancestors và sandbox không có mức dự phòng — đây là lỗ hổng được nhắc đến nhiều nhất trong các triển khai CSP thực tế.
Kiểm thử ở chế độ enforce trước. Chạy ở Report-Only với một bộ thu nhận trong một tuần, đọc báo cáo, rồi chuyển sang thực thi. Một chính sách làm hỏng thanh toán còn tệ hơn không có chính sách.
Băm khoảng trắng khác nhau. Hash bao phủ đúng byte của khối nội tuyến; một bước build “hữu ích” cắt các xuống dòng cuối sẽ làm thay đổi mọi hash. Hãy tạo hash từ những gì được triển khai, không phải từ mã nguồn.
Câu hỏi thường gặp
Tôi có cần default-src nếu liệt kê mọi chỉ thị không? Không, nhưng giữ nó làm mức sàn là thói quen tốt: các chỉ thị fetch mới trong trình duyệt tương lai khi đó sẽ mặc định theo mức nền của bạn thay vì “được phép”.
Thực sự upgrade-insecure-requests làm gì? Nó bảo trình duyệt viết lại mọi URL http:// mà trang sẽ tải — ảnh, style, fetch — thành https:// trước khi yêu cầu. Đó là công cụ di chuyển; trạng thái cuối là các trang không còn URL http:// nào.
Nonce hay hash? Nonce khi bạn kiểm soát phản hồi máy chủ (một giá trị ngẫu nhiên cho mỗi phản hồi, vừa trong tiêu đề vừa trong mỗi thẻ script). Hash khi HTML là tĩnh hoặc được lưu đệm. Không bao giờ dùng nonce tĩnh — nonce không đổi chỉ là unsafe-inline mặc với thêm bước.
Vì sao chính sách của tôi đã được gửi nhưng các vi phạm không đến? Kiểm tra xem bạn có đang ở chế độ Report-Only (chỉ báo cáo) không, report-uri có trỏ đến bộ thu nhận chấp nhận POST không, và bạn đã đặt cơ chế Reporting-Endpoints / Report-To mà chỉ thị report-to hiện đại cần hay chưa.
CSP có thay thế các bảo vệ khác không? Không. Nó chỉ là một lớp: vẫn escape đầu ra, giữ cookie sau HttpOnly và Secure, giữ HSTS. Công cụ kiểm tra tiêu đề bảo mật trên trang này chấm toàn bộ bộ tiêu đề.