Cross Site Port Attacks – XSPA – Part 1

This is the first of a 3 part series of blog posts that explain Cross Site Port Attacks(XSPA) in greater detail. I disclosed this as a speaker at the recently concluded OWASP AppSecUSA2012, Austin and thought it was about time I blogged as well.

Read Cross Site Port Attacks – XSPA – Part 2
Read Cross Site Port Attacks – XSPA – Part 3

Update: Please note that this is independent research conducted as part of my involvement with Bug Bounty programs with several companies and although related to Alexander Polyakov’s research on SSRF, the similarity in findings are merely a coincidence and are focused on showing how common XSPA/SSRF are in popular web applications.


Many web applications provide functionality to pull data from other webservers for various reasons. Using user specified URLs, web applications can be made to fetch images, download XML feeds from remote servers, text based files etc. This functionality can be abused by making crafted queries using the vulnerable web application as a proxy to attack other services running on remote/local servers. Attacks arising via this abuse of functionality are named as Cross Site Port Attacks (XSPA). 

What is XSPA? 

An application is vulnerable to Cross Site Port Attacks if the application processes user supplied URLs and does not verify/sanitize the backend response received from remote servers before sending it back to the client. An attacker can send crafted queries to a vulnerable web application to proxy attacks to external Internet facing servers, intranet devices and the web server itself using the advertised functionality of the vulnerable web application. The responses, in certain cases, can be studied to identify service availability (port status, banners etc.) and even fetch data from remote services in unconventional ways.

The following screengrab shows providing this functionality:

XSPA allows attackers to abuse available functionality in most web applications to port scan intranet and external Internet facing servers, fingerprint internal (non-Internet exposed) network aware services, perform banner grabbing, identify web application frameworks, exploit vulnerable programs, run code on reachable machines, exploit web application vulnerabilities listening on internal networks, read local files using the file protocol and much more. XSPA has been discovered with Facebook, where it was possible to port scan any Internet facing server using Facebook’s IP addresses. Consecutively, XSPA was also discovered in several other prominent web applications on the Internet, including Google, Apigee, StatMyWeb,,, Pinterest, Yahoo, Adobe Omniture and several others. We will take a look at the vulnerabilities that were present in the above mentioned web applications that could be used to launch attacks and perform port scans on remote servers and intranet devices using predefined functionality.

Examples of Implementation

Let us look at some examples of PHP implementations of file fetching via user supplied URLs. XSPA affects web applications written in any language as long as they let users decide where the data would be fetched from. Please note the examples shown below are neither clean nor secure, however most of the parts of the code outlined below have been obtained from real world application sources.
1.    PHP file_get_contents:

if (isset($_POST['url']))
$content = file_get_contents($_POST['url']);
$filename = './images/'.rand().'img1.jpg';
file_put_contents($filename, $content);
echo $_POST['url']."";
$img = "";
echo $img;

This implementation fetches data as requested by a user (an image in this case) using the file_get_contents PHP function and saves it to a file with a randomly generated filename on the disk. The HTML img attribute then displays the image to the user.

2.    PHP fsockopen() function:

