CSRF token in request header or body

[matus_b]

Hi Isomorphic,

until now we used the recommended approach by setting CSRF token to the RPCManager actionURL. But after the last audit we got following request from security department:

However, the token must stay in the message body or custom headers and not URL or cookie. I understood from your message that you rely on SSL in order to keep the token in the URL. But I would like to ask to stick to the best practices and keep the token off the URL and cookie, because there are different attack vectors.

Quote from OWASP cheat sheet:

“CSRF tokens in GET requests are potentially leaked at several locations, such as the browser history, log files, network appliances that log the first line of an HTTP request, and Referer headers if the protected site links to an external site.”

Is there some way how to handle it on global level, because going to hunt down all DSRequests all across the app would be very hard.

Regards
Matus

[Blama]

matus_b,

while I get what they mean and an other way is surly nicer, I assume that the OWASP hint does not apply here, as all requests to IDACall as POST and not GET, as far as I can see. Of course this is only a last resort when arguing.

Best regards
Blama

[Isomorphic]

Further, network appliances cannot log the URL for HTTPS requests - they can only do so for HTTP - so your approach is already secure.

However, if the easier thing is to mollify the security team even when they are incorrect, you can install request transformers at the RPCManager level, so you could add HTTP headers there.

Again, when using HTTPS, this makes no difference, so if you'd like to save yourself some wasted work, we would suggest challenging the assertion that "there are different attack vectors". Under HTTPS, the URL is encrypted, period, so placing the CSRF token in the URL vs in the HTTP headers makes no difference.

[matus_b]

Thank you both Isomorphic and Blama. Your answers are very helpful.