Tác động
Giả mạo yêu cầu chéo trang (CSRF) cho phép kẻ tấn công lừa trình duyệt của nạn nhân thực hiện các hành động không mong muốn trên một trang web khác mà nạn nhân hiện đã được xác thực. Vì trình duyệt tự động đưa thông tin xác thực xung quanh như cookie vào yêu cầu nên kẻ tấn công có thể giả mạo các hoạt động thay đổi trạng thái—chẳng hạn như thay đổi mật khẩu, xóa dữ liệu hoặc bắt đầu giao dịch—mà người dùng không hề biết.
Nguyên nhân gốc rễ
Nguyên nhân cơ bản của CSRF là hành vi mặc định của trình duyệt web là gửi cookie được liên kết với một miền bất cứ khi nào có yêu cầu được thực hiện đối với miền đó, bất kể nguồn gốc của yêu cầu là [S1]. Nếu không xác thực cụ thể rằng yêu cầu được kích hoạt có chủ ý từ giao diện người dùng của chính ứng dụng, máy chủ không thể phân biệt giữa hành động hợp pháp của người dùng và hành động giả mạo.
Cơ chế bảo vệ CSRF của Django
Django cung cấp một hệ thống phòng thủ tích hợp để giảm thiểu những rủi ro này thông qua phần mềm trung gian và tích hợp mẫu [S2].
Kích hoạt phần mềm trung gian
django.middleware.csrf.CsrfViewMiddleware chịu trách nhiệm bảo vệ CSRF và thường được bật theo mặc định [S2]. Nó phải được định vị trước bất kỳ phần mềm trung gian xem nào cho rằng các cuộc tấn công CSRF đã được xử lý [S2].
Triển khai mẫu
Đối với mọi biểu mẫu POST nội bộ, nhà phát triển phải bao gồm thẻ {% csrf_token %} bên trong phần tử <form> [S2]. Điều này đảm bảo rằng một mã thông báo bí mật, duy nhất được bao gồm trong yêu cầu, sau đó máy chủ sẽ xác thực dựa trên phiên của người dùng.
Rủi ro rò rỉ token
Một chi tiết triển khai quan trọng là không bao giờ được đưa {% csrf_token %} vào các biểu mẫu nhắm mục tiêu các URL bên ngoài [S2]. Làm như vậy sẽ rò rỉ mã thông báo CSRF bí mật cho bên thứ ba, có khả năng ảnh hưởng đến bảo mật phiên [S2] của người dùng.
Bảo vệ cấp trình duyệt: Cookie SameSite
Các trình duyệt hiện đại đã giới thiệu thuộc tính SameSite cho tiêu đề Set-Cookie để cung cấp một lớp [S1] chuyên sâu về phòng thủ.
- Nghiêm ngặt: Cookie chỉ được gửi trong ngữ cảnh của bên thứ nhất, nghĩa là trang web trong thanh URL khớp với miền [S1] của cookie.
- Lax: Cookie không được gửi theo yêu cầu phụ trên nhiều trang web (chẳng hạn như hình ảnh hoặc khung) nhưng được gửi khi người dùng điều hướng đến trang gốc, chẳng hạn như bằng cách nhấp vào liên kết tiêu chuẩn [S1].
FixVibe kiểm tra nó như thế nào
FixVibe hiện bao gồm tính năng bảo vệ CSRF dưới dạng kiểm tra hoạt động có kiểm soát. Sau khi xác minh miền, active.csrf-protection kiểm tra các biểu mẫu thay đổi trạng thái được phát hiện, kiểm tra đầu vào có hình mã thông báo CSRF và tín hiệu cookie SameSite, sau đó thử gửi nguồn gốc giả mạo có tác động thấp và chỉ báo cáo khi máy chủ chấp nhận. Kiểm tra cookie cũng gắn cờ các thuộc tính SameSite yếu làm giảm khả năng phòng thủ chuyên sâu của CSRF.