Steal CSRF token

From OWASP (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) )

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

The CSRF attack vector, by definition, is not on the same server as the server being attacked, so it doesn't have access to that information.

A rudimentary example:

Victim - Bob

Site - foo.com

Attacker - John

John has no access to foo.com, but he has access to Bob, either through a website or an email. He knows how foo.com works, so he can bind a request to either an email or a malicious website that is not on the foo.com domain. This will send the request and piggy-back off Bob's credentials.

The same-origin policy prevents John from seeing or intercepting anything of Bob's version of foo.com, which is why the CSRF key can be stored on the page Bob receives from foo.com without ever being seen by John.

If John were able to use JS to actually see the token, that would imply that John has access to requests from foo.com, in which case this would be either person-in-the-middle attack or an inside attack.

Basically, the goal of a CSRF key is to only stop a CSRF attack. If the CSRF key itself is being intercepted, then another attack has occurred.

TL;DR

Java script can access your DOM and Cookie .

You have to prevent Intruder's Java script to run on your users browser (XSS Attack),

in order to prevent them from CSRF Attack too.

Further information on tokens difference

---

For CSRF prevention there exists two popular method:

• CSRF token
• XSRF token

Steal CSRF

for an attacker to access CSRF token, he/she has to inject his js into victims web page to steal CSRF token. this attack is called XSS attack. so you have to prevent XSS attack too.

another possibility, is the attacker access victims memory which needs have malware with kernel space access.

Steal XSRF

XSRF are saving in cookies and should set Same-Site Policy as Lax or Strick to make browser not giving it to another script.

in additional victim's are vulnerable if saved cookie file on system is not protected with required privilege.

The short answer is: The Same Origin Policy. As an attacker would serve its malicious script from another origin, his script is not allowed to read data contained in another origin (I.e. the token).

However, if the site containing the token has a XSS vulnerability and the attacker uses that to load his script, the origin would match and he would be indeed be able to steal his token.