1

I'm confused about these magic quotes.
They are enabled on my server, and my question is should i disable them by using functions like :

if(get_magic_quotes_gpc()){
 $username=stripslashes($username);
 $password=stripslashes($password);
}

to sanitize my input or should i leave all the job to magic quotes.
I'm practicing some sql injection (for learning purposes) and when magic quotes are on i cant do anything, but when i use the code above i can do sql injection.
So should i stick with magic quotes or use functions like this:

if(get_magic_quotes_gpc()){
 $username=stripslashes($username);
 $password=stripslashes($password);
 $cleanUsername=mysql_real_escape_string($username);
 $cleanPassword=mysql_real_escape_string($password);
}

I dont have that much experience on sanitizing inputs so any help please :(

aygeta
  • 429
  • 3
  • 7
  • 17
  • The only function you need to avoid sql injection is mysql_real_escape_string – Aurelio De Rosa Nov 01 '11 at 03:28
  • Only that ? ... so all i have to do is create a function with mysql_real_escape_string inside and use that ? Not that sure if im completely protected from sql inejction by only doing this – aygeta Nov 01 '11 at 03:32
  • Unless you want use a PDO as suggested by TrexXx, mysql_real_escape_string is the only function you need (if you not trust me you can search in this site for related answers) to protect you against sql injection. – Aurelio De Rosa Nov 01 '11 at 03:33
  • @AurelioDeRosa, relying on string escaping is inherently risky (did you escape in *every* place you need to?) and prone to bugs (like unwanted backslashes showing up in HTML presented to users). Prepared statements are much safer. – Wyzard Nov 01 '11 at 03:33
  • 1
    `mysql_real_escape_string` is not [100% sure](http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html) – Furicane Nov 01 '11 at 03:34
  • @Wyzard You said risky because a programmer can forget some escape, but if you use that function always, you don't need more. Besides, "unwanted backslashes showing up in HTML presented to users" it's not a *bug*, maybe an unwanted behavior, but sure not a bug. – Aurelio De Rosa Nov 01 '11 at 03:36
  • @AurelioDeRosa, unwanted behavior *is* a bug, by definition. – Wyzard Nov 01 '11 at 03:39
  • So if i create a class with functions inside for protecting different inputs and use only mysql_real_escape_string ... im protected 100% ? I mean only from sql injection. I know there are other attacks like NULL BYTE or XSS. – aygeta Nov 01 '11 at 03:39
  • @Wyzard Totally wrong. A bug is a bug which is caused by a fail in the source. By unwanted behavior I meant something the users don't like to see. No crashes, No execution errors and nothing similar. "A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result" – Aurelio De Rosa Nov 01 '11 at 03:42
  • Anyway you can look here for all that you need: http://stackoverflow.com/questions/60174/best-way-to-stop-sql-injection-in-php – Aurelio De Rosa Nov 01 '11 at 03:44
  • @AurelioDeRosa, you have a strange definition of "bug". When your application misbehaves and users complain, try telling them "it's not a bug" and I think you'll find that they disagree. – Wyzard Nov 01 '11 at 03:49
  • @Wyzard So you consider you have a bug everytime your users complain? Are all your users Computer scientists? So if you have a user that agree is not a bug you'll consider not a bug? That's a very strange way of think. – Aurelio De Rosa Nov 01 '11 at 03:52
  • @AurelioDeRosa, this isn't the place for a debate about the definition of "bug", so I won't reply again. But extraneous slashes in HTML output would fall under the criterion of "unexpected result" in the definition you quoted above. – Wyzard Nov 01 '11 at 03:55

1 Answers1

1

Magic quotes are deprecated and will be removed from the next version of PHP (PHP 5.4), so you shouldn't rely on them. (See http://www.php.net/manual/en/security.magicquotes.php) The best way to prevent SQL injection is to use PDO and prepared statements. See http://fr2.php.net/manual/en/pdo.prepared-statements.php for more and search for a tutorial on google if you need more.

mravey
  • 4,380
  • 2
  • 21
  • 31
  • And if you're using MySQL, connect to it using the newer "mysqli" driver, not the older "mysql" one. The latter doesn't actually support prepared statements, so PDO has to simulate them using escaping. @Furicane's comment includes a link that explains the problem with that. – Wyzard Nov 01 '11 at 03:45