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?

8
  • Won't a forged token fail the check with what's in your database? You should read the OWASP CSRF cheat sheet Jul 9, 2016 at 2:46
  • @NeilSmithline I don’t seem to understand what you mean? Jul 9, 2016 at 2:47
  • When you get a POST, you compare the hidden field with what you stored in your database, correct? Jul 9, 2016 at 2:49
  • Yes, that is correct Jul 9, 2016 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 Jul 9, 2016 at 2:51

1 Answer 1

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.

4
  • 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? Jul 9, 2016 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. Jul 9, 2016 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, 2016 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. Jul 9, 2016 at 10:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .