Cùng Mi2 tìm hiểu Content Security Policy (CSP) là gì, lợi ích của việc sử dụng CSP. Cũng như cách nó hoạt động để bảo vệ trang Web.
Content Security Policy, viết tắt CSP là một giao thức cho phép chủ sở hữu trang Web kiểm soát những tài nguyên (Resources). Được trình duyệt tải trên trang và cách những tài nguyên đó có thể được tải. Giao thức này được phát triển chủ yếu để giảm thiểu tác động của lỗ hổng Cross-site Scripting (XSS). Để tìm hiểu chi tiết về khái niệm này cũng như cách CSP hoạt động để bảo vệ trang Web, đừng bỏ qua bài viết dưới đây!
1. Content Security Policy – CSP là gì?
Content Security Policy (CSP) là một chuỗi lệnh thông báo cho trình duyệt. Về tất cả các vị trí mà Author ứng dụng Web lường trước sẽ có nội dung.
Về cơ bản, CSP hoạt động như một Allowlist (danh sách được phép) nội dung an toàn cho DOM (Document Object Model – mô hình các đối tượng tài liệu). Bên cạnh việc hạn chế JavaScript nội tuyến – khía cạnh quan trọng nhất của CSP. Nó có thể định rõ nhiều loại hạn chế nội dung khác. Bao gồm nguồn CSS, nguồn iFrame hợp lệ, các loại Plugin hợp lệ cần được hỗ trợ hoặc không (chẳng hạn như Flash). Và các điểm đến (Destinations) Websocket đã được phê duyệt.
CSP không ngăn XSS. Điều này thể hiện ở việc nó không hoạt động để chặn đầu vào độc hại được Render trong DOM. Những gì nó làm là giảm thiểu tác động của tấn công XSS. Bằng cách hướng dẫn trình duyệt không thực thi các Script không được cho phép rõ ràng.
2. Lợi ích của CSP
Content Security Policy – CSP chủ yếu hạn chế các nguồn, các loại nội dung và vị trí trong trang mà nội dung có thể được hiển thị (Presented) hoặc Render.
Về mặt ngăn chặn XSS, JavaScript nội tuyến có xu hướng là Vectơ chính cho nội dung độc hại. JavaScript nội tuyến là khi Code được đặt trong thẻ “<script>” trong phần nội dung của HTML Document. Ngoài ra, việc ngăn chặn JavaScript nội tuyến cũng sẽ ngăn mã không thực thi trên Event Listeners. Chẳng hạn như thuộc tính “onClick” hoặc “onHover” là Vectơ phổ biến cho XSS. Nói chung, việc sử dụng JavaScript nội tuyến là một cách làm không tốt. Vì vậy việc sử dụng CSP để ngăn JavaScript nội tuyến thực thi không chỉ là một tính năng bảo mật tuyệt vời. Mà còn thực hiện Code Hygiene tốt.
Bên cạnh đó, CSP có thể ngăn không cho Code thực thi lời gọi hàm (Call Function) “eval ()” trong JavaScript. Đây là một nguồn phổ biến khác của lỗ hổng XSS. Cần lưu ý rằng nhiều Graphing Libraries phổ biến sử dụng hàm “eval ()” mặc dù hoạt động kém. Điều này khiến một số dự án gần như không thể thực thi chính sách này.
CSP cũng có thể hạn chế vị trí có thể tải Script (tập lệnh). Ví dụ: thêm ‘self’ vào lệnh ‘script-src’ sẽ chỉ cho phép tải các tập lệnh được lưu trữ trên cùng một miền mà trang Web được lưu trữ. Hay nói cách khác sẽ ngăn không cho các tập lệnh được tải từ bất kỳ miền nào khác (Google Analytics là một ví dụ). Chức năng này không chỉ dừng lại ở các Script. Nó cũng có thể giới hạn quyền đối với các Style, Form Actions, Fonts, vị trí iFrame. Hoặc thậm chí các điểm đến siêu kết nối.
3. Cách CSP hoạt động
Một lưu ý quan trọng là việc thực thi các vi phạm CSP là trách nhiệm của trình duyệt. Điều này đồng nghĩa với việc chi tiết thực tế triển khai có thể khác nhau. Giữa các trình duyệt và hỗ trợ cho các chỉ thị (Directive) CSP khác nhau cũng có thể khác nhau.
CSP có hai chế độ thực thi chính: chế độ tiêu chuẩn (thực thi hoặc chặn mọi vi phạm tiềm ẩn) và chế độ chỉ báo cáo (Report Only Mode) (không chặn các điều kiện vi phạm mà chỉ báo cáo chúng). Điều này đưa chúng ta đến một chỉ thị khá thú vị, chỉ thị “báo cáo”. Chỉ thị này chấp nhận một URL đầy đủ. Mà dữ liệu về tất cả các vi phạm sẽ được gửi qua HTTP POST. Dưới đây là một ví dụ về báo cáo.
{ “csp-report”: { “document-uri”: “http://example.com/signup.html”, “referrer”: “”, “blocked-uri”: “http://example.com/css/style.css”, “violated-directive”: “style-src cdn.example.com”, “original-policy”: “default-src ‘none’; style-src cdn.example.com; report-uri /_/csp-reports”, “disposition”: “report” } }
Thông thường, trong giai đoạn mới sử dụng CSP. Bạn nên bắt đầu với chế độ chỉ báo cáo và chuyển sang thực thi. Khi bạn tin chắc rằng bạn chưa phá vỡ trang Web của mình cho những người dùng hợp lệ.
Triển khai CSP
Có hai phương pháp triển khai CSP đáng chú ý. Cơ chế triển khai chính là chuyển một HTTP Header có tên “Content – Security – Policy” (hoặc “Content – Security – Policy – Report – Only” để vô hiệu hóa việc thực thi).
Tùy chọn thứ hai là sử dụng một biến thể ít được biết đến của thẻ HTML “” trong phần đầu HTML Document. Để triển khai CSP theo cách này, bạn có thể sử dụng thẻ như sau:
<meta http-equiv=”Content-Security-Policy” content=”<csp policy>” />
Tùy chọn thứ hai này hữu ích nếu bạn không nhất thiết phải có quyền kiểm soát Server Headers. Nhưng có toàn quyền kiểm soát nội dung.
Các chỉ thị phổ biến
Tất cả các chỉ thị CSP là tùy chọn và phạm vi khả năng được hỗ trợ bởi các chỉ thị thì khác nhau. Để hiểu cách CSP đang được sử dụng và những tính năng nào đang được áp dụng rộng rãi nhất. Cùng xem qua các chỉ thị dưới đây:
- default-src: Chỉ thị tài liệu phổ biến nhất là chỉ thị default-src. Điều này là rõ ràng vì nó được sử dụng để chỉ định chính sách nội dung mặc định cho hầu hết các chỉ thị nguồn.
- script-src’: script-src’ cũng là một chỉ thị phổ biến bởi có thể thấy lợi ích chính của CSP là giảm thiểu các cuộc tấn công XSS. Bằng cách không cho phép thực thi JavaScript nội tuyến.
- Các chỉ thị phổ biến tiếp theo là img-src và style-src. Nguyên nhân được lý giải bởi tần suất tải hình ảnh và Styles dưới dạng tài nguyên bên ngoài và tính dễ thực hiện (cả hai loại nội dung đều có xu hướng được phân chia từ các thư mục tĩnh).
- Một số chỉ thị được gắn cờ ‘experimental’. Nghĩa là chúng không được chấp thuận hoàn toàn vào RFC. Và có hỗ trợ hạn chế hoặc không nhất quán trên các trình duyệt. Chỉ thị Experimental được sử dụng phổ biến nhất là workersrc. workersrc kiểm soát nơi có thể tải các tập lệnh Worker, SharedWorker hoặc ServiceWorker. Tính năng này cho phép các tác vụ nền chạy trong trình duyệt và là tính năng khá tiên tiến. Service Workers là một tính năng của Ứng dụng Web luỹ tiến (PWA), các ứng dụng Web có thể cài đặt có nhiều tính năng của các ứng dụng gốc.
4. Kết luận
Content Security Policy – chính sách bảo mật nội dung không ngăn ứng dụng Web của bạn bị tấn công bởi XSS. Nhưng nó ngăn nhiều lỗ hổng trong số đó có thể bị khai thác. Hy vọng những chia sẻ trên đã giúp người đọc, đặc biệt là cộng đồng phát triển Web có thêm công cụ, hướng dẫn và khuôn khổ mới để phát triển các chính sách bảo mật nội dung hiệu quả.
