Defaults.Exposed

Defaults.Exposed › Cách khắc phục › Content-Security-Policy (CSP)

Cách khắc phục Content-Security-Policy (CSP)

Content Security Policy là bộ quy tắc an toàn website của bạn trao cho trình duyệt mỗi khách truy cập, nói chính xác mã nào được phép chạy. Không có nó, nếu có thứ gì độc hại vào trang — qua hộp bình luận, plugin bị tấn công, hoặc script bên thứ ba — trình duyệt sẽ chạy nó tự do, kể cả mã lặng lẽ skim số thẻ và mật khẩu của khách hàng khi họ gõ, trong khi ổ khóa vẫn hiển thị.

Điểm mấu chốt với doanh nghiệp bạn: Nếu website bị can thiệp, mã độc có thể đọc thông tin thẻ thanh toán và đăng nhập của khách hàng ngay trên trang thanh toán của bạn trong khi mọi thứ trông hoàn toàn bình thường — để lại cho bạn chargeback, khiếu nại gian lận, vi phạm dữ liệu phải báo cáo, và lỗi kiểm tra mà nhóm bảo mật của khách hàng lớn hơn dùng để đình trệ hoặc hủy thỏa thuận.

Điều này có thể gây thiệt hại gì

Tại sao điều này quan trọng. Ổ khóa chứng minh kết nối đến website của bạn là riêng tư, nhưng nó không làm gì để kiểm soát mã nào chạy khi khách truy cập đang trên trang. Content Security Policy là biện pháp bảo vệ làm điều đó — nó nói với trình duyệt bỏ qua bất kỳ script nào không đến từ nguồn bạn tin tưởng, vì vậy một trường bị can thiệp, quảng cáo, hoặc plugin không thể trở thành công cụ ăn cắp tiền và dữ liệu khách hàng. Đây là kiểm tra có điểm trên scorecard của bạn, đáng điểm thật, và là một trong những thứ đầu tiên đánh giá bảo mật chuyên nghiệp tìm kiếm.

Thực ra là gì, giải thích đơn giản

Khi ai đó truy cập website của bạn, trình duyệt tải trang và chạy bất kỳ mã nào trên đó — các script làm menu thả xuống, nút hoạt động, form thanh toán gửi, v.v. Theo mặc định, trình duyệt tin tưởng tất cả. Nó không có cách nào biết mã nào thực sự là của bạn và mã nào bị ai đó khác lén vào.

Content Security Policy (thường viết tắt là CSP) là danh sách ngắn quy tắc website của bạn gắn vào mỗi trang, nói với trình duyệt: “chỉ chạy mã từ các nguồn tôi đã phê duyệt, và từ chối mọi thứ khác.” Đó là sự khác biệt giữa hộp đêm cho phép bất kỳ ai vào và hộp đêm có danh sách khách mời ở cửa.

Lý do điều này quan trọng đến vậy là website bị can thiệp liên tục — không phải lúc nào cũng bằng cách tấn công máy chủ của bạn, mà qua cửa sau hầu hết website để mở: hộp bình luận, ô tìm kiếm, plugin lỗi thời, script bên thứ ba cho quảng cáo hoặc analytics, hoặc widget chat. Nếu kẻ tấn công đưa được dù chỉ một dòng mã của chúng vào một trong các trang của bạn, trình duyệt chạy nó như thể là của bạn. Từ đó nó có thể đọc mọi thứ khách hàng gõ — số thẻ, mật khẩu, địa chỉ — và lặng lẽ gửi đi nơi khác. Content Security Policy đóng cửa đó bằng cách từ chối chạy bất cứ thứ gì từ nguồn bạn không phê duyệt.

Điều này có thể khiến bạn mất gì

Đây không phải trừu tượng. Cuộc tấn công mà Content Security Policy ngăn chặn — mã được chèn vào trang đánh cắp dữ liệu từ chính khách hàng của bạn — là nguyên nhân đằng sau một số vi phạm skimming thẻ lớn nhất trong lịch sử. Đây là cách nó thường diễn ra với doanh nghiệp bình thường:

Thực ra nó là gì (chi tiết)

