Using XSS to perform XSS on another website using CSRF (XSS-CSRF-XSS)
Let us assume two websites A and B such that website A is vulnerable to XSS and CSRF and website B is vulnerable to XSS. In such a scenario if a user is logged in website A and browsing website B in another tab (in the same browser) then an attacker can inject a CSRF script in website B using XSS. This CSRF script would look something like this (if using GET, however a similar attack can be done with POST as well):
This CSRF script will get executed on website A while the user browses website B. It is easy to imagine what all can be substituted within the script tags and the resulting consequences. Interesting thing is to understand the applicability of such an attack. It can be used in cases where the attacker wants to perform stored based XSS on a website that only allows accounts for known users; one such example is financial institutions. However, it can be argued that DOM and Reflected XSS can be used directly to perform malicious activities rather than performing this stunt. But I would say the advantages (from an attacker’s perspective of course!) of stored based XSS outweigh the benefits of a DOM or Reflected XSS. Needless to say, stored based XSS can impact a large number of users if only a single victim is tricked into executing the script (anyone who visits the infected page from that point onwards will be a victim). However, in DOM and Reflected XSS, the attacker would need every single victim to execute the script and that would be something hard to achieve (the affected base of users will be comparatively smaller).
Taking an example that would make immediate sense; there is a good probability to find small to medium sized financial institutions that are vulnerable to XSS and CSRF (considering the current state of web security where US Treasury Department is struggling with malicious IFrames, you can blame me for being optimistic for larger corporations!). If such a case exists, the attacker needs to find a related website vulnerable to XSS that has probable chances of being visited while the user is logged in the financial institution’s website. A probable scenario is a user doing share trading (financial institution’s website) and browsing through share related information websites (script mount points). Other lucrative targets can be social networking websites.
Obviously, this attack requires a number of conditions to fulfill (as compared to other exploit scenarios) but it offers rich dividend to the attacker as compared to other avenues of attack.
http://www.WebsiteA.com/submit.php?SomeVulnerableField=<script> Do something malicious</script>
This CSRF script will get executed on website A while the user browses website B. It is easy to imagine what all can be substituted within the script tags and the resulting consequences. Interesting thing is to understand the applicability of such an attack. It can be used in cases where the attacker wants to perform stored based XSS on a website that only allows accounts for known users; one such example is financial institutions. However, it can be argued that DOM and Reflected XSS can be used directly to perform malicious activities rather than performing this stunt. But I would say the advantages (from an attacker’s perspective of course!) of stored based XSS outweigh the benefits of a DOM or Reflected XSS. Needless to say, stored based XSS can impact a large number of users if only a single victim is tricked into executing the script (anyone who visits the infected page from that point onwards will be a victim). However, in DOM and Reflected XSS, the attacker would need every single victim to execute the script and that would be something hard to achieve (the affected base of users will be comparatively smaller).
Taking an example that would make immediate sense; there is a good probability to find small to medium sized financial institutions that are vulnerable to XSS and CSRF (considering the current state of web security where US Treasury Department is struggling with malicious IFrames, you can blame me for being optimistic for larger corporations!). If such a case exists, the attacker needs to find a related website vulnerable to XSS that has probable chances of being visited while the user is logged in the financial institution’s website. A probable scenario is a user doing share trading (financial institution’s website) and browsing through share related information websites (script mount points). Other lucrative targets can be social networking websites.
Obviously, this attack requires a number of conditions to fulfill (as compared to other exploit scenarios) but it offers rich dividend to the attacker as compared to other avenues of attack.
