1

I am trying to implement XSS best practices on a site I’m making.

I am currently generating a secure token on my server and sending it back to the user as a form hidden field, then validating that token by ensuring that it has not expired and that it matches what is on database.

I was wondering what prevents an attacker from generating his/her own token. So hypothetically, if someone simply had his server generate a new token every time someone were to click on one of his malicious links which would bypass my CSRF validation.

Then I began requiring the clients IP to also be stored and checked during validation. But this would not be secure if our attacker and victim were on the same network such as a public WiFi hotspot.

My attempt at a solution: To place a cookie on every user's browser and to hash their token with the cookie's value so that I can be sure that it is not an XSS attack.

The question: I was wondering what the best practices are in ensuring that the token was originally generated by the intended user, also am I being paranoid about this?

  • Won't a forged token fail the check with what's in your database? You should read the OWASP CSRF cheat sheet – Neil Smithline Jul 9 '16 at 2:46
  • @NeilSmithline I don’t seem to understand what you mean? – Mohammad Ali Jul 9 '16 at 2:47
  • When you get a POST, you compare the hidden field with what you stored in your database, correct? – Neil Smithline Jul 9 '16 at 2:49
  • Yes, that is correct – Mohammad Ali Jul 9 '16 at 2:50
  • 1
    So if an attacker tries to forge a token, it won't validate when you do the compare and you're good. I'm not sure I understand your concern – Neil Smithline Jul 9 '16 at 2:51
2

I believe you're mixing up a few different threats and attack vectors here.

Threat: MITM sniffing or setting tokens

Location: Public wifi

How to mitigate: Use HTTPS so the connection is secured over TLS/SSL. Also the cookie Secure Flag is recommended, and an HSTS policy with preload.

Threat: XSS

Location: Over the internet

What it is: An attacker injecting JavaScript code into the page, either by enticing their victim to visit a URL for a "reflected XSS" attack, or by storing script within the system's database that is not correctly encoded on output for a "stored XSS" attack. When the attack payload is executed, it comes from the victim's browser and IP.

How to mitigate: Correctly encode output values, implement a Content Security Policy, set X-XSS-Protection and X-Content-Type-Options HTTP headers, set the HttpOnly flag on cookies.

Threat: CSRF

Location: Over the internet

What it is: At attacker enticing their victim to visit the attacker's site or a site compromised by the attacker that then makes a malicious request to a good site that the victim is also logged into. When the attack payload is executed, it comes from the victim's browser and IP.

How to mitigate: Generate a random token per session which is passed outside of the cookie mechanism (aka Synchronizer Token Pattern).

Your points

I was wondering what prevents an attacker from generating his/her own token

Nothing - however if you have associated the token with the user session, Bob's login cannot use Alice's CSRF token and vice versa. Therefore any attacker will not be able to use their own token in a CSRF attack. A good storage location is the server-side session mechanism many web frameworks provide.

Then I began requiring the clients IP to also be stored and checked during validation. But this would not be secure if our attacker and victim were on the same network such as a public WiFi hotspot.

A CSRF attack comes from the victim browser. Therefore, the IP address will be the same as the rest of the victim's session. Reading your paragraph again I now realise you may not have been referencing a Man-In-The-Middle situation as I described above, however I've left it in for completeness.

My attempt at a solution: To place a cookie on every user's browser and to hash their token with the cookie's value so that I can be sure that it is not an XSS attack.

XSS is a different type of attack. If you have an XSS vulnerability then most CSRF protection mechanisms are either useless or severely compromised.

The mechanism you describe appears to be the Encrypted Token Pattern which is also a valid way to mitigate CSRF.

  • Yes, that is all true but you indicate that a random token should be generated per session. What would prevent you from generating a token then emailing me a forum with a hidden link using that token? How would I mitigate something like that? – Mohammad Ali Jul 9 '16 at 8:53
  • 1
    Each session has its own token. Bob has token 123 stored in their session, Alice has token 456 stored in their session. The hidden field Bob has won't match Alice's token so Bob cannot attack Alice via CSRF. The server-side script will check that the CSRF token POSTed equals the token in the session variable. – SilverlightFox Jul 9 '16 at 9:07
  • might mention x-frame-options in this context. Also, why does the csrf token need to be outside of a cookie on https? – dandavis Jul 9 '16 at 9:26
  • @dan Clickjacking is another attack, but can also be mitigated by a content security policy. The reason it needs to be outside of the cookie mechanism is that cookies are auto submitted by the browser in a cross domain request. Cookies can be used though in combination with values outside of cookies. – SilverlightFox Jul 9 '16 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.