Content Security Policy được gửi như một HTTP response header duy nhất — một dòng máy chủ web của bạn gửi với mỗi trang. Giá trị của nó là một tập chỉ thị, mỗi cái đặt tên một loại nội dung và các nguồn được phép cho nó. Ví dụ:

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

Nói đơn giản, điều đó có nghĩa: theo mặc định chỉ tải thứ từ tên miền của chính tôi; chỉ chạy script từ tên miền của chính tôi; không cho phép plugin kiểu cũ; và không để trang khác nhúng trang của tôi vào frame.

“Tốt” trông như thế nào. Kiểm tra của chúng tôi không chỉ tìm sự có mặt của header — nó đọc từng chỉ thị chính sách và tính điểm mạnh thực sự của nó như người đánh giá bảo mật sẽ làm. Chính sách mạnh:

Chính sách tồn tại nhưng dựa vào 'unsafe-inline', 'unsafe-eval', hoặc wildcard vẫn sẽ điểm kém — vì trong thực tế nó cung cấp ít bảo vệ thật. Mục tiêu là chính sách chặt chẽ, không chỉ bất kỳ chính sách nào.

Cách sửa (miễn phí, ~1–2 giờ)

Chuyển cho người IT của bạn hoặc người chạy website — bản sửa hoàn toàn miễn phí. Chúng tôi chỉ tính phí để theo dõi rằng nó luôn được bật và đúng theo thời gian; bật nó không tốn gì. Lý do điều này mất một hoặc hai giờ thay vì vài phút là bước thử nghiệm cẩn thận ngăn nó vô tình chặn các phần của chính website bạn.

  1. Bắt đầu ở chế độ chỉ-báo-cáo — chưa thực thi. Thêm response header Content-Security-Policy-Report-Only. Điều này theo dõi và ghi nhật ký những gì sẽ bị chặn mà không thực sự chặn gì, vì vậy trang live vẫn hoạt động trong khi bạn tìm hiểu mỗi trang phụ thuộc vào gì. (Quan trọng: chỉ-báo-cáo không cung cấp bảo vệ nào cho khách truy cập — đó chỉ là bước đầu tiên an toàn.)

  2. Xây dựng chính sách từ những gì website thực sự dùng. Xem xét báo cáo để tìm mọi nguồn script, style, font, và hình ảnh hợp lệ — tên miền của bạn, analytics, nhà cung cấp thanh toán, host font, widget chat — và liệt kê chúng là nguồn được phép. Điểm bắt đầu vững chắc là default-src 'self' cộng với các mục rõ ràng cho các bên thứ ba đáng tin bạn thực sự dùng.

  3. Tránh các lỗ hổng đánh bại toàn bộ mục đích. Tránh 'unsafe-inline' và 'unsafe-eval' cho script, và tránh nguồn wildcard như * và scheme bare như https: cho script — chúng mở lại chính xác khoảng cách mà chính sách muốn đóng. Khi script inline không thể tránh khỏi, dùng nonce hoặc hash để chỉ mã được phê duyệt cụ thể của bạn chạy.

  4. Khóa framing và plugin. Thêm frame-ancestors 'self' (điều này cũng ngăn các trang khác nhúng trang của bạn để lừa khách hàng, và nó thỏa mãn kiểm tra clickjacking liên quan) và object-src 'none' để chặn tấn công dựa trên plugin cũ.

  5. Chuyển từ chỉ-báo-cáo sang thực thi. Sau khi báo cáo sạch và website hoạt động, thay tên header từ Content-Security-Policy-Report-Only thành Content-Security-Policy. Đây là bước thực sự mang lại bảo vệ — chính sách chỉ-báo-cáo đơn lẻ không làm vậy, và sẽ không vượt qua kiểm tra.

    Nơi bạn đặt header phụ thuộc vào nền tảng:

    • Cloudflare: Rules → Transform Rules → Modify Response Header → đặt Content-Security-Policy.
    • 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';"
    • IIS (web.config): thêm HTTP response header tùy chỉnh tên Content-Security-Policy với chính sách là giá trị của nó.
    • Google Workspace / Microsoft 365: những thứ này chạy email của bạn, không phải website công khai, vì vậy chính sách được đặt bất cứ nơi nào website của bạn thực sự được lưu trữ (Cloudflare hoặc web host ở trên), không phải trong console admin email.

  6. Kiểm tra lại tên miền để xác nhận chính sách giờ hiển thị là đang bật và thực thi, không có lỗ hổng làm yếu.

