Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.
$ticket = $_POST["ticket"];
$ticket = strip_tags($ticket);
$sql_ticket = mysql_escape_string($ticket);//I'm still on an old php
$sql = "INSERT INTO table SET ticket='$sql_ticket';
use mysql_real_escape_string() - is better. and don't use strip_tags() because this will likely strip the "very important" from this string: "this is a post <very important> can you please give me support" -- i think. htmlentities() will give you all the protection you need as that will convert < into < so that the browser won't interpret that as HTML.
Also make sure you call htmlentities with the two optional arguments:
this is recommended in chris shiflett's book although he doesn't specify why. The 2nd arg should always be ENT_QUOTES and the third the same as the header Content-Type that your server serves. Also notice how i'm not just reassigning the variable i'm actually putting it in a new array ($html) this is important as it help you distinguish what you've processed and what you haven't.
But with regards to strip_tags, how do you get rid of the nasty forward slashes put in by mysql_escape_string? (note i cant use real_escape as my version of php is quite old).
how do you get rid of the nasty forward slashes put in by mysql_escape_string
err are you serious? That is the point in mysql_escape_string. Those slashes prevent quotes ( ' " ) from being treated as SQL itself. Without them users can send input to the server that breaks out of the SQL quotes you put in.
SELECT * FROM users WHERE username = 'Bob' // ' AND password = 'acorn'
The hacker has been able to get the user record without using a password by commenting out the second part of the query. This is just one example of many attacks. However if the forward slash is put in by mysql_real_escape_string() the resulting query is:
SELECT * FROM users WHERE username = 'Bob\' // ' AND password = 'acorn'
and MySQL will say no user exists because the user "bob\' */" doesn't exist -- the correct behaviour. This is because a quote preceeded by a forward slash is an "escape" causing the quote to be treated as part of the string rather than the end (or beginning) of it
any query that uses a string will have to have its quotes escaped. otherwise if quotes appear inside the string (thus inside the quotes in the query) they will end the string incorrectly
$value = "php's forum";
$sql_value = addslashes($value);
$sql = "INSERT INTO table SET field='$sql_value'";
$sql = "SELECT field FROM table";
$field = stripslashes($field);
Now, as part of security, we are being advised to use mysql_real_ascape. So does this actually add forward slashes to the data being inserted OR is it just a temporary addition to the sql to ensure that the data get's inserted okay?
So does this actually add forward slashes to the data being inserted OR is it just a temporary addition to the sql to ensure that the data get's inserted okay?
the second. is it just a temporary addition to the sql to ensure that quotes are treated as part of the string rather than terminating it.
no problem. you should get a book on this stuff because there are probably loads of different types of attacks you aren't aware of. There certainly was when I started to read up on this stuff.
ole wrote:this is recommended in chris shiflett's book although he doesn't specify why.
Sorry about that. The reason is that it's very important for the escaping function (htmlentities()) and the browser to interpret data the same way. Forgetting details for a moment, imagine if what the browser considered a less than sign (<) is different than what htmlentities() considers a less than sign.
If you want a more specific example, I blogged a bit about Google's XSS vulnerability, which was a direct result of this type of character encoding inconsistency: