How to stop XSS

Illustration of a policeman stopping a thief with the word XSS

Last week I wrote about Cross-Site Scripting, and the serious consequences it can have.

According to OWASP, XSS affects about two thirds of all applications. That statistic should scare you!

Now that I have your attention, let’s look at how we can stop XSS.

Untrusted data

Untrusted data is at the heart of XSS.

  • Untrusted data that is submitted to the server leads to server XSS.
  • Untrusted data that is used to update the DOM leads to client XSS.

Untrusted data is data that has come in across a trust boundary. In web applications, that is often data that comes from the HTTP request i.e. the user. This can be in the form of URL parameters, form fields, headers or cookies. Untrusted data can also come from other systems, such as another database or a web service.

The golden rule for server XSS

The golden rule is to never use untrusted data.

On the server, you must sanitise the input. You must check data received from the client before you either store or output it.

You should validate on two levels:

  • Syntactic validation checks that the syntax of fields is correct. For example, a data value has a particular structure.
  • Semantic validation checks that the values of the fields are correct within the business context. For example, a date value might need to be within 12 months of the current date.

You can validate in different ways:

  • Whitelist validation is when you check the value against a fixed list of values.
  • Blacklist validation is when you check to see if the value contains dangerous characters.

Use whitelist validation where possible, as it is more effective.

For full details, read the OWASP Input Validation Cheat Sheet.

The golden rule for client XSS

The golden rule is the same: never use untrusted data.

On the client, you might need to use untrusted data to create an element, or an attribute, or change a style setting. In that case, the OWASP rule is simple: encode. OWASP recommends the following:

  • HTML encode before inserting untrusted data into HTML element content.
  • Attribute encode before inserting untrusted data into HTML common attributes.
  • JavaScript encode before inserting untrusted data into JavaScript data values.
  • CSS encode and validate before inserting untrusted data into HTML style property values.
  • URL encode before inserting untrusted data into HTML URL parameter values.

For full details, read the OWASP XSS Prevention Cheat Sheet.

Tools to help you

It’s hard to find your own vulnerabilities. That’s why developers have created detection tools to help you.

Many of these tools are not free, and you will want to do some research before you buy a licence. But you can start with a simple online scan using the free version of XSS Scanner.

If you haven’t already, join our Security Spotlight series. You’ll get a weekly email about web application security.

Leave a Comment

Your email address will not be published. Required fields are marked *