PHP 8.4.2 Released!

mysql_real_escape_string

(PHP 4 >= 4.3.0, PHP 5)

mysql_real_escape_stringProtège une commande SQL de la présence de caractères spéciaux

Avertissement

Cette extension était obsolète en PHP 5.5.0, et a été supprimée en PHP 7.0.0. À la place, vous pouvez utiliser l'extension MySQLi ou l'extension PDO_MySQL. Voir aussi MySQL : choisir une API du guide. Alternatives à cette fonction :

Description

mysql_real_escape_string(string $unescaped_string, resource $link_identifier = NULL): string

mysql_real_escape_string() protège une commande SQL de la chaîne unescaped_string, en "échappant" les caractères spéciaux tout en prenant en compte le jeu de caractères courant de la connexion link_identifier. Le résultat peut être utilisé sans problème avec la fonction mysql_query(). Si des données binaires doivent être insérées, cette fonction doit être utilisée.

mysql_real_escape_string() appelle la fonction mysql_escape_string() de la bibliothèque MySQL qui ajoute un antislash aux caractères suivants : NULL, \x00, \n, \r, \, ', " et \x1a.

Cette fonction doit toujours (avec quelques exceptions) être utilisée avant d'envoyer la requête à MySQL afin de protéger vos données d'injection de caractères pouvant dévoyer cette requête.

Attention

Securité : le jeu de caractères par défaut

Le jeu de caractèrs doit être défini soit au niveau serveur, soit avec la fonction API mysql_set_charset() pour qu'il ait un effet sur la fonction mysql_real_escape_string(). Voir la section sur les concepts on des jeux de caractères pour plus d'informations.

Liste de paramètres

unescaped_string

La chaîne à échapper.

link_identifier

La connexion MySQL. S'il n'est pas spécifié, la dernière connexion ouverte avec la fonction mysql_connect() sera utilisée. Si une telle connexion n'est pas trouvée, la fonction tentera d'ouvrir une connexion, comme si la fonction mysql_connect() avait été appelée sans argument. Si aucune connexion n'est trouvée ou établie, une alerte de niveau E_WARNING sera générée.

Valeurs de retour

Retourne la chaîne échappée, ou false si une erreur survient.

Erreurs / Exceptions

Exécuter cette fonction sans qu'une connexion MySQL ne soit présente va également émettre une erreur PHP de niveau E_WARNING. N'exécuter cette fonction qu'avec une connexion MySQL valide.

Exemples

Exemple #1 Exemple simple avec mysql_real_escape_string()

<?php
// Connexion
$link = mysql_connect('mysql_host', 'mysql_user', 'mysql_password')
OR die(
mysql_error());

// Requête
$query = sprintf("SELECT * FROM users WHERE user='%s' AND password='%s'",
mysql_real_escape_string($user),
mysql_real_escape_string($password));
?>

Exemple #2 Exemple avec mysql_real_escape_string() et la nécessité de la présence d'une connexion

Cet exemple démonte ce qui survient si une connexion MySQL n'est pas présente lors de l'appel à la fonction.

<?php
// Nous n'avons pas de connexion MySQL

$lastname = "O'Reilly";
$_lastname = mysql_real_escape_string($lastname);

$query = "SELECT * FROM actors WHERE last_name = '$_lastname'";

var_dump($_lastname);
var_dump($query);
?>

Résultat de l'exemple ci-dessus est similaire à :

Warning: mysql_real_escape_string(): No such file or directory in /this/test/script.php on line 5
Warning: mysql_real_escape_string(): A link to the server could not be established in /this/test/script.php on line 5

bool(false)
string(41) "SELECT * FROM actors WHERE last_name = ''"

Exemple #3 Un exemple d'attaque par injection SQL

<?php
// Nous ne vérifions pas $_POST['password'], il peut contenir ce que l'utilisateur veut ! Par exemple :
$_POST['username'] = 'aidan';
$_POST['password'] = "' OR ''='";

// Demande à la base de vérifier si un utilisateur correspond
$query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'";
mysql_query($query);

// Cela signifie que la requête envoyée à MySQL sera :
echo $query;
?>

La requête envoyée à MySQL :

SELECT * FROM users WHERE user='aidan' AND password='' OR ''=''

Cela permet à n'importe qui de s'identifier sans mot de passe valide.

Notes

Note:

Une connexion MySQL est nécessaire avant d'utiliser la fonction mysql_real_escape_string(), sinon, une erreur de niveau E_WARNING sera générée, et false sera retourné. Si link_identifier n'est pas défini, la dernière connexion MySQL est utilisée.

Note:

Si cette fonction n'est pas utilisée pour protéger vos données, la requête sera vulnérable aux attaques par injection SQL.

Note: mysql_real_escape_string() n'échappe ni %, ni _. Ce sont des jokers en MySQL si combinés avec LIKE, GRANT, ou REVOKE.

