Anton Rager developed such a tool in 2005 and demonstrated that XSS proxies can be used to sustain an XSS attack indefinitely (as long as the hijacked browser window exists) and allow the attacker to view or submit content to the vulnerable server, in the victim’s place. Essentially, the attacker hijacks the victim’s session to a vulnerable server in order to plug the victim’s browser into the XSS Proxy tool, and then use it to force the victim’s browser to access content on the same domain as the vulnerable server – for as long as the victim keeps the session active.
Examples of scenarios where normal XSS is not viable
These examples assume there is an XSS vulnerability on a target server, which enables an attacker to perform an XSS attack against it, but because of the context and other variables, such an attack would not be viable and would not render the desired results. However, the initial XSS condition is still important as it allows the attacker to take control of the victim’s browser and plug it into the XSS Proxy tool. Thus, XSS becomes the premise for other attacks that in turn achieve the desired results, rather than remaining the main mean of achieving them.
a) HTTP Authentication
b) IP-based access control methods
These methods prevent the attacker from gaining access to a target server, even though he manages to steal credential information required, because they cannot impersonate the victim’s IP (which is granted access) and their IP is not in the “allowed” list. However, if they can manipulate the victim’s browser through an XSS Proxy tool, they can load documents and gain access to web pages by forcing the victim’s browser to access them and forward them to the XSS Proxy.
c) Client-Side Certificates
When certificates are used for creating secure SSL /HTTPs, the attacker cannot impersonate the victim in order to get access to the target server because they cannot steal and use the victim’s certificate. However, if they can control the victim’s browser, they can gain access to restricted data, in a similar way as in the example above.
Limitations of XSS Proxy tools
How to prevent XSS Proxy attacks
Users should avoid keeping sessions active for extensive periods of time, to reduce the risk of attackers maintaining control of their browser. Users should also be wary of what they click on, and avoid the common ways of getting XSS-ed, such as clicking on malicious Flash objects, or clicking links in SPAM emails. This way, they reduce the likelihood of being victims of the initial XSS attack that establishes the connection to the XSS Proxy.