OWASP AppSec Day - Dev Guide to XSS

Next stop on the security conference trip is XSS - Cross-site scripting. The speaker was Felix Shi, another security expert from New Zealand. He was also really funny and I think this was my favourite talk out of all the talks I attended. His talk was quite easy to follow, and since I only have a basic understanding of XSS, all the examples he gave were great.

Have you ever tried to enter something in a text field, only to find that they're really strict about what kind of characters you can enter? It's probably a good thing that most people don't know how to use semi-colons anymore, because they'll probably find that their input ruined by some websites. Now you'll see one of the reasons why!

What is XSS?
XSS is when someone manages to run their own code on your site. This happens because when you allow users to enter stuff into a field, it's very hard to control what they enter. Most users will follow the instructions and enter their name as labelled, but there's nothing to stop someone from entering anything, including code, like in this xkcd comic: https://xkcd.com/327/ (the exploit in this is SQL injection, not XSS, but the idea is the same).

For instance, someone might have a textbox for you to enter your name, and then they take that input, and wrap it in some tags to display on the page.

e.g. html = "Hello " + name + "!
;

Which if you enter a proper thing, will result in Hello Anna!
.

However, if you put something malicious in there, like
Hello


In this video, you can see that the page takes one of the values in the URL and  displays that as the title. So when he modifies the value, he's able to change the way the title on the page is displayed.

In the second video, he changed his message to be some garbage, then adds a script so that when the page loads with an error, it redirects to another page. The brilliant thing about this, which is an example of persisted XSS, is that the page loads all the old messages, so every time the page loads (for anyone), the error is thrown and the person gets redirected to another page. This is how you can deface a website, but if you are a particularly bad baddie, you can redirect someone to a phishing page and steal their credentials, or combine with another exploit to get them to download malware.

Defense against XSS
Don't allow user input (he was joking)

Validate, encode / escape user provided data: this may involve replacing special characters that tend to be in scripts, like the angle-brackets < >, quote marks ' ". Modern web frameworks do this by default, and this feature tends to be opt out, which is great as it stops people who don't really know what they're doing from leaving huge holes in their websites. If you're wondering why would you want to turn it off at all? Mostly it's because of having to deal with legacy systems, that were written before this stuff was the norm.

Be wary of user attributes being used in other parts of the page, e.g. gravatar / alt-text. This can be another way to allow someone to add a script.

Having multiple security mechanisms make it hard for attackers to use XSS on your site. Along with what I've already mentioned, enable content security policy (inline javascript can't be run unless unsafe-inline is enabled and it also blocks things like eval - however, support for it is inconsistent across browswers), tag sensitive cookies with security tags (HttpOnly: can't be read by javascript, Secure: cookies can only be sent via HTTPS).

He went on to describe certain input validation techniques.

Do people really need < or > in their name? You can't block out apostrophes, or a large part of Ireland will hate you - not to mention if you force people to enter alphanumeric characters, what happens if someone wants to enter their name in Chinese or Hindi?

Don't attempt to cleanse the data and save it, just outright reject it, it's safer that way.

-----------------------

Hopefully you have a better idea of XSS. I think it's fascinating that talks like these make you feel good about thinking like a criminal - it's all for the sake of being secure, right?!