OWASP Mitigation Strategies Part 2: XSS Attacks

Yesterday John showed you how BIG-IP Application Security Firewall can mitigate injection attacks. Today, we’ll cover number three on the list in cross-site scripting. XSS Scripting defined directly from the OWASP XSS page:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.

There are a few attack angles (persistent, reflected, don-based) as well as attack surfaces (client side, server side) and are all far better documented on OWASP and very well summarized on excess-xss.com as well. So what does that look like? Let’s use the example attack scenario from the OWASP page linked above:

Here’s how the attack flow works (image recreated for this specific example from an image at excess-xss.com):

In the phpauction site, I add a new item to sell, but instead of putting in an actual description, I inject the script:

After saving the item, I visit it. Here’s the screen shot confirming that, after connecting to that auction item, my session data was transmitted in the foo query parameter to the attacker site (in yellow at the bottom of the image!)

So how do we stop this nefarious behavior? Well that’s where ASM really shines. John covered how to build a policy in part 2 of his ASM series, which I followed for this example. Once I got the policy built and attached to the virtual server, I ran some test traffic to the auction site and attempted another xss injection, which was successful as the policy was in transparent mode. It did however publish some recommendations it learned from my injection attack, which I accepted and then applied the policy. Clicking the have suggestions column on the signatures row took me to the injections I applied:

Which takes me to this screen showing me the matching signatures:

Once those were accepted and the policy applied (and moved from transparent->blocking!) I then tried to attack again by inserting the same script into the description field of a new item.

Good news! And here’s the report from ASM:

Walking through the report step by step:

• In yellow, this is the log entry that matches my attack attempt
• The green shows me that it was blocked due to matched attack signatures 
• Blue shows me the matching support id and the policy it applied to
• Purple is the list of matching attack signatures
• Light orange shows the actual payload that matched and the particular signature highlighted in red.

XSS is challenging to stop. Thanks to the OWASP project, education is helping improve developer skills in encoding and validating inputs to protect against XSS attacks. But the reality is, there are billions of lines of code out there with no current protection, and even with new development the potential for oversights still exists. Deploying the Application Security Manager as a tool in your toolbox to help protection your applications puts you in a solid position enhancing your defense in depth strategy.