Does using the converting input from HTML forms into htmlentities protect attacks invoving JavaScript insertion?

Question

Hi everyone,

I was wondering if converting POST input from an HTML form into html entities, (via the PHP function htmlentities() or using the FILTER_SANITIZE_SPECIAL_CHARS constant in tandem with the filter_input() PHP function ), will help defend against any attacks where a user attempts to insert any JavaScript code inside the form field or if there's any other PHP based function or tactic I should employ to create a safe HTML form experience?

Sorry for the loaded run-on sentence question but that's the best I could word it in a hurry.

Any responses would be greatly appreciated and thanks to all in advance.

racl101

Answer 1

It would turn the following:

<script>alert("Muhahaha");</script>

into

<script>alert("Muhahaha");</script>

So if you're printing out this data into HTML later, you would be protected. It wouldn't protect you from:

"; alert("Muhahaha");

just in case you were echoing into a script like so:

var t = "Hello there <?php echo $str;?>";

For this purpose, you should use addslashes() and a database string escaping method like mysql_real_escape_string().

Answer 2

yes, that is one way to sanitise. it has the benefit that you can always display the database contents without fear of xss attacks. however, a 'purer' approach is to store the raw data in the database and sanitise in the view - so every time you want to show the text, use htmlentities() on it.

however, your approach does not take into account sql injection attacks. you might want to look at http://php.net/manual/en/function.mysql-real-escape-string.php to guard against that.

Answer 3

Yes, do this when you want to display data to a webpage, but I recommend you don't store the HTML in the database as encoded, this may seem fine for large text fields, but when you have shorter titles, say a 32 character, a normal 30 character string that contains an & would become & and this would either cause a SQL error or the data to be cut off.

So the rule of thumb is, store everything row (obviously prevent SQL injection) and treat EVERYTHING as tainted, no matter where it comes from: the database, user forms, rss feeds, flat files, XML, etc. This is how you build good security without worrying about the data overflowing, or the fact you might oneday need to extract the data to a non web user where the HTML encoding is a problem.