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.

Leave a Comment

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

Thank You

We're Excited!

Thank you for completing the form. We're excited that you have chosen to contact us about training. We will process the information as soon as we can, and we will do our best to contact you within 1 working day. (Please note that our offices are closed over weekends and public holidays.)

Don't Worry

Our privacy policy ensures your data is safe: Incus Data does not sell or otherwise distribute email addresses. We will not divulge your personal information to anyone unless specifically authorised by you.

If you need any further information, please contact us on tel: (27) 12-666-2020 or email info@incusdata.com

How can we help you?

Let us contact you about your training requirements. Just fill in a few details, and we’ll get right back to you.