In his book “Web Application Vulnerabilities: Detect, Exploit, Prevent”, Steve Palmer describes XSS Proxies as cross-site scripting exploitation tools that allow attackers to temporarily take control over the victim’s browser. XSS Proxy functions as a web server which takes commands from the attacker via a web browser, delivering malicious JavaScript payloads to and retrieving information from the victim’s browser (such as HTML sources of content that the victim is loading or content that the attacker forces the user to access on the vulnerable server).

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.

The use of such tools slightly alters a traditional attack flow since the attacker does not need to steal cookies and hijack the session to impersonate the user and gain access to restricted content. With such a tool, an attacker has the means to access and change content directly by controlling the victim’s browser, thus taking advantage of XSS vulnerabilities in scenarios where simple exploitation would not yield the desired results (such as stealing credentials when the target server does not use cookies for authenticating sessions).

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

When using HTTP Authentication, the attacker cannot steal the credentials via an XSS attack (assuming that the server being accessed does have an XSS vulnerability) because the JavaScript, delivered as payload during such an attack, would not have access to the credentials. However, if the attacker can control the victim’s web browser, it can force it to access the target server with an authenticated session and then forward the HTTP headers containing the credentials to the XSS Proxy.

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.

Taking control via XSS Proxy

Taking control via XSS Proxy (click to enlarge)

Limitations of XSS Proxy tools

Although XSS Proxy is a powerful tool in the hands of a knowledgeable attacker, it is limited by the victim’s actions, and the ability of JavaScript code to read content. The XSS Proxy can control the victim’s browser only for as long as the hijacked tab/window is active. If the user closes the tab/window, the attacker loses control over the victim’s browser. The attacker uses code to identify and communicate with the hijacked browser tab so any changes in the tab order may cause the attacker to fail to identify the compromised tab and lose control over the victim’s browser.

In addition, when accessing content on the domain of the vulnerable server, through the victim’s browser, the attacker is limited to receiving HTML-based content (files or pages) and cannot receive content which is not accessible via JavaScript (PDF, Flash objects, etc.). Consequently, although the victim loads a PDF file from the vulnerable server, either as desired or forced by the XSS Proxy, the attacker will not be able to read its content.

How to prevent XSS Proxy attacks

Client-side

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.

Server-side

All the classic XSS prevention methods are useful because if there is no initial XSS condition, then the browser cannot be hijacked. Additional methods such as implementing short session expiry times, andavoiding saving documents or content in formats that JavaScript can read, further helps prevent attacks through XSS proxies. Periodic use of appropriate vulnerability scanners also ensures the detection of XSS vulnerabilities that may form the basis of XSS attacks through XSS Proxies.

SHARE THIS POST
THE AUTHOR
Acunetix

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.

Comments are closed.