CSRF - where token is tied to non-session cookie

Lab: CSRF where token is tied to non-session cookie

So I did the lab again one day afterwards because I really want to understand what is going.

So the purpose of the lab is to update the email for wiener but we uses carlos account at the time when we do it.

so in first place we login as(Attacker)  'Carlos' and grab a csrf-token also the cookie csrfKey.

TestSuite

​​​​​​​to verify  if the 'CSRF token' is tied to the 'CSRF cookie'. Testcase#1) Submit a invalid CSRF-token. Intercept the request for the user 'wiener' by change a character in the  csrf parameter as image below:

its resulted in a bad request  a good sign.

Testcase 2) submit a valid CSRF-token but for another user.

its also resulted in a bad request. that means now the cookie csrfKey and csrf-token are tied together.

Step3) Submit a valid CSRF token and cookie from another user

to verify if the cookie csrfKey and csrf parameter are tied to the session-handling mechanism.

 We take the cookie csrfKey and CSRF-token from the user carlos and put those in the intercepted request for wiener.

We also following redirection:

So it works httpcode 200. that means the session-handling and the defence mechanism are not tied together.

Exploit part! ​​​​​​​In order to exploit this vulnerability there are 2 things that needs to be done.

​​​​​​​Testcase#3 Step 1) Inject a csrfKey coookie in the users session (HTTP Header injection) Step2 ) Send a CSRF attack to the victim with a known csrf token. Notice you need to do that in one request.

For now we have only got one  csrfKey cookie:

detailed:

so lets do a search for the word 'hat' then we get another cookie as image below:

below in an example of the request within burp suite:

in the response we can appear there has been Set a new cookie line 2. Set-Cookie: lastSearchTerm=hat;

depending of how the second cookie is validated we might able to bypass it, to set a own cookie as image below:

we got 302 redirected so that means it works.

good snippet for the PoC 

next step is to intercept a request where we update the email for wiener

(we already made a note of the cookie csrfKey and the CSRF-Token for the user carlos(NOTICE  important you dropped that request ))

Below is where we generated a PoC 

The csrfKey on line 3 is also used in the PoC line 10 as csrfKey IMPORTANT.

snippet

example:

​​​​​​​Paste it in exploit server and voila as below=)