Voir aussi

add a note

User Contributed Notes 6 notes

up
183
feedr
14 years ago
Just a little function which mimics the original mysql_real_escape_string but which doesn't need an active mysql connection. Could be implemented as a static function in a database class. Hope it helps someone.

<?php
function mysql_escape_mimic($inp) {
if(
is_array($inp))
return
array_map(__METHOD__, $inp);

if(!empty(
$inp) && is_string($inp)) {
return
str_replace(array('\\', "\0", "\n", "\r", "'", '"', "\x1a"), array('\\\\', '\\0', '\\n', '\\r', "\\'", '\\"', '\\Z'), $inp);
}

return
$inp;
}
?>
up
31
nicolas
18 years ago
Note that mysql_real_escape_string doesn't prepend backslashes to \x00, \n, \r, and and \x1a as mentionned in the documentation, but actually replaces the character with a MySQL acceptable representation for queries (e.g. \n is replaced with the '\n' litteral). (\, ', and " are escaped as documented) This doesn't change how you should use this function, but I think it's good to know.
up
22
Walter Tross
12 years ago
For further information:
http://dev.mysql.com/doc/refman/5.5/en/mysql-real-escape-string.html
(replace your MySQL version in the URL)
up
8
sam at numbsafari dot com
12 years ago
No discussion of escaping is complete without telling everyone that you should basically never use external input to generate interpreted code. This goes for SQL statements, or anything you would call any sort of "eval" function on.

So, instead of using this terribly broken function, use parametric prepared statements instead.

Honestly, using user provided data to compose SQL statements should be considered professional negligence and you should be held accountable by your employer or client for not using parametric prepared statements.

What does that mean?

It means instead of building a SQL statement like this:

"INSERT INTO X (A) VALUES(".$_POST["a"].")"

You should use mysqli's prepare() function (http://php.net/manual/en/mysqli.prepare.php) to execute a statement that looks like this:

"INSERT INTO X (A) VALUES(?)"

NB: This doesn't mean you should never generate dynamic SQL statements. What it means is that you should never use user-provided data to generate those statements. Any user-provided data should be passed through as parameters to the statement after it has been prepared.

So, for example, if you are building up a little framework and want to do an insert to a table based on the request URI, it's in your best interest to not take the $_SERVER['REQUEST_URI'] value (or any part of it) and directly concatenate that with your query. Instead, you should parse out the portion of the $_SERVER['REQUEST_URI'] value that you want, and map that through some kind of function or associative array to a non-user provided value. If the mapping produces no value, you know that something is wrong with the user provided data.

Failing to follow this has been the cause of a number of SQL-injection problems in the Ruby On Rails framework, even though it uses parametric prepared statements. This is how GitHub was hacked at one point. So, no language is immune to this problem. That's why this is a general best practice and not something specific to PHP and why you should REALLY adopt it.

Also, you should still do some kind of validation of the data provided by users, even when using parametric prepared statements. This is because that user-provided data will often become part of some generated HTML, and you want to ensure that the user provided data isn't going to cause security problems in the browser.
up
-2
rohankumar dot 1524 at gmail dot com
3 years ago
There is requirement for old projects which are using `mysql_escape_string`, and upgrading the PHP version to 7 and above. Basically this happens in maintenance projects where we don't know how many files the functions are used in application. We can use [mysqli.real-escape-string][1] for the function:

If you have a typical connection file like `conn.php`

$conn = new mysqli($host, $user, $password, $db);
// may be few more lines to handle the $conn
if (!function_exists('mysql_escape_string')) {
function mysql_escape_string($sting){ // if mysql_escape_string not available
return $conn->real_escape_string($string); // escape using the $conn instance
}
}

[1]: https://www.php.net/manual/en/mysqli.real-escape-string.php
up
1
strata_ranger at hotmail dot com
15 years ago
There's an interesting quirk in the example #2 about SQL injection: AND takes priority over OR, so the injected query actually executes as WHERE (user='aidan' AND password='') OR ''='', so instead of returning a database record corresponding to an arbitrary username (in this case 'aidan'), it would actually return ALL database records. In no particular order. So an attacker might be able to log in as any account, but not necessarily with any control over which account it is.

Of course a potential attacker could simply modify their parameters to target specific users of interest:

<?php

// E.g. attacker's values
$_POST['username'] = '';
$_POST['password'] = "' OR user = 'administrator' AND '' = '";

// Malformed query
$query = "SELECT * FROM users WHERE user='$_POST[username]' AND password='$_POST[password]'";

echo
$query;

// The query sent to MySQL would read:
// SELECT * FROM users WHERE user='' AND password='' OR user='administrator' AND ''='';
// which would allow anyone to gain access to the account named 'administrator'

?>
To Top