Add slashes vs magic quotes

PHP
1

Sorry about this but im new to php

I hear many people talking about using getmagicquotes when working with entering text to a field for uploading to the database. I understand how it can break the sql code but for my 1st cms i simpliy put addslashes on the varialbe and it works.
example:
$song_title = addslashes($_POST[‘song’]);

will this ever fail me and if so where? is it to do with different types of servers which are being run?

Thanks in advance

2

Magic quotes is just a term for where the servers automatically add slashes to superglobals such as $_GET and $_POST.

If it’s a song by “Conan O’Brian”, you’ll find that the web server might add slashes to that making it “Conan O\'Brian” after which you add slashes with what you’re doing, and it’s “Conan \\\'O Brian”

The proper way to handle this type of things is to not escape at the input, but to ensure that it’s not escaped at all until it’s sent out to different places. The database requires a different type of escape (mysql_real_escape_string) to that of HTML content ([url=“http://php.net/manual/en/function.htmlspecialchars.php”]htmlspecialchars), which is different from email content (no escaping of plain text), which is different again from a page url ([url=“http://php.net/manual/en/function.urlencode.php”]urlencode).

The problem is that with PHP 5.3, magic quotes are deprecated, and they will be removed completely with version 6.0. So your code needs to either check whether they are being used and do something about it, or preferably, to completely disable magic quotes at the server so that you don’t need to do anything special relating to them.

PHP provides full details on why not to use magic quotes, and on how to go about [url=“http://www.php.net/manual/en/security.magicquotes.disabling.php”]disabling magic quotes

Sanitize the input, escape the output.

3

Thanks for all of that but im still not fully sure.
i used the addslahes for when im gettin data ready to input to a database, this is only an extract of the code. addslashes works for me here

if ($_POST){
$name = addslashes($_POST[‘name’]);
$category = $_POST[‘cid’];
$price = $_POST[‘price’];
$add = $_POST[‘add’];

$error = empty($name) ? ‘- Name Field is empty <br />’ : null;
$error .= empty($category) ? ‘- Category Field is empty <br />’ : null;
$error .= empty($price) ? ‘- Price Field is empty <br />’ : null;

if(empty($error)){
$sql = “INSERT INTO products SET
name = ‘$name’,
cat_id = ‘$category’,
price = ‘$price’”;
if(mysql_query($sql)){
redirect_to(“addproducts.html”);
}
}
}

4

There are several security reasons why addslashes was replaced with mysql_escape_string, and then further with mysql_real_escape_string.

addslashes fails when it comes to escaping multi-byte characters. How?

Using ¿’ in the submitted data causes addslashes to turn it in to ¿\’
That’s as expected.
What is not expected is that ¿\ is 0x5CBF which PHP see as a single character and boom goes your security because the single quote got through.

This article takes you through how addslashes can be exploited in ways that mysql_real_escape_string cannot be.
addslashes() Versus mysql_real_escape_string()

5

addslashes worked because the data you entered was pretty straight forward. In practice there is no need to consider it over mysql_real_escape_string (meaning forget addslashes, use mres)

I also noticed that you’re not doing anything with $_POST[‘cid’] and price, add.
You cannot assume that because a value came from a <select> or radio, or checkbox that it’s value is safe. $_POST can contain any value the user wants, so they all need to be validated.

Typecast to int or float for those types of values


$price = (float)$_POST['price'];

When there is a predefined set of options, make sure the submitted value is one:


$allowed_pets = array('dog', 'cat', 'mammal');
if( !in_array($_POST['pet'], $allowed_pets) ) {
   echo "You can't keep a " . htmlentities($_POST['pet'], ENT_QUOTES, 'UTF-8'), " here!";
}