I mean there are a lot it seems, like htmlentites, strip_tags, mysql_real_escape_string... Which one should I use to protect from sql injection and to prevent users from submitting html tags in posts to change colors and add links? If you are thinking two, the how do you declare the two of them? I mostly use $username = mysql_real_escape_string($_POST['username']) Code (markup): Is there anyway, to double sanitize them or ... ?? Thanks
To sanitize HTML input/output, I generally use htmlentities. You can also use strip_tags, but if the user puts in invalid html such as missing an ending tag, it could be removing a lot more content than expected. <?php $username = htmlentities(mysql_escape_string($username), ENT_QUOTES, 'UTF-8'); ?> PHP:
Thanks Gemba, but it seems on top of the many to choose from, you have also given me a new ones to wander about. Because, i don't know what this means: [COLOR=#009900][FONT=monospace])[/FONT][/COLOR][COLOR=#339933][FONT=monospace],[/FONT][/COLOR][COLOR=#111111][FONT=monospace] [/FONT][/COLOR][COLOR=#009900][FONT=monospace][B]ENT_QUOTES[/B][/FONT][/COLOR][COLOR=#339933][FONT=monospace],[/FONT][/COLOR][COLOR=#111111][FONT=monospace] [/FONT][/COLOR][COLOR=#0000FF][FONT=monospace]'UTF-8'[/FONT][/COLOR][COLOR=#009900][FONT=monospace]); [/FONT][/COLOR] Code (markup): what does that mean?
ENT_QUOTES makes sure that both single and double quotes are escaped, UTF-8 is just the character encoding by default
To protect yourself from SQL inject, mysql_real_escape_string (or quote using pdo) is more than enough. Now if you want to protect yourself from JS/CSS injection, the best thing to use is strip_tags if you don't allow for HTML input or htmlentities if you do (like shown above).
This is a slightly older thread thread but I just want to clear the misinformation. Surely mysql_real_escape_string is NOT enough to be protected from SQL injection. Suppose you have a query like the following $id=$_GET("id");; $id=mysql_real_escape_string($id); $sql="Update users set lastname='pot' where id=$id"; PHP: Ah you think you are safe from SQL injection because you used mysql_real_escape_string. But no, if someone types in "1 OR 1=1" in the id field, its quietly going to pass your "sanitizing" function and all the users last names in your database will be updated to pot. So you have to check whether $id is really a number using a function like is_numeric() or you are vulnerable to SQL injection even if you used mysql_real_escape_string And yes for protecting against XSS htmlentities() is good enough. If you would like to allow HTML selectively you may take a look at HTML purifier
The only 'real' reason to be sanitizing inputs in this day and age using functions like that, is using outdated/outmoded/deprecated functions in the first place. http://php.net/manual/en/function.mysql-connect.php See the BIG RED BOX saying don't use that anymore?!? The proper/modern way to access a database is with the msqli_ or PDO objects, which if you use "prepared queries" will auto-sanitize all your values for you, without any extra headaches of screwing around with outdated half-assed nonsense like mysql_real_escape_string. For example, assuming $db is a PDO object that's already connected: $statement=$db->prepare(" SELECT id,name,fullName,registeredDate,lastAccess,publicEmail FROM users WHERE name = :name AND password = :password "); $statement->execute(array( ':name' => $_POST['name'], ':password' => $_POST['password'] )); Code (markup): Prepared queries are immune to code injections. You can do the same thing with mysqli_ commands, but I prefer PDO since it's SQL engine neutral and lets you pass an array rather than using a horde of 'bind' commands. Though bind is handy when you want to force typecasting.
Yes it is preferable to use prepared queries. But many people still do use mysql (and a lot of existing code do) and even when using pdo sometimes you may not use prepared queries. When you sanitize your user input properly , you are not too bothered of which database driver you use as your input is safe. Anyway its good to check datatype of user input . You do not know where you are going to use it and what kind of problems you will face when the data type is not the type you expect Also parameters can't be used for substituting identifiers and operators so if you need that you have to go back to making your sql using string concatenations and if those identifiers (column names, table names) or operators are from user input you are in for a surprise if you dont validate the user input properly.
How is that true? Doesn't mysql_real_escape_string place backward slashes to each double or single quotes?