Các lỗi phổ biến

FAQ

Tôi không rành kỹ thuật — tôi có thể tự xử lý điều này không?

Bạn không cần hiểu các chi tiết. Đây là cài đặt được thêm bởi người chạy website hoặc hosting của bạn, và trên dịch vụ như Cloudflare nó được hướng dẫn phần lớn. Chuyển phần 'Cách sửa' bên dưới cho họ. Miễn phí; thận trọng duy nhất là nên triển khai cẩn thận trong thử nghiệm chỉ-theo-dõi trước để không vô tình chặn các phần của chính website bạn — đó chính xác là những gì các bước bao gồm.

Tôi đã có ổ khóa và chứng chỉ SSL — website tôi không an toàn sao?

Ổ khóa bảo vệ việc gửi trang của bạn; nó không kiểm soát những gì chạy bên trong nó. Nếu mã độc vào trang — qua plugin bị tấn công, quảng cáo bị xâm phạm, hoặc trường bị chèn vào — ổ khóa không ngăn nó đánh cắp dữ liệu. Content Security Policy là lớp giới hạn những gì được phép chạy ngay từ đầu. Chúng bảo vệ những thứ khác nhau, và bạn muốn cả hai.

Bật cái này có thể phá website của tôi không?

Có thể nếu bật tích cực ngay lập tức, vì nó có thể chặn các script hợp lệ bạn thực sự dùng. Đó là lý do tại sao cách tiếp cận tiêu chuẩn là bắt đầu ở chế độ thử nghiệm 'chỉ-báo-cáo' theo dõi mà không chặn, sửa bất cứ thứ gì nó gắn cờ, và chỉ sau đó thực thi. Làm theo cách này thì an toàn — và bước thử nghiệm được tích hợp vào phần sửa bên dưới.

Chúng tôi đã đặt nó ở chế độ 'chỉ-báo-cáo' rồi — chúng tôi đã được bảo vệ chưa?

Chưa, và đây là cảm giác an toàn giả phổ biến nhất. Chế độ chỉ-báo-cáo theo dõi và ghi nhật ký những gì sẽ bị chặn, nhưng nó không chặn gì — khách truy cập không có bảo vệ thật. Đó chỉ là bước đầu tiên an toàn. Kiểm tra của chúng tôi trao cho chỉ-báo-cáo một phần nhỏ tín dụng của chính sách thật và sẽ không ghi nhận là đạt. Bạn chỉ được bảo vệ khi chuyển sang chế độ thực thi.

Điều này có ảnh hưởng điểm của chúng tôi không, hay chỉ là tư vấn?

Ảnh hưởng điểm của bạn. Kiểm tra Content Security Policy được tính điểm và đáng đến 25 điểm trong danh mục Bảo mật Web. Chính sách thiếu hoặc yếu được đánh dấu nghiêm trọng cao và kéo điểm xuống — và đây chính xác là loại khoảng cách bảng câu hỏi bảo mật của khách hàng hỏi.

Nhà phát triển của chúng tôi đã thêm chính sách nhưng điểm vẫn thấp — tại sao?

Chính sách có thể tồn tại và vẫn yếu. Thủ phạm phổ biến nhất là lỗ hổng như 'unsafe-inline' và 'unsafe-eval' cho script, hoặc nguồn wildcard (bare *), chúng mở lại chính xác khoảng cách mà chính sách muốn đóng. Kiểm tra của chúng tôi đọc từng chỉ thị chính sách và tính điểm thấp hơn cho những điểm yếu đó — chính sách cho phép bất cứ thứ gì điểm không tốt hơn không có gì nhiều. Bản sửa là siết chặt quy tắc script bằng nonces hoặc hash thay vì những lỗ hổng đó.