Have Geek Brain

Does transforming input from HTML forms to htmlentities protect JavaScript injection attacks?

I was wondering if converting the POST input from an HTML form to html entities (via the PHP htmlentities () function or using the FILTER_SANITIZE_SPECIAL_CHARS constant in tandem with the PHP filter function filter_input ()) would help protect against any attacks the user tries to insert any JavaScript code inside the form field, or if there is any other PHP function or tactic I should use to create a secure HTML image?

Sorry for the uploaded proposal question, but the best thing I can say is in a hurry.

Any answers would be greatly appreciated and in advance.

racl101

+2


a source to share


3 answers


This will result in the following:

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

at

&lt;script&gt;alert("Muhahaha");&lt;/script&gt;

So, if you print this data to HTML later, you will be protected. This will not protect you from:



"; alert("Muhahaha");

just in case you echo into your script like so:

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

For this purpose, you should also use the addslashes()

database string escaping method, for example mysql_real_escape_string()

.

+2


a source


yes, this is one of the disinfection methods. has the advantage that you can always display the contents of the database without fear of xss attacks. however, a "cleaner" approach is to store the raw data in the database and sanitize it in the view - so every time you want to show text, use htmlentities () on it.



however, your approach does not account for SQL injection attacks. you can look at http://php.net/manual/en/function.mysql-real-escape-string.php to guard against this.

0


a source


Yes, do this when you want to display data on a web page, but I recommend that you do not store HTML in the database as encoded, this may seem fine for large text fields, but when you have shorter headers say 32 characters is a normal string with 30 characters which contains a and will become and this will cause the SQL error or data to be truncated.

So a rule of thumb: keep all strings (obviously prevent SQL injection) and treat EVERYTHING as messed up, no matter where they come from: database, custom forms, rss feeds, flat files, XML, etc. This is how you create good security without worrying about data overflows, or that you might need to fetch data from a non-web user where HTML coding issue is an issue.

0


a source






More articles:


All Articles