Protection against XSS exploits?

Question 1

I'm newish to PHP but I hear XSS exploits are bad. I know what they are, but how do I protect my sites?

Question 2

To prevent from XSS attacks, you just have to check and validate properly all user inputted data that you plan on using and dont allow html or javascript code to be inserted from that form. Or you can you Use htmlspecialchars() to convert HTML characters into HTML entities. So characters like <> that mark the beginning/end of a tag are turned into html entities and you can use strip_tags() to only allow some tags as the function does not strip out harmful attributes like the onclick or onload.

Question 3

safe2() is clearly htmlspecialchars()

In place of safe1() you should really be using HTMLPurifier to sanitize complete blobs of HTML. It strips unwanted attributes, tags and in particular anything javascriptish. Yes, it's slow, but it covers all the small edge cases (even for older IE versions) which allow for safe HTML user snippet reuse. But check out http://htmlpurifier.org/comparison for alternatives. -- If you really only want to display raw user text there (no filtered html), then htmlspecialchars(strip_tags($src)) would actually work fine.

safe3() screams regular expression. Here you can really only apply a whitelist to whatever you actually want:

var a = "<?php echo preg_replace('/[^-wd .,]/', "", $xss)?>";

You can of course use json_encode here to get a perfectly valid JS syntax and variable. But then you've just delayed the exploitability of that string into your JS code, where you then have to babysit it.

Is it also safe in all browsers (specifically IE6)?

If you specify the charset explicitly, then IE won't do its awful content detection magic, so UTF7 exploits can be ignored.

Question 4

htmlspecialchars() is enough to prevent document-creation-time HTML injection with the limitations you state (ie no injection into tag content/unquoted attribute).

However there are other kinds of injection that can lead to XSS and:

There are no <script> tags in the document.

this condition doesn't cover all cases of JS injection. You might for example have an event handler attribute (requires JS-escaping inside HTML-escaping):

<div onmouseover="alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!

or, even worse, a javascript: link (requires JS-escaping inside URL-escaping inside HTML-escaping):

<a href="javascript:alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!

It is usually best to avoid these constructs anyway, but especially when templating. Writing <?php echo htmlspecialchars(urlencode(json_encode($something))) ?> is quite tedious.

And... injection issues can happen on the client-side as well (DOM XSS); htmlspecialchars() won't protect you against a piece of JavaScript writing to innerHTML (commonly .html() in poor jQuery scripts) without explicit escaping.

And... XSS has a wider range of causes than just injections. Other common causes are:

allowing the user to create links, without checking for known-good URL schemes (javascript: is the most well-known harmful scheme but there are more)
deliberately allowing the user to create markup, either directly or through light-markup schemes (like bbcode which is invariably exploitable)
allowing the user to upload files (which can through various means be reinterpreted as HTML or XML)

Question 5

The misconception is that you want to escape the input, which is wrong. You have to filter the output (and database is also an output).

It means that when the form is submitted, you use mysql_real_escape_string() to send (output) data to database, and you use htmlspecialchars() to output the content on the screen. The same principle applies to regular expressions, where you'd use preg_quote(), and so on.

No matter where data is coming from, you have to escape it in the context of where you are sending it to.

So for preventing XSS attacks, you must use htmlspecialchars() / htmlentities(). mysql_real_escape_string has nothing to do with XSS (but you still have to use it when you are sending data to the database).

Question 6

As mentioned, prepared statements are one of the best ways to prevent SQL injections. i.e., you shouldn't add your parameters as part of the final query string. You should use parameter placeholders, and add the parameters via a key/value array.

If you're using PDO, have a look at this page, which describes prepared statements in greater detail:

http://php.net/manual/en/pdo.prepared-statements.php

A quite thorough explanation of PHP's input filters (and a good article on sanitization) can be found here:

http://coding.smashingmagazine.com/2011/01/11/keeping-web-users-safe-by-sanitizing-input-data/

Check here for PHP's own filters/sanitization functions:

http://www.php.net/manual/en/filter.filters.php

You are probably interested in the filter_var and filter_input functions:

http://www.php.net/manual/en/function.filter-var.php
http://www.php.net/manual/en/function.filter-input.php

Also, this question has some good pointers: What's the best method for sanitizing user input with PHP?

This question has very good pointers too: What are the best PHP input sanitizing functions?

Protection against XSS exploits?

Answers

php,xss