1

I am trying to do CSRF vulnerability analysis for my website. My website uses an anti-CSRF-token which is sent by the server to the client with the session cookie and then Javascript in the client scrapes it out of the cookie and attaches it as a separate XSRF-TOKEN header to send back to the server.

I tried CSRF attacks on an XSS vulnerable form on my website from BurpSuite by generating CSRF PoC after intercepting the request, saving it in an html file and opening that file in a new tab with an active session in another tab. I found that the browser is not able to send the XSRF token automatically but it does for all the cookies and other headers.

I want to know if it is possible to create a new or manipulate the existing XSRF-TOKEN header from the client side using a script and send it with the request. Or if there is any other way to forcefully send the XSRF-TOKEN header or any other way to carry out the CSRF attack?? As of now, the only vulnerability I know of is that I am able to open my website in an iframe from other domain.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
Akshay
  • 33
  • 5
  • When you are able to poke around on the session cookie with JS, you're not sending the cookie HttpOnly which is a bad thing IIRC. And when you're vulnerable to XSS, CSRF protection will fail anyways https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet – eckes Sep 18 '15 at 13:36

2 Answers2

1

JavaScript from another domain cannot manipulate or read content from your domain, even in an IFrame, due to the Same Origin Policy. Therefore the attack scenario you describe is not a risk as this is not a vulnerability.

Bear in mind that Double Submit Cookies has other vulnerabilities. See this answer.

A way of circumventing CSRF protections is for an attacker to use Clickjacking instead. To prevent this make sure that your site cannot be framed using the X-FRAME-OPTIONS header and Content Security Policy's frame ancestors directive.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • say, you hijack one of the domain and have it's control for example.org via `sub-domain hijacking AKA red october` attack; an attacker here could then host his JS and redirect traffic from it's main domain to his sub-domain and hence manipulate content. No? – Shritam Bhowmick Oct 22 '15 at 10:13
  • If they can get victims to visit their subdomain, then yes (as described in the linked post). – SilverlightFox Oct 22 '15 at 10:17
0

Your last sentence is not about CSRF, but is about Click Jacking, these are not related.

The only thing I can think of to modify the XSRF-TOKEN header as an attacker is when you are vulnerable to HTTP Parameter Pollution.

To get a better understanding of your anti CSRF implementation, it would be better if you describe how the cookie and the header are checked.

I've seen implementations that only check if the cookie value is equal to the header value, which in my opinion is not correct as the server should check its value and not just compare the two.

Jeroen
  • 5,783
  • 2
  • 18
  • 26