function GetFile($host,$port,$link)
$fp = fsockopen($host, intval($port), $errno, $errstr, 30);
if (!$fp) {
echo "$errstr (error number $errno) \n";
} else {
$out = "GET $link HTTP/1.1\r\n";
$out .= "Host: $host\r\n";
$out .= "Connection: Close\r\n\r\n";
$out .= "\r\n";
fwrite($fp, $out);
while (!feof($fp)) {
$contents.= fgets($fp, 1024);
return $contents;

This implementation fetches data as requested by a user (any file or HTML) using the fsockopen PHP function. This function establishes a TCP connection to a socket on the server and performs a raw data transfer.

3.    PHP curl_exec() function:

if (isset($_POST['url']))
$link = $_POST['url'];
$curlobj = curl_init();
curl_setopt($curlobj, CURLOPT_POST, 0);
curl_setopt($curlobj, CURLOPT_RETURNTRANSFER, 1);
$filename = './curled/'.rand().'.txt';
file_put_contents($filename, $result); echo $result;

This is another very common implementation that fetches data using cURL via PHP. The file/data is downloaded and stored to disk under the ‘curled’ folder and appended with a random number and the ‘.txt’ file extension.

In the next part of this series, we shall see some of the attacks that can be launched using this vulnerbility. XSPA allows attackers to target the server infrastructure, mostly the intranet of the web server, the web server itself and any public Internet facing server as well. Currently, I have come across the following five different attacks that can be launched using XSPA:

1. Port Scanning remote Internet facing servers, intranet devices and the local web server itself. Banner grabbing is also possible in some cases.
2. Exploiting vulnerable programs running on the Intranet or on the local web server
3. Attacking internal/external web applications that are vulnerable to GET parameter based vulnerabilities (SQLi via URL, parameter manipulation etc.)
4. Fingerprinting intranet web applications using standard application default files & behavior
5. Reading local web server files using the file:/// protocol handler.

We will see examples of each of these scenarios in several prominent web applications on the Internet as well.

15 thoughts on “Cross Site Port Attacks – XSPA – Part 1”

  1. Thanks Alexander!
    XSPA allows attacks on not only internal and external HTTP services, but any program listening on arbitrary reachable ports. The next two posts should make this clear. Port scanning is only one of the attacks that is possible. SSRF and XSPA are very similar but different on several points, some of which are highlighted below:
    1. SSRF is non HTTP dependent. SSRF works with services that are not HTTP at source (like MSSQL/Oracle etc.)
    2. SSRF uses XXE to attack internal applications and programs unlike XSPA which is self contained.

    I agree that multiple terminologies for the same vulnerability is not a great idea, but subtle differences between SSRF and XSPA enforces this idea. I would request you to review the remainder of the posts before we reach to any conclusion.

  2. I confirm. This is a specific case of SSRF. Also, the PHP code written above is highly insecure and it does not even validate the Content Type of data fetched from a remote resource. If proper content validation is done (which is the case in most secure web applications), this will not work.

  3. I found this vulnerability after observing this behavior in several 'secure' live web applications including Facebook, Google, Adobe, Apigee and Mozilla. There was no clear documentation anywhere that this had been done before. I also state explicitly that “Please note the examples shown below are neither clean nor secure, however most of the parts of the code outlined below have been obtained from real world application sources.”

    Proper content validation of response on the server is in fact one of the fixes that I will discuss in future posts, thank you for pointing this out.

  4. This post is part of my paper that I wrote while doing independent research into Bug Bounty programs. I have presented this at the AppSecUSA and will be speaking at BlackHat AD as XSPA. The idea that SSRF is a more appropriate term is open for discussion. I'm not looking to standardize this as XSPA, only that when I started researching this, I was unaware (as are most people even today) that SSRF even existed. I will give due credit to people as and when required, but please note that this is independent research conducted in the absence of the knowledge that SSRF even existed.

  5. Wait, you're a professional pentester and you haven't met the idea of manipulating user supplie URLs to access other resources from the IP of the server until now? really?

    Everyone at my company has been using this for years, we don't feel the need to give it a name and champion it as if it ws a new attack concept.

    I wouldn't mind, but I feel this kind of behaviour confuses what is a plain and simple underlying philosophy: user input should be restricted to only perform the subset of possible actions which are intended by the application developers.
    Very simple, very clear.

    I understand that you made this post and gave those presentations in good faith, but for the love of god please stop adding acronyms and muddying the waters of fundamental principles which illuminate security risks. It scares people off and bogs down developers trying to learn how to write secure code, as they restle not with the problem, but with its taxonomy.

  6. If i'm not wrong SSRF is introduced by Alexander Polyakov back in 2008 and you are claiming that you got to know about this in 2012 after you invented XSPA in 2012 😛
    I have read both papers SSRF and XSPA..both are one and same if you look at little deeply…you made changes to hide the truth…
    after 4 years…still you didn't aware of ssrf…I think lol

Leave a Reply

Your email address will not be published. Required fields are marked *