How to prevent code injection attacks in PHP?

• mysql_real_escape_string used when insert into database
• htmlentities() used when outputting data into webpage
• htmlspecialchars() used when?
• strip_tags() used when?
• addslashes() used when?

htmlspecialchars() used when?

htmlspecialchars is roughly the same as htmlentities. The difference: character encodings.

Both encode control characters like <, >, & and so on used for opening tags etc. htmlentities also encode chars from other languages like umlauts, euro-symbols and such. If your websites are UTF, use htmlspecialchars(), otherwise use htmlentities().

strip_tags() used when?

htmlspecialchars / entities encode the special chars, so they're displayed but not interpreted. strip_tags REMOVES them.

In practice, it depends on what you need to do.

An example: you've coded a forum, and give users a text field so they can post stuff. Malicious ones just try:

pictures of <a href="javascript:void(window.setInterval(function () {window.open('http://evil.example');}, 1000));">kittens</a> here

If you don't do anything, the link will be displayed and a victim that clicks on the link gets lots of pop-ups.

If you htmlentity/htmlspecialchar your output, the text will be there as-is. If you strip_tag it, it simply removes the tags and displays it:

pictures of kittens here

Sometimes you may want a mixture, leave some tags in there, like <b> (strip_tags can leave certain tags in there). This is unsafe too, so better use some full blown library against XSS.

addslashes

To quote an old version of the PHP manual:

Returns a string with backslashes before characters that need to be quoted in database queries etc. These characters are single quote ('), double quote ("), backslash () and NUL (the NULL byte).

An example use of addslashes() is when you're entering data into a database. For example, to insert the name O'reilly into a database, you will need to escape it. It's highly recommeneded to use DBMS specific escape function (e.g. mysqli_real_escape_string() for MySQL or pg_escape_string() for PostgreSQL), but if the DBMS you're using does't have an escape function and the DBMS uses \ to escape special chars, you can use this function.

The current version is worded differently.

Only encode data at the point where it goes into the system it needs to be encoded for — otherwise you will run into situations where you want to manipulate the real data.

For SQL injection - use bound variables as described in How can I prevent SQL injection in PHP? (it talks about prepared statements, but it is the binding that gives you protection, not the preparation).

For XSS - if you are writing into HTML at point where either HTML or text is specified. Use htmlentities at the point where you generate your document. I would avoid storing the data in that form in the database (except possible in a write-rare-read-often system where CPU performance/disk access times were becoming and issue - then I would have a raw_ and an html_ version of the column … or just use memcached or similar).

If you are letting users enter URLs then you need to be more careful, as javascript:do_evil() is a valid URI that will execute (e.g. as an href for a clicked upon link or (in some browsers) the src of an image that is just loaded).

You only need to use mysql_escape_string() when inserting into a database and htmlentites when displaying the HTML. This is sufficient if you want to prevent a simple injection attack, but there are no doubt many other security issues you should be aware of when developing a web app, another major one being cross site request forgeries.

I wouldn't use htmlentities() when inserting data into the database or querying the database. If the data in you database is stored as entities, that data is then only useful to something that understands html entities.

You have to use different escaping mechanisms for different types of output, e.g. SQL - mysql_real_escape_string(), HTML - htmlentities() or htmlspecialchars(), shell - escapeshellarg(). This is because the characters that are 'dangerous' are different for each one - there isn't a magic way you can make any data safe for any output medium.

Take a look at this site PHP Security Consortium. I found it to be a good site for an overall overview on PHP Security (SQL Injection and XSS included).