views:

140

answers:

4

Hi,

It has a been a long day but I cannot seem to choose in my own head which is better or if I should use both.

Basically what should I use to sanitize user inputted values. Is it either the htmlentities or preg_match function ?

I will then if the value goes into a sql query use the mysql_real_escape_string function but only until I change it to a prepared statement then I can remove this.

Or would it be good idea to use both htmlentities and preg_match ?

+2  A: 

Why didn't you just ask this in your previous question ?

Use preg_match before you do any escaping, to ensure the data meets the whitelist of what you expect it to be. Then use the escape for the database insertion. This is called defense in depth (i.e. more than one layer of security checking, in case the attacker can break through the first layer).

Mike
Well I was just asking a general question out of curiosity.
Oliver Bayes-Shelton
I just updated my answer to make it a bit clearer. You'd use both approaches to provide defense in depth. More layers to brake makes your app harder to exploit.
Mike
+1 For the defense in depth. Good stuff Mike
Mike B
It doesn't make it harder if the layers are redundant. It is still the same level of difficulty.
Rook
You're right that the layers need to be different to be of use. Here we've got the database layer and the presentation layer. Both have different weaknesses and strengths. htmlentities is used to display output - most likely output from the database. Whitelisting (preg_match) is used to ensure bad input never makes it into the database. In the event someone compromises your database with evil input (or for some reason there's a bug in your regex), you'll still have some level of protection against XSS via the htmlentities, and vice-versa.
Mike
A: 

Its better to have too many validation checks and sanitization routines than too few. The system is no more or less secure by adding redundancy. Ether its a vulnerability or its not, its a Boolean not a Float. When I am auditing code and I see redundant secuirty measures I think of it as a red flag and it encourages me to dig deeper. This programmer is paranoid and perhaps they do not understand the nature of vulnerabilities although this is not always true.

There is another problem. htmlentities() doesn't always stop xss, for instance what if the output is within a <script></script> tag or even an href for that matter? mysql_real_escape_string doesn't always stop sql injection, what if: 'select * from user where id='.mysql_real_escape_string($_GET[id]);. a preg_match can fix this problem, but intval() is a much better function to use in this case.

I am a HUGE fan of prepared statements. I think this is an excellent approach because by default it is secure, but passing a variable to mysql_real_escape_string() before a prepared statement is just going to corrupt the data. I have seen a novice fix this problem by removing all validation routines thus introducing a vulnerability because of redundancy. Cause and Effect.

Web Application Firewalls (WAF) is an excellent example of how layers can improve security. WAF's are highly dependent on regular expressions. They try to look at the bigger picture and prevent nasty input or at the very least log it. They are by no means a silver bullet and should not be the only security measure you use, but they do stop some exploits and I recommend installing mod_security on production machines.

Rook
A: 

Basically what should I use to sanitize user inputted values. Is it either the htmlentities or preg_match function ?

Certainly not htmlentities, probably not preg_match either (for security purposes). You change the representation of any output to the medium its going to (htmlentites fora web page, urlencode for URL, mysql_real_escape_string for a mysql database....).

If someone really wants to register on your application as dummy' UNION SELECT 'dummy' AS user,'dummy' AS password FROM DUAL then let them!

Writing your code to insulate it from attacks is a lot more effective than trying to detect different types of attack in advance.

Some data input may have to match a particular format for it to be of any use - and there may be a delay between the data capture and the use of the data - e.g. if the user is asked to input an email address or a date - in which case preg_match might be appropriate. But this is nothing to do with security.

C.

symcbean
preg_match has everything to do with security! If you allow characters that don't match the specification for a persons name, into a name field, then you've opened up an avenue for XSS, Data Injection (SQL or LDAP!), etc...
Mike
Read it again Mike.
symcbean
+1  A: 

If your using PHP 5.2+, you should look into the Filter functions to sanitize your data.

http://php.net/manual/en/filter.examples.sanitization.php

Ben Rowe