Các phản hồi (response) HTTP headers có thể củng cố bảo mật cho các ứng dụng web của bạn. Chỉ cần thêm một vài dòng code, bạn sẽ tận dụng các headers này để ngăn hầu hết các trình duyệt web hiện đại gặp phải các lỗ hổng dễ tránh.
Với sự gia tăng của các cuộc tấn công mạng hiện nay, việc biết cách sử dụng bảo mật HTTP headers có thể giúp bạn fix các lỗ hổng trong các ứng dụng của mình và cung cấp trải nghiệm người dùng an toàn hơn.
HTTP Headers là gì?
Mỗi khi người dùng truy cập ứng dụng web bằng máy khách (thường là trình duyệt), máy khách (client) sẽ gửi một số request headers đến máy chủ và máy chủ sẽ phản hồi với nội dung được yêu cầu cùng với HTTP headers. Cả máy khách và máy chủ đều sử dụng các thông báo header này để trao đổi dữ liệu như một phần của giao thức HTTP.
HTTP headers về cơ bản là key:value được sử dụng để chuyển thông tin kỹ thuật, chẳng hạn như loại tài nguyên được yêu cầu, cách trình duyệt lưu nội dung vào bộ nhớ cache,…
Bạn có thể kiểm tra thông tin plain-text (văn bản thuần) của HTTP response headers bằng cách sử dụng lệnh cURL đơn giản, với tùy chọn —head. Đây là một ví dụ:
Bằng cách thiết lập các headers bảo mật phù hợp trong các ứng dụng web của mình, bạn có thể tăng cường khả năng chống lại các cuộc tấn công.
curl --head https://www.securecoding.com/ Server: nginx Date: Wed, 21 Jul 2021 16:05:03 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding ... X-Kinsta-Cache: HIT Content-Encoding: gzip ...
HTTP Strict Transport Security (HSTS)
The HTTP Strict Transport Security (HSTS) là một response header cho phép bạn hướng dẫn trình duyệt rằng các tương tác chỉ nên được tổ chức thông qua kết nối HTTPS an toàn chứ không phải qua giao thức HTTP.
Ví dụ: nếu ứng dụng web cho phép kết nối qua URL http:// trước khi chuyển hướng khách truy cập đến https://, thì tương tác ban đầu không được mã hóa này của ứng dụng có thể tạo cơ hội cho các loại tấn công khác nhau, chẳng hạn như man-in-the-middle.
Với HSTS, bạn có thể yêu cầu trình duyệt web rằng nó không bao giờ được truy cập vào một ứng dụng thông qua HTTP. Bất kỳ nỗ lực nào để tải ứng dụng web thông qua HTTP đều được tự động thay đổi thành HTTPS.
Dưới đây là các tùy chọn HSTS:
- max-age=<number of seconds> – đảm bảo trình duyệt truy cập ứng dụng bằng HTTPS trong số giây được chỉ định.
- includeSubDomains — một tham số đảm bảo HSTS được áp dụng ngay cả cho các subdomains của domain hiện tại.
- preload — một thông số được sử dụng khi một ứng dụng web đã nhận được HSTS preload list.
Dưới đây là một ví dụ về cách bạn có thể triển khai HSTS:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload //note that 31536000 seconds is equal to a year.
X-Frame-Options (XFO)
X-Frame-Options (còn được gọi là XFO) là một response header cho phép hoặc cấm các trình duyệt web render trang trong thẻ HTML “frame”, “iframe”, “embed” hoặc “object”.
Các iframe HTML cho phép một ứng dụng web con được lồng vào một ứng dụng web mẹ. Mặc dù chúng cung cấp các tính năng hữu ích, nhưng kẻ tấn công có thể sử dụng chúng để nhúng một ứng dụng web hợp pháp vào một ứng dụng web độc hại. Điều này làm cho ứng dụng dễ bị tấn công click-jacking; tức là, lừa người dùng nhấp vào một phần tử trang web độc hại.
Với XFO, bạn có thể thông báo cho trình duyệt áp dụng các hạn chế ngăn ứng dụng web của bạn bị iframe. Điều này có thể ngăn kẻ tấn công nhúng ứng dụng web của bạn vào một trang web độc hại và lừa người dùng thực hiện các hành động có hại.
Dưới đây là các tùy chọn XFO:
- DENY — chặn hoàn toàn iframe.
- SAMEORIGIN — chỉ cho phép iframe cho các ứng dụng trên cùng một domain.
Đây là một ví dụ:
X-Frame-Options: SAMEORIGIN
Content Security Policy (CSP)
The Content Security Policy (CSP) là response header cho phép bạn kiểm soát loại tài nguyên mà trình duyệt web có thể tải cho ứng dụng web của bạn. Đây là một cách hiệu quả để đưa các nguồn nội dung ứng dụng của bạn vào danh sách trắng.
Với CSP, bạn có thể bảo vệ ứng dụng web của mình chống lại việc thực thi nội dung độc hại — chẳng hạn như từ XSS, click-jacking hoặc các loại tấn công injection khác.
Dưới đây là một số tùy chọn CSP phổ biến:
- default-src <source> – hoạt động như một nguồn dự phòng. Ví dụ: default-src ‘self’ tải mọi nội dung từ domain hiện tại.
- script-src <source> — chỉ định các nguồn được phép cho các tập lệnh. Ví dụ: script-src myjsscript.com chỉ tải các tập lệnh từ trang web được chỉ định.
- img-src <source> — chỉ định các nguồn được phép cho hình ảnh và biểu tượng yêu thích. Ví dụ: img-src * cho phép tải hình ảnh từ bất kỳ nguồn trực tuyến nào.
Đây là một ví dụ:
Content-Security-Policy: default-src 'self'; script-src myjsscript.com; img-src *;
X-Content-Type-Options
X-Content-Type-Options là một response header cho phép bạn chống lại các lỗ hổng kiểu nội dung hoặc các lỗ hổng MIME.
MIME sniffing là một tính năng mà hầu hết các trình duyệt web sử dụng để kiểm tra (và sửa chữa) loại nội dung của tài nguyên đang được tải. Ví dụ: trình duyệt có thể được yêu cầu hiển thị hình ảnh tại /my-best-image.png, nhưng máy chủ đã không đặt đúng loại nội dung khi cung cấp cho trình duyệt (chẳng hạn như Content-Type: text/plain).
Sau đó, trình duyệt sẽ “đánh hơi (sniff)” tệp để phát hiện định dạng tệp của nó. Trong trường hợp này, trình duyệt web sẽ bỏ qua headers Content-Type do máy chủ gửi và diễn giải tệp theo định dạng đã xác định. Điều này sẽ đảm bảo hình ảnh được hiển thị đúng cách.
Mặc dù MIME sniffing là một tính năng hữu ích của trình duyệt, nhưng nó có thể dẫn đến một lỗ hổng bảo mật nghiêm trọng. Ví dụ: nếu ứng dụng web cho phép người dùng tải lên hình ảnh của chính họ, thì khách truy cập có thể tải tệp hình ảnh chứa code HTML độc hại lên ứng dụng web của bạn. Trong trường hợp như vậy, trình duyệt sẽ bỏ qua loại nội dung hình ảnh và thay vì hiển thị hình ảnh, trình duyệt sẽ thực thi code HTML độc hại đó.
Với X-Content-Type-Options, bạn có thể hướng dẫn trình duyệt tránh bị sniffing khi xử lý các tài nguyên đã tìm nạp. Trình duyệt sẽ giữ nguyên giá trị được đặt trong Content-Type.
Nó chỉ có một tùy chọn:
- nosniff — ngăn chặn các nỗ lực sniffing kiểu MIME.
Đây là một ví dụ:
X-Content-Type-Options: nosniff
Clear-Site-Data
Clear-Site-Data là một tresponse header cho phép bạn hướng dẫn trình duyệt tránh lưu trữ thông tin nhạy cảm của ứng dụng web.
Bạn có thể sử dụng nó để xóa tất cả dữ liệu duyệt web — chẳng hạn như cache, bộ nhớ và cookie — được liên kết với ứng dụng web của bạn. Ví dụ: sau khi người dùng đăng xuất, bạn có thể sử dụng header này để đảm bảo rằng tất cả dữ liệu được lưu trữ ở phía máy khách đều bị xóa.
Dưới đây là các tùy chọn Clear-Site-Data:
- cache — xóa tất cả nội dung được lưu trong bộ nhớ cache cục bộ.
- storage — xóa tất cả nội dung được lưu trữ trong DOM.
- cookie — xóa tất cả cookie.
- *(ký tự đại diện) —xóa tất cả các loại dữ liệu duyệt web.
Đây là một ví dụ:
Clear-Site-Data: "*"
Kết luận
Hầu hết các trình duyệt web hiện đại đều hỗ trợ một số loại header HTTP. Bạn có thể tận dụng chúng để tăng cường bảo mật cho các ứng dụng web của mình. Bằng cách định cấu hình chính xác các headers, bạn có thể tăng cường khả năng phòng thủ và bảo vệ trước các cuộc tấn công thông thường.
Ngoài ra, bạn cũng có thể xem cách tìm lỗ hổng bảo mật bằng OWASP ZAP tại đây.
