1

I was reading about XSRF and I'd like to ensure that I understand the problem correctly and know if my application is protected against that kind of attack.

How I understand CSRF works:

  • adding a random(?) string which is saved in your cookie by set-cookie header or by an javascript code (then it can't be HTTP only so I guess that is better to use set-cookie), in theory it can be accessed only from the domain it was set
  • that string is validated with every request by the API to ensure that request isn't made from different origin

Solution I have currently:

  • session is set by the server after user authentication(login) and its ID is set as HTTPS only cookie
  • session ID is long random string saved in DB with information about users browser user agent string, IP and user ID
  • JS can't access the cookie, all requests are set with XMLHttpRequest.withCredentials to pass cookie to server
  • session ID is validated with every request also against user agent and IP
  • session is valid by 10 mins but can be extended

Moreover:

  • I have CSP set to allow content only for a few trusted domains
  • I have CORS setup to allow requests from trusted origins only

As I see my session ID acts a bit similar to CSRF token. I'd like to know do I need additional CSRF token to prevent XSRF or solution I have currently covers that vulnerability in satisfying way?

Security is area which I am new in and I don't feel confident I appreciate any help.

Improve this question
3
  • if all your requests are POST, and all the above is all true, then you don't really need CSRF tokens.
    – dandavis
    Commented Aug 3, 2016 at 17:46
  • @dandavis how different is POST than GET in this situation?
    – LJ Wadowski
    Commented Aug 4, 2016 at 6:20
  • 1
    becasue you basically need XSS to pull of a zombie POST, whereas a mere img tag can spoof a GET. So, if you have a working CSP, you don't have to worry much about XSS and thus CSRF.
    – dandavis
    Commented Aug 4, 2016 at 11:50

1 Answer 1

Reset to default
2

The token needs to be validated outside of the cookie mechanism also.

Say evil.example.com open in Alice's browser makes a cross-site request to yoursite.example.org, then the browser will send all her cookies to yoursite.example.org, including session cookies or any other cookies you may be using to prevent CSRF.

To mitigate this, you need to send the token using another method also (I'm describing the Double Submit Cookies because it is quite simple). For example, you could include a hidden field on your form:

<input type=hidden name=csrftoken value=12321231 />

On the server-side you simply check that your session value (or cookie value) that you are using for CSRF matches the one in the hidden form field. An attacker can not then forge a request because they do not know this value, nor can they retrieve it for the current user. This value needs to be generated randomly per session (using some source of unpredictable entropy).

Improve this answer
2
  • Thank you for the answer. I have a couple of additional questions: does the CORS settings that allows requests from yoursite.example.org only wont block requests from evil.example.com? Is there a way to implement Double Submit Cookie in Angular SPA app where all HTML files are static and served by nginx?
    – LJ Wadowski
    Commented Aug 3, 2016 at 11:25
  • 1
    If you're only allowing particular origins in your CORS headers, then yes it will block others like evil.example.com. I believe Angular implements the encrypted token pattern: See my answer here and the links for further info.
    – SilverlightFox
    Commented Aug 3, 2016 at 11:32

You must log in to answer this question.

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