Changes to the community structure and the menu bar
Significant changes have happened to the structure of our community and our drop down menu bar. READ ABOUT IT HERE
Protect Your Assets

Application Security Testing – A journey from XSS to System Shell

Application Security Testing – A journey from XSS to System Shell


From XSS to shell?

In ordinary circumstances, XSS is ultimately an attack against a user, not an attack against a server.  For instance, a web forum that is vulnerable to XSS would allow an attacker to steal cookies from the site’s visitors. So how do we go from XSS to server access?



In the early days of the web, dynamic web pages relied on Common Gateway Interface (CGI) scripts. In short, the web server received a request from a browser and then passed some of the information it received to a CGI script. The CGI script would then process the request and return the results back to the web server, which in turn sent the results back to the web browser.


To simplify this, web servers used a technology called Server-Side Includes (SSI). With SSI, not only is it possible to execute system commands, it’s also possible to do fancy things, like displaying time, remote IP addresses, and more.


To make executing CGI scripts as convenient as possible, all a webmaster (the old term for someone who built web pages) had to do is include:


<!--#echo var="REMOTE_ADDR" -->

into an SSI enabled webpage to display the remote IP address. If, for example, the webmaster wanted to show how long his server has been up, he could insert:



<!--#exec cmd="uptime" -->


That last command, executes the Linux “uptime” command.


Old technology + XSS = server access

Now that we understand all of the pieces of the puzzle, we can put them together and gain server access.

If you look closely, you will find that the special characters needed for XSS are the same ones used to create server-side includes. Here are a couple of examples of what an XSS proof of concept looks like:


<img src=x onerror=prompt(document.domain);>


To test a web form for a XSS vulnerability, a tester could insert



 in a name field. If this pop-up is displayed when the name is displayed on a page:



then the site is vulnerable to XSS. The next thing you should do is attempt to inject some SSI code. Instead of inserting:




you should try:


<!--#printenv -->

If you get a list of variables, you will know that the server you are testing has SSI enabled.

Some servers are configured to prevent the use of the exec function. To test, try putting in:


<!--#exec cmd="id" -->


If you see:


uid=0(root) gid=0(root) groups=0(root)

not only do you have the ability to execute commands, you are also executing commands with administrator permissions!



If you are a system administrator, you should check and make sure that SSI is disabled on your webservers. The configuration on how to do this will be dependent on the type of web server that is in place.


As a next step, the developers responsible for that application should examine the XSS flaw and use appropriate mechanisms to adequately sanitize the special characters. An excellent source on how to effectively prevent XSS attacks can be found here:



We hope you enjoyed learning how to go from XSS to a system shell! For more great articles in mobile and web application security testing, please check out our other articles on this blog.

About the Author


Lucas Gates is an Advanced Dynamic Tester with the Fortify On Demand team who enjoys responsible hacking.


I think you're confusing two distinct attacks with similar looking vectors here.  XSS attacks are generally considered to only relate to the injection of browser-side scripting languages (e.g. JavaScript, VBScript).


Injection attacks that affect the server-side of an application like SSI injection, SQL injection are separate categories from XSS.


What can be confusing in this case is that the test vectors for these two classes of issue are very similar (in that they involve the use of < and > characters).

Absent Member.

Hi Rory,


Thank you for your comment! You perfectly described (in less words) what I was trying to convey -- That SSI can use the same attack vector as XSS. 


So if you happen to find XSS, you might as well try SSI to see if it is enabled!


Hope you have a great set of holidays!



One thing is unclear about this explanation.  In your explanation you state "If you look closely, you will find that the special characters needed for XSS are the same ones used to create server-side includes."  But there is nothing to look at thatt shows what the special characters are to create an XSS.  So there is no way for us to know what in the next part looks like the XSS characters.


Did I miss something?  This explanation appears to be designed for newbees like me, so if I am supposed to already know what the XSS codes are, it's not going to get the point across.



Absent Member.

Hi Perry,


Thank you for taking the time to help improve the post! Cross-site scripting, (commonly referred to as XSS) is an attack that abuses the lack of input validation when submitting input to a website. 


By using input, such as:



 an attacker will be able to alter the behavior of the website. The example above will simply produce a pop-up with "1337". A malicious attacker, however, can use this flaw to inject malicious code into the webbrowser, steal user information, and more.


Now, switching back to the article, if the website isn't adequately filtering "<" and ">" (which would make it vulnerable to XSS), it may be possible to inject a Server-Side Include (SSI). Here is an example of SSI:


<!--#printenv -->


While Cross-site Scripting is an attack that is commonly talked about, it isn't widely understood.

OWASP has a great explanation for different types of XSS.


If you still have questions, please feel free to reach out!


Best Regards,