4

The application is constructed in Java language and JSF framework. I have reported a CSRF attack and the development team have to fix it soon since the application is in production.

I recommended to use CSRF tokens but the development team says it may take some time for the implementation.

Can any of you suggest a better and faster way to remediate CSRF? If it is a temporary solution for now, that is also fine. Later, they will implement the proper CSRF tokens in the code in a reasonable time.

Improve this question
1
  • just require POST, then it can basically only work w/XSS, which is it's own issue anyway
    – dandavis
    May 11, 2018 at 19:19

3 Answers 3

Reset to default
4

A quick fix against CSRF is to check the Referer and/or Origin HTTP header. At least one of these should be set and the domain it contains should be your domain (i.e. same origin).

Note that this will break cases where your site is accessed from a bookmark, link inside a mail or similar since in thus cases no Referer will be sent. But in no case you should simply accept an empty Referer (unless you have a non-empty Origin header) since this is easy to create for an attacker.

You should also make sure that your checks for the domain are correct. This is, if your site is www.example.com you must not accept Referer like http://www.example.com.attacker.com or http://www.attacker.com/www.example.com or http://www-example.com.

You should also make sure that the attacker can not use other functionality (or bugs) in your application as a trampoline to create a custom request with malicious payload but the expected same-origin Referer. As Arminius nicely pointed out in a comment, open redirects might be such a trampoline. Thus you should either make sure that all requests to the domain have a same-origin Referer or that any parts which might need to accept a cross-origin Referer can not be abused as trampoline.

For more information about this method of protecting against CSRF and about its potential problems see Verifying Same Origin with Standard Headers in the Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet from OWASP.

Improve this answer
2
  • 4
    However, Firefox currently doesn't send the Origin header by default, and checking the Referer alone isn't always sufficient since other features such as open redirects may allow an attacker to forge the header. But as a quick fix it may definitely help.
    – Arminius
    May 10, 2018 at 12:01
  • @Arminius: thanks for pointing out the danger of open redirects. I've integrated it in my answer.
    – Steffen Ullrich
    May 10, 2018 at 12:28
1

Another possibility is to use Same Site cookies (SameSite=Strict;). Essentially this attribute, when enabled, prevents the browser from sending cookies from cross-site requests. This could potentially break some functionality, however it's another idea that could be added quickly:

https://medium.com/compass-security/samesite-cookie-attribute-33b3bfeaeb95

Downfall - not all browsers support it.

Improve this answer
-1

The only way to mitigate this vulnerability is a synchronizer token pattern. Only with a token.

Try to use OWASP CSRFGuard project

Improve this answer
1
  • 2
    I added links to the things you were talking about, and the OWASP page defines the 2 methods, not just tokens. The OP already stated that tokens are not possible, which means the other methods are worthy of mention.
    – schroeder ♦
    May 10, 2018 at 12:48

You must log in to answer this question.

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