6

CSRF was part of older OWASP TOP 10 lists but has been retired "as many frameworks include CSRF defenses, it was found in only 5% of applications". But even without frameworks doing CSRF defense, I've got the feeling that modern browsers already mitigate the problem. Cookies and headers needed for authentication are not sent by default in cross site requests.

For instance, if an XMLHttpRequest should send cookies, the withcredentials-flag has to be set. And even then, the target server has to implement a CORS header for the request to be successful. At least in Chrome.

So I now wonder, which browsers already implement those counter measures and if they are enough as defense or if we still have to implement CSRF mitigations in our applications.

3 Answers 3

4

... if an XMLHttpRequest should send cookies, the withcredentials-flag has to be set. And even then, the target server has to implement a CORS header for the request to be successful. ... which browsers already implement those counter measures and if they are enough as defense or if we still have to implement CSRF mitigations in our applications.

CORS for XHR is not a new mitigation and it even isn't a mitigation against previously working attacks at all. When XMLHttpRequest was designed no cross-origin requests were possible at all. And only with the introduction of CORS this restrictions was changed and replaced with cross-origin requests controlled by a CORS policy. Thus, all the old browsers which did not implement CORS were not affected by CSRF via XHR in the first place.

Nevertheless, CSRF is still a problem and can still be used the same way as it could in the past. XHR is not needed as a vector for CSRF attacks at all and it did not work in the past anyway. Instead cross-site image includes, cross-site form submits or similar can be used, which still automatically send the necessary credentials and cookies cross-site. The new samesite attribute for cookies can be used to prevent this but it has to be explicitly set by the application and not all browsers support it yet.

Therefore proper CSRF protection is still needed today.

What happens if CSRF protection is not properly implement can be seen for example by recent news like Hackers Launching Massive Cyber Attack Against 800,000 DrayTek Routers by Exploiting zero-day Vulnerability.

3
  • Maybe I've put too much emphasis on the XMLHttpRequest example. AFAIK, also other CSRF requests like <img>-tags are nowadays not so easy to create, because they don't send cookies anymore or do they still? btw: I can't find a reference to CSRF in the article you linked...
    – rdmueller
    Oct 2, 2018 at 20:01
  • 1
    @rdmueller: "...I can't find a reference to CSRF in the article you linked..." - it references this security advisory which explicitly points out a CSRF problem. Oct 3, 2018 at 1:13
  • 1
    @rdmueller: "AFAIK, also other CSRF requests like <img>-tags are nowadays not so easy to create, because they don't send cookies anymore or do they still?" - I'm not sure where your AFAIK comes from but as far as I know they still do - and this is for example also used for tracking and advertisement to detect the same users over multiple domains. Oct 3, 2018 at 1:16
4

Cookies and headers needed for authentication are not sent by default in cross site requests.

That is not correct. If a user clicks a link or post a form on evil.com to example.com, cookies will be included. The user doesn't even have to click the link or submit button, it can be automated with a script.

For instance, if an XMLHttpRequest should send cookies, the withcredentials-flag has to be set. And even then, the target server has to implement a CORS header for the request to be successful.

Yeah, sure. But why would an attacker need XHR when you can just use an old fashioned form?

So I now wonder, which browsers already implement those counter measures and if they are enough as defense or if we still have to implement CSRF mitigations in our applications.

Browsers do not implement any automatic counter measures, so you still need to do it. Vulnerable sites will continue to be vulnerable no matter how modern browsers we use.

In one way you are right, though. Modern API:s are often designed in ways that gives them at least some CSRF protection by default. This happens for instance if you do authentication with a authorization header instead of cookies, or if you only accept POST requests with a JSON body.

2
  • right. GET requests send cookies. But by now, everybody should be aware that GET requests shouldn't modify anything on the server. This would limit the attack surface to other request which are not initiated by a simple link, wouldn't it?
    – rdmueller
    Oct 3, 2018 at 5:00
  • 1
    @rdmueller I'm not taking about just GET but POST as well. Anyways, theres a lot of things everybody should be aware of by now, but isn't.
    – Anders
    Oct 3, 2018 at 5:08
1

If I had to make a comment on the matter then It'd be best reflected by what's written in this piece.

https://medium.com/@jrozner/wiping-out-csrf-ded97ae7e83f

CSRF is still relevant in a condition similar to IPv4 - We won't be able to phase out legacy systems that are privy to it for a while yet, and eventually a permutation of it will arise.

As always; remember to patch your systems kids

1
  • thanx. The article is great and your comparison with IPv4 is what I think, too. But it would be nice to have some figures on what percentage of browsers still cause a problem
    – rdmueller
    Oct 2, 2018 at 19:05

You must log in to answer this question.

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