Do you only run htmlspecialchars() on output or is there other functionality you also do?

Question

When outputting user input, do you only use htmlspecialchars() or are there are functions/actions/methods you also run? I'm looking for something that will also deal with XSS.

I'm wondering if I should write a function that escapes user input on output or just use htmlspecialchars(). I'm looking for the generic cases, not the specific cases that can be dealt with individually.

Parameter

Answer 1

I usually use

htmlspecialchars($var, ENT_QUOTES) 

on input fields. I created a method that does this because i use that a lot and it makes the code shorter and more readable.

Distributor

Why the use of ENT_QUOTES (rather than ENT_NOQUOTES as suggested by me)? – Garica

I use ENT_QUOTES for input fields with data from the database. So if the data there has ' or " it will not close the value variable within the input tag. – Odor

Ólafur: yes, on input fields (or more generally attributes) it makes a certain sense. ;-) – Garica

+1. Defining your own function to do echo(htmlspecialchars()) with a nice short name takes the pain out of <?php-style literal output. In this case you'll use it for all your output so the ENT_QUOTES is necessary for the off-chance you use it in a single-quote-delimited attribute value. – Gemology

Heres how people hack yours site when you use htmlspecialchars. ha.ckers.org/blog/20070327/htmlspecialchars-strikes-again – Skitter

Answer 2

Lets have a quick review of WHY escaping is needed in different contexts:

If you are in a quote delimited string, you need to be able to escape the quotes. If you are in xml, then you need to separate "content" from "markup" If you are in SQL, you need to separate "commands" from "data" If you are on the command line, you need to separate "commands" from "data"

This is a really basic aspect of computing in general. Because the syntax that delimits data can occur IN THE DATA, there needs to be a way to differentiate the DATA from the SYNTAX, hence, escaping.

In web programming, the common escaping cases are: 1. Outputting text into HTML 2. Outputting data into HTML attributes 3. Outputting HTML into HTML 4. Inserting data into Javascript 5. Inserting data into SQL 6. Inserting data into a shell command

Each one has a different security implications if handled incorrectly. THIS IS REALLY IMPORTANT! Let's review this in the context of PHP:

1. Text into HTML: htmlspecialchars(...)

2. Data into HTML attributes htmlspecialchars(..., ENT_QUOTES)

3. HTML into HTML Use a library such as HTMLPurifier to ENSURE that only valid tags are present.

4. Data into Javascript I prefer json_encode. If you are placing it in an attribute, you still need to use #2, such as

5. Inserting data into SQL Each driver has an escape() function of some sort. It is best. If you are running in a normal latin1 character set, addslashes(...) is suitable. Don't forget the quotes AROUND the addslashes() call:

   "INSERT INTO table1 SET field1 = '" . addslashes($data) . "'"

6. Data on the command line escapeshellarg() and escapeshellcmd() -- read the manual

-- Take these to heart, and you will eliminate 95%* of common web security risks! (* a guess)

Morgen

Answer 3

You shouldn't be cleansing text on output, it should happen on input. I use a filter that filters all input to the application. It is configurable so that it can allow specific tags/data through when needed (say for a wysiwig editor).

You should do as little processing of text on output as possible so that you ensure speed. Processing it once creates a lot less strain then processing it 500,0000 times.

Skitter

I would have agreed with you, except that generally the theory is to only accept input that is valid, but then you still need to escape output. The problem comes in when someone enter's a quote in their username, you escape it for HTML it becomes useless for PDF generation. – Parameter

Heres the thing though, if you are programming this for the web, how many times will it be viewed on the web verse exported as a PDF. I assume you aren't generating PDF's on the fly on every view. So my point stands strong, in the case of a PHP export you can simply reverse the output. – Skitter

Well, the rule still stands that you want to store the users data as exact as possible in the database and on output modify it as needed. I work on some sites where 50% of web/HTML and 50% is PDF/Excel/etc. – Parameter

Those sound more like web applications and not web sites. If I was to decode all output when its called on my site it would create a stupid amount of overhead. Very few websites on the face of the planet need to support xhtml, pdf, and excel at the same time and output to each. Thats not standard – Skitter

1. Filter input 2. Escape output shiflett.org/blog/2005/feb/my-top-two-php-security-practices – Gourd