A Mini-paper Reverse Proxy Cross Site Scripting Author: Shalom Carmel Date: January 13, 2005 ** Introduction ** Cross Site Scripting (XSS) requires that the target web site is susceptible (at least to some degree) to html and script injection. This requirement is due to built-in DOM limitations: Modern browsers restrict javascript in one window from interacting with another window, unless both point to the same document domain (protocol + server name + port). This mini-paper describes how to overcome this requirement, and shows a possible XSS attack agains a web application even if it is not XSS-vulnerable at all. For some background on XSS, please read the references. ** Basic Reverse Proxy XSS attack ** The basic attack is simple to create and to verify. It requires an Apache server that host an html page with the attack code, and that runs a reverse http proxy. The reverse proxy is configured to relay some http requests to the victim web site. The attack page contains an iframe pointing at the proxy-relayed address at the local Apache server. By creating an iframe that is supposedly on the same document domain like the attacker, the attacker can access the iframe's contents. Let's see a simple example. The victim site contains a web page http://www.victim.com/v_page.html v_page code:
The attacker site is called http://www.victim.com.victin.com The attacker's apache server is configured to serve html documents from directory /xss , and has the following reverse proxy definitions: ProxyPass / http://www.victim.com/ ProxyPassReverse / http://www.victim.com/ Inside the local xss directory, there is a document called x_page.html. x_page code: shalom When someone accesses the address http://www.victim.com.victin.com/xss/x_page.html the browser will load the page from the attacked web site and attempt to access its contents. While the loading will succeed, the access wil fail. However, when the attacking page is modified to refer to the proxy relay,