798
1.Mã thông báo CSRF là gì?
Mã thông báo CSRF là một giá trị duy nhất, bí mật và không thể đoán trước được tạo bởi ứng dụng phía máy chủ và được chia sẻ với khách hàng. Khi đưa ra yêu cầu thực hiện hành động nhạy cảm, chẳng hạn như gửi biểu mẫu, khách hàng phải bao gồm mã thông báo CSRF chính xác. Nếu không, máy chủ sẽ từ chối thực hiện hành động được yêu cầu.
Một cách phổ biến để chia sẻ mã thông báo CSRF với khách hàng là đưa chúng dưới dạng tham số ẩn trong biểu mẫu HTML, ví dụ:
<form name="change-email-form" action="/my-account/change-email" method="POST">
<label>Email</label>
<input required type="email" name="email" value="evil-user@website.com">
<input required type="hidden" name="csrf" value="423lmdsajd24s">
<button class='button' type='submit'> Update email </button>
</form>
Việc gửi biểu mẫu này sẽ dẫn đến yêu cầu sau:
POST /my-account/change-email HTTP/1.1
Host: normal-website.com
Content-Length: 51
Content-Type: application/x-www-form-urlencoded
csrf=42cbxjknciownsd&email=evil-user@website.com
Khi được triển khai chính xác, mã thông báo CSRF giúp bảo vệ chống lại các cuộc tấn công CSRF bằng cách gây khó khăn cho kẻ tấn công trong việc xây dựng yêu cầu hợp lệ thay mặt nạn nhân. Vì kẻ tấn công không có cách nào dự đoán giá trị chính xác cho mã thông báo CSRF nên chúng sẽ không thể đưa nó vào yêu cầu độc hại.
2.Các lỗi phổ biến trong xác thực mã thông báo CSRF
a.Xác thực mã thông báo CSRF tùy thuộc vào phương thức yêu cầu
Một số ứng dụng xác thực chính xác mã thông báo khi yêu cầu sử dụng phương thức POST nhưng bỏ qua xác thực khi sử dụng phương thức GET.
GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2ySDAHdklncklxc
b.Việc xác thực mã thông báo CSRF phụ thuộc vào mã thông báo hiện có
Một số ứng dụng xác thực chính xác mã thông báo khi có mã thông báo nhưng bỏ qua xác thực nếu mã thông báo bị bỏ qua.
Trong tình huống này, kẻ tấn công có thể xóa toàn bộ tham số chứa mã thông báo (không chỉ giá trị của nó) để bỏ qua xác thực và thực hiện cuộc tấn công CSRF :
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2ySDAHdklncklxc
email=pwned@evil-user.net
c.Mã thông báo CSRF không bị ràng buộc với phiên người dùng
Một số ứng dụng không xác thực rằng mã thông báo thuộc cùng phiên với người dùng đang thực hiện yêu cầu. Thay vào đó, ứng dụng duy trì một nhóm mã thông báo toàn cầu mà nó đã phát hành và chấp nhận bất kỳ mã thông báo nào xuất hiện trong nhóm này.
Trong tình huống này, kẻ tấn công có thể đăng nhập vào ứng dụng bằng tài khoản của chính họ, lấy mã thông báo hợp lệ và sau đó cung cấp mã thông báo đó cho người dùng nạn nhân trong cuộc tấn công CSRF của chúng.
d.Mã thông báo CSRF được gắn với cookie không có phiên
Trong một biến thể của lỗ hổng trước đó, một số ứng dụng liên kết mã thông báo CSRF với một cookie, nhưng không liên kết với cùng một cookie được sử dụng để theo dõi phiên. Điều này có thể dễ dàng xảy ra khi một ứng dụng sử dụng hai khung công tác khác nhau, một để xử lý phiên và một để bảo vệ CSRF, không được tích hợp với nhau:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=fRsjdaskjd231jkscj
csrf=SDdnslcbxjkbckj1231sknsY&email=wiener@normal-user.com
Tình trạng này khó khai thác hơn nhưng vẫn dễ bị tổn thương. Nếu trang web có bất kỳ hành vi nào cho phép kẻ tấn công đặt cookie trong trình duyệt của nạn nhân thì một cuộc tấn công có thể xảy ra. Kẻ tấn công có thể đăng nhập vào ứng dụng bằng tài khoản của chính họ, lấy mã thông báo hợp lệ và cookie được liên kết, tận dụng hành vi cài đặt cookie để đặt cookie của họ vào trình duyệt của nạn nhân và cung cấp mã thông báo của họ cho nạn nhân trong cuộc tấn công CSRF của họ.
e.Mã thông báo CSRF được sao chép đơn giản trong cookie
Trong một biến thể khác của lỗ hổng trước đó, một số ứng dụng không duy trì bất kỳ bản ghi mã thông báo phía máy chủ nào đã được phát hành mà thay vào đó sao chép từng mã thông báo trong cookie và tham số yêu cầu. Khi yêu cầu tiếp theo được xác thực, ứng dụng chỉ cần xác minh rằng mã thông báo được gửi trong tham số yêu cầu khớp với giá trị được gửi trong cookie. Điều này đôi khi được gọi là biện pháp bảo vệ “gửi kép” chống lại CSRF và được ủng hộ vì nó dễ thực hiện và tránh sự cần thiết của bất kỳ trạng thái phía máy chủ nào:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa
csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com
Trong tình huống này, kẻ tấn công có thể thực hiện lại cuộc tấn công CSRF nếu trang web chứa bất kỳ chức năng cài đặt cookie nào. Ở đây, kẻ tấn công không cần phải có mã thông báo hợp lệ của riêng mình. Chúng chỉ đơn giản tạo ra một mã thông báo (có thể ở định dạng bắt buộc, nếu điều đó đang được kiểm tra), tận dụng hành vi cài đặt cookie để đặt cookie của chúng vào trình duyệt của nạn nhân và cung cấp mã thông báo của chúng cho nạn nhân trong cuộc tấn công CSRF của chúng.
