What is XSS vulnerabilities and how do I make sure my website doesn’t have them?
Wikipedia Definition: Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side script into web pagesviewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.
XSS can be server side or DOM-based.
A very simple XSS DOM-based vulnerability would be something as simple as submitting a small script in a form. An example would be instead of typing your name in the “First Name:” field you type:
If you press submit and you get an alert box with “Eddie” as the message then you have found a simple DOM-based XSS exploit. A Non-persistant exploit to be exact.
Wikipedia: Non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the request.
Fixing this issue form, or Sanitizing the request could simply be stripping special characters from the submission form.
XSS can get much more complicated. Let’s take this persistent cross-zone scripting vulnerability as an example. This is a real example that was an issue on MySpace at one time and coupled with a computer worm which allowed execution of arbitrary code and listing of filesystem contents via a QuickTime movie. This example also is considered to be a cross-zone script vulnerability as well. This is basically taking advantage of an exploit with a browser giving the attacker content (scripts) in unprivileged zones to be executed with the permissions of a privileged zone. Quite nasty indeed. We’ll have a separate post on this soon.
Wikipedia: Persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on “normal” pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.
You might be wondering “How do I fix my website? There are just too many things to try and so many places to try them”. A few simple measures can go a long ways:
- As I stated before correctly escaping input before it is processed would eliminate issues such as the script example I wrote about earlier. But I think it’s best not to tackle this on your own. There are just so many clever little ways to find a trip up, it’s best to get behind a community driven auto-escaping template. Even google has one.
- HTML sanitation: There is a bunch of things out in the wild to help with this. You can keep a white & black list of your own. You can find a community built one, or you can use some open source modules on your site to help you out. An open source example would be (I’m just randomly picking the first one that came up in my google search for “HTML sanitation”) OWASP.
Links to check out: