2

I have read OWASP's XSS prevention cheat sheet but I don't really recognize my application with those rules. I don't feel like I have any of the vulnerabilities pointed out in those rules.

I am doing a PHP application that follows all the following principles:

  1. Not a single user input is displayed directly on the HTML page without being processed and sanitized on the server-side

  2. All my user input are sanitized with htmlentities(). Is that sufficient? (I use prepared statements for SQL injection)

  3. Some of the user input have a maxlength condition of 5 characters on server-side. Does that help protect against XSS? (since I hardly see an XSS code being shorter than 6 characters)

  4. Apart from data from the database, the only user input that is displayed back to the user was sent to the server via ajax, sanitized with htmlentities and reintroduced in the DOM using text() instead of html() (using jQuery)

Should I be concerned about XSS in my case? What else can I do to protect myself from XSS?

halfer
  • 19,824
  • 17
  • 99
  • 186
alexx0186
  • 1,557
  • 5
  • 20
  • 32
  • 2
    Ihmo the attitude to have is: you should always be concerned about XSS, even in Hello World apps. Relying on underlying functionality like maxlength validation/filtering to prevent xss instead of simplying using one of the escaping functions seems lazy. http://stackoverflow.com/questions/1996122/how-to-prevent-xss-with-html-php suggests `htmlspecialchars()` over `htmlentities()` – Mike B Jun 27 '12 at 14:18
  • Hi Mike, thanks for your response. I'm reading through that. – alexx0186 Jun 27 '12 at 14:24
  • 1
    Points are generally good. However #3 is useless. You should never rely on client side validation for security. Properties on input fields will not help your security. However it seems like you have the basics covered. That already makes you ahead of the pack. – Louis-Philippe Huberdeau Jun 27 '12 at 14:26
  • 1
    Here's another good one http://stackoverflow.com/questions/129677/whats-the-best-method-for-sanitizing-user-input-with-php. It's a little broader but has better explanations. – Mike B Jun 27 '12 at 14:27

2 Answers2

1

All my user input are sanitized with htmlentities(). Is that sufficient? (I use prepared statements for SQL injection)

No. First, you should filter on output, not on input. In programming never trust any data, even those from your own database! On input, you just need to escape it for use in SQL, logs, etc. But you also have to filter basic html + some special characters: \0 & < > ( ) + - = " ' \ on output. htmlentities() is just not enough.

Imagine you have a image on site:

<img src="xxx" onload="image_loaded({some_text_from_db});">

{some_text_from_db} would be );alert(String.fromCharCode(58,53,53)

If you escape it just with htmlentities it will become:

<img src="" onload="image_loaded();alert(String.fromCharCode(58,53,53));">

Some of the user input have a maxlength condition of 5 characters on server-side. Does that help protect against XSS? (since I hardly see an XSS code being shorter than 6 characters)

Always check data on server side, if you want also on client side, its ok, but always do it also on server side. Many modern browsers (chrome,ff,opera) allows user to edit page "on the fly" so they can easily remove the maxlength attribute.

Apart from data from the database, the only user input that is displayed back to the user was sent to the server via ajax, sanitized with htmlentities and reintroduced in the DOM using text() instead of html() (using jQuery)

From .text() jquery documentation:

We need to be aware that this method escapes the string provided as necessary so that it will render correctly in HTML. To do so, it calls the DOM method .createTextNode(), which replaces special characters with their HTML entity equivalents (such as < for <).

So probably yes, it should be enough but be aware of escaping from text() like in example above.

Your application filtering should look like this:

  • INPUT USER -> FILTER -> APPLICATION
  • OUTPUT APPLICATION -> FILTER -> USER

Not just input filtering.

Zaffy
  • 16,801
  • 8
  • 50
  • 77
0

I suggest using HTMLawed or HTMLPurifier for user input that needs to be displayed as HTML, or just completely stripping all HTML from user input that shouldn't contain it anyway. HTMLPurifier is the more powerful of the two, and I've never had any XSS issues in any projects with which I have used it.

Lusitanian
  • 11,012
  • 1
  • 41
  • 38