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.
As a beginner I'm trying to build a php (version 5.3.0) website connected to a MySQL database. As a security measure I intend to use mysql_real_escape_string for user input to reduce the risk of SQL-injection. My code looks like this:
<?php
if ($_POST["submit"]=='submit')
{
include "db.php";
$user = mysql_real_escape_string($_POST['user']);
$sql = "INSERT INTO test (user) VALUES('$user')";
mysql_query($sql);
mysql_close($con);
}
?>
<html><body><form action="" method="post"><input type="text" name="user"><input type="submit" name="submit" value="submit"></form></body></html>
But the output does not seem to give any escapes anywhere. I have tried echo to display the escaped string, but it seems to remain unchanged. Am I misunderstanding this function or did I something wrong?
Thanks,
Mike
Last edited by Mike2009 on Fri Sep 25, 2009 10:14 am, edited 2 times in total.
jackpf wrote:Various types of quotes should be escaped. Is that not the case?
Yes, that is one of the things mysql_real_escape_string is supposed to do as far as I understood. If for instance, I post the value ' OR 1 this exact value is posted to the database - no slash in front of it as mentioned on some websites. If I leave out the mysql_real_escape_string from the script, the very same value is still stored in the database. So mysql_real_escape_string does not seem to do anything with the string?
Magic quotes wasn't turned on. But turning it on does the job. My thanks to you.
It crossed my mind last night that this might cause the problem, but I reckoned it couldn't as the php.ini file states Also note, this feature has been deprecated as of PHP 5.3.0 and is scheduled for removal in PHP 6 where as mysql_real_escape_string isn't deprecated (in contrary to mysql_escape_string) and the documentation at php dot net on mysql_real_escape_string even notes If magic_quotes_gpc is enabled implying to me that the function does not depend on magic quotes. Apparantly it does
You shouldn't rely on magic quotes...I was actually thinking that you may have them turned on, which would affect your data (it would be double escaped).
You should turn it back off and use mysql_real_escape_string() instead
Mike, you are seeing your (correct) script behave securely, as intended.
If you comment-out the escaping and enable error displaying, you will notice that your sample attack vector will indeed "break" the query.
Due to the fact that you successfully escape it, it goes in the database as a string value, which is what you wanted.
Okay, I understand it a bit more now. I was expecting to see a backslash in the stored string, but I shouldn't as Mordred pointed out - the '\' only forces the parsers not to interpret the following character as a part of an instruction, but as a symbol instead. Back with magic quotes turned off it still works now. Using the following code indeed gives a different output between the escaped and un-escaped string: