F5 Security on Owasp Top 10: XSS

Part of the F5/Owasp Top Ten Series

Number two on Owasp list is Cross Site Scripting (XSS). Their definition is

“XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions,deface web sites, or redirect the user to malicious sites. “

Whats that mean? Simply put, an evil attacker type will inject a snippet of code onto a website, commonly through comment postings. Then, when other users access the page, their browser executes this bit of code. What does this snippet do? Could pop up an alert box… or perhaps load an invisible iFrame? GASP!

Oh noes!

Let’s XSS:

A very basic example of this is pretty straight forward. First we decide what we want to do? For this test, I want to increase the number of hits to one of my pages. Wouldn’t it be nice if everyone who visited a site automatically opened a page to my target page? Thank goodness for javascript.

Now, I just need a page that people will want to access, and a site that is vulnerable. Oh look! Hackit auctions is here when I need them.

Now, I just need to create an item to sell, something people will click. Voila! Who would not want to bid on a flying monkey?

Evil Auction Posting

What is that strange language in the box?

<(ESC)script>

window.open("https://devcentral.f5.com/s/articles/f5-security-on-owasp-top-10-injections","","width=1,height=1");

</(ESC)script>

What does this little thing do?

You load the auction page for flying monkeys. What you see:

What your browser sees:

“Hey browser, please executive me as a javascript. What I want you to do is open another browser window to this special wicked awesome page. Then quit the script”

And the browser says:

“Ok javascript, whatever you say.”

Result:

You’ve now loaded a page that you did not actually intend to.

Let’s fix

So, this is a fun one. The execution is actually on the client side of the connection. So the defense mechanisms on the server side are based around not allowing the script to exist on the paged, either by blocking it when someone attempts to post it, or more uncommonly, blocking it from leaving the network (detecting the script and removing it from the return data).

Wouldn’t it be nice if they could just fix it at the code level and be done with it? Well, this one they can (fairly simple escaping of characters). But we all know is reality, most code changes require scrums, waterfalls, validations, testing, and a flood of tears.

In our case, we already have the Virtual server for this website on the LTM/ASM (Virtual Edition 11.1). Again we can follow similar steps from the injection article to put the defense in place. Let’s say you already have the policy in place, and you need to add the protection to the site.

1. Make sure that you have a wildcard parameter in the parameters list. Then click on it and make sure that

“Perform Tightening”

Is checked. This will ensure that the policy learns the new parameters for the new auction item page.

If you made any changes, make sure to click save and then apply the policy change.

2. Now the policy is ready to learn some new parameters. Next, I’ll go to the site and run through the “Sell an Item” Page. By submitting all the data, I let the ASM learn what parameters are coming from this page.