😝CSRF

Today i will Explain what is CSRF in simple way :

  • (CSRF) is a client side technique used to attack other users of a web application.

How CSRF happen ?

  • when sites change password or email or transfer money without need old password or without used token for every user or use any authentication process

When CSRF happen :

  1. No CSRF Token

  2. Weak CSRF token - if i can delete it ? or if site check for token ? if it change every request ?

  3. Check Content Type

  4. Check referrer header

How does CSRF work in function ?

For a CSRF attack to be possible, three key conditions must be in place:

  1. A relevant action :

    • must found impact like : we have a function vulnerable and the attack have high value like : delete user

  2. Cookie-based session handling :

    • must use victim cookie (main part of request ) ,, because server check cookie for every victim request ⇒ function must check cookie for changing password

  3. No unpredictable request parameters :

    • doesn’t need any unknown parameters in request : like old user password '

What cases can be exec attack Even if there is token ???

  1. ٍstatic token for evert request with all users ..

  2. small token can be brute force such as 3 num

  3. no validation with token (can be delete )

what we can Test against :

  1. when we find CSRF token

  2. Test in Referrer Header

Simple attack :

1- The attacker intercepts the request but doesn't find a CSRF token.

2- The attacker generates a forgery site with the original request, including a new password, and enables auto-submit.

3- The attacker sends the link to the user, and the change is made when the user clicks on it.

some of port swigger labs :

  • Function doesn't use CSRF Token in request

  • let's generate our CSRF Poc

  • send it to exploit server and submit => work success


  • make a simple request with function change mail

  • send it to repeater and try to delete CSRF token => "Missing parameter 'csrf'"

  • it use POST Method let's try to change it to GET without CSRF Token => accepted and 302 found

  • then generate our CSRF Poc


3- CSRF where token validation depends on token being present :

  • make a simple request to use the function

  • let's try to delete Token to check if server validate token or not . => 302 Found

  • then generate our CSRF Poc


4- CSRF where token is not tied to user session :

  • tric : csrf token change for every request

    scenario : we are here 2 attacker and victim ,, we attacker token to attack victim and not need validation

  • some applications do tie the CSRF token to a cookie ,, The attacker can login to the application using his account, to obtain a valid token and associated cookie , then place their cookie into the victim's browser

  • make a simple request with wiener account => success

  • when i try to use same token to change mail for wiener => invalid => token work for 1 time

  • It uses tokens to try to prevent CSRF attacks, but they aren't integrated into the site's session handling system.

  • we can't use the same token for twice request :

  • trick here => back end create a pure token in the page source => بيكريت التوكن الجديده اللي هيستخدمها المره الجايه

    اللي ع اليمين دي القديمه والشمال دي اللي هيستخدمها ف ال REQUEST الجديده
  • here we get the next CSRF site will use let's copy it and use in change mail function in carlos account

  1. we need a way to use my pure CSRF token to put it in poc and send it to victim (because token change for every request)

  2. Generate POC with the pure token (in page source ) and change the mail name then send it to carlos


  • here use 2 tokens , one for session handling (CSRFKey) and one for CSRF protection, which are not integrated together

  • login with 2 account and use change mail Function :

  • check if csrf token tied to csrf cookie or not ⇒ change value of csrf token ===⇒ Invalid CSRF Token

  • try to use CSRF token and CSRF key from user wiener to carlos to know if session handling mechanism work or not (test deffensive mechanism ) ⇒ status code is 200 and work (الاتنين مربوطين ببعض يبقي لازم لو هستخدم ال csrf token بتاعت واحد استخدم معاها ال csrf key بتاعته )

  • hint : You cannot register an email address that is already taken by another user. If you change your own email address while testing your exploit, make sure you use a different email address for the final exploit you deliver to the victim.

  • let's find a way to exploit that :

  1. the server set CSRF KEY with cookie every request & i can control CSRF value but can't control CSRF KEY

  2. and there is relation between CSRF KEY & CSRF

  3. here we need to chain 2 vulnerability to make exploit

  4. when i use Search Function it set the value of search in request (cookie) => able to XSS

  5. let's use search Function to inject to set a new cookie value => the key that we can send to victim

  6. here i need to make 2 things ( send CSRF token of wiener to carlos - make a new request to change value of CSRF in cookie jar of wiener)

  7. let's use CRLF Vulnerability :https://owasp.org/www-community/vulnerabilities/CRLF_Injection CRLF refers to Carriage Return ( \r ) Line Feed ( \n ). i will use it to terminate search and make a new line to set a new CSRF key %0d%0a (\r\n)

  8. then i need a way to put CSRF_KEY (carlos) in a poc because it changed every request and tied to csrf =>

  9. let's login with carlos to get his token & key

  10. Then generate POC with Token & CSRF key of carlos

  11. and here we success :

  • conclusion : CSRF token and CSRF key is not tied to session handling mechanism and any user can forward with any CSRF token and CSRF key


  • make a basic request to show how server create token

  • here we find that => server create 2 tokens and have same value

  • let's try to change value with random and check how can the server check

  • server just check if 2 value are equal => 302 found (success)

  • it's time to Generate POC of Exploit

  1. we have Search function we can inject in it ( last search ) parameter

  2. we will use above technique to make to inject it to set a new cookie

  3. then we use our old token => here we success


Bypassing Referer-based CSRF defenses :

  • when intercepting request it like => we don't have any token in request

  • let's generate POC with this request without change any thing (just mail )and look what happen

  • we get that in the browser after send exploit

  • then we know that he check for the referer header (referer is the domain of application )

  • 1- then remove Referer header from request

  • 2- Create POC and add this header in POC

  • work success

  1. Validation of Referer can be circumvented

  • let's try to remove referrer header

  • lets try to make the domain is a subdomain or parameter

    here we scuccess in this step
  • let's Generate our POC and here we will put the query and url in the last thing inhistory.pushState('', '', '/?domain.com') => it's a function used to add entry to browser session

  • and add Referrer-Policy : unsafe-url in the head tag to bypass it

  • Success

Last updated