1

Say a website has the following form on their sign-up page:

<form method="POST" action="https://example.com/login/"> <input type="hidden" name="x-csrf-token" value="[token]"/> <input type="hidden" name="firstName" value="[first name]"/> <input type="submit" value="Submit">

We know for a fact that the firstName value is susceptible to XSS. If I type in <script>alert(1)</script>, I get a dialog box.

However, I only get this dialog box on the next page, https://example.com/login/2.

Can the XSS on this website be used to steal the x-csrf-token and submit the form, even if the token is only generated on the first page? The end goal would be to have the attacker host a website with a maliciously crafted form, which would force the victim to make a POST request with the XSS in firstName being used to steal their CSRF token.

0

1 Answer 1

1

Assuming you can reach the second page without needing a cookie or other stateful artifact of going through the first page, yes, you absolutely can do that. Use XMLHttpRequest or fetch to retrieve the user's view of the first page, extract the CSRF token, and then use it to POST the values you want. Alternatively, inject an iframe for the first page into the second (it can be invisible to the user), and then you can read the iframe's contents and manipulate its DOM, because it is same-origin.

Alterntively, for login CSRF, just programmatically set the session cookie in the XSS payload. Login CSRF matters, but only after you have completely eliminated XSS and usually post-authentication CSRF matters a lot more, too. Sign-up CSRF is basically a weird case of login CSRF.

2
  • Now let's say the first page can only be accessed after logging in from a different page, /login/sign-up. Once you login with a valid social media account, you are redirected to /login/. Then, once your first name or the payload into the firstName variable, you are redirected to /login/2, which is the page that is vulnerable to XSS. So if you have a valid login page with no XSS, and then you are directed to the sign up page, which will show you results on the next page (e.g. "Welcome, <script>alert(1)</script>, please check your email!), is that just self-XSS? Feb 5, 2019 at 5:02
  • In that case, yes, it sounds like there's no way to actually exploit the XSS from another site or user, so it's just self-XSS. Still a good idea to fix it in case there later turns out to be some other way to use this (as part of an attack chain built on some other bug(s)), but not urgent.
    – CBHacking
    Feb 5, 2019 at 6:22

You must log in to answer this question.

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