3

Lets say that page A is vulnerable to XSS, but contain nothing of interest to an attacker. Page A links to page B that is not vulnerable to XSS, but contains a high value target for an attacker (such as a login form to steal passwords from). Both page A and page B are on the same domain.

Is it possible to exploit the XSS vulnerability on page A to run code on page B when the victim visit it, so you can steal the victims password when it is entered into the log in form?

I suspect that playing around with frames or iframes might be part of the solution here, so a natural follow up question is if it is possible to containt the XSS vulnerability to page A with the help of content security policy or something similar?

|improve this question
  • 2
    One very simple attack would be to alter the URL of the link to page B to an attacker-controlled site (possibly with a very similar-looking domain name) that fakes (or proxies) B and records passwords or such. Furthermore, since the attacker has full control of the content displayed in A, they have all sorts of methods to alter its appearence in ways that make it seem like the user has transitioned to page B, while they are actually still on the attacker-controlled page A. – AardvarkSoup May 9 '16 at 21:01
5

The attacker could add some onclick event attribute on the different link of the page. When the user click on a link, he'll think he got a simple disconnection bug, instead of that, you're onclick event loaded a fake connection page. But, you're still on the domain and you can even manipulate the url with history.pushState(); as an example.

|improve this answer
0

1. Change the link

As suggested by AadvarkSoup in comments, an attacker can change the href attribute of the link on page A, so instead of page B it goes to http://evil-pishin-site.com/login. Most users would probably not notice the change of domain, as they don't expect it to change.

2. Simulate page B

As Xavier59 suggests in his answer - when the user clicks the link to page B, just change the apperance of page A to match the apperance of page B, but do not actually follow the link to page B.

3. Use an iframe

Remove all content from page A, and instead fill it with an iframe with page A in it. Since page A and B are from the same origin, the attacker will be able to access page B in the iframe (after the user clicks the link there) from the modified page A holding the iframe.

Setting the header content-security-policy: frame-ancestors 'none' on page B will stop this approach, but also prevent you from loading it in an iframe for legitimate reasons if you would ever want to do that.

Conclusion

Since only no #3 can be protected against, is seems like there is no good way to contain an XSS vulnerability to the vulnerable page.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.