PHP 5.4.45 Released

mysql_real_escape_string

(PHP 4 >= 4.3.0, PHP 5)

mysql_real_escape_stringMaskiert spezielle Zeichen innerhalb eines Strings für die Verwendung in einer SQL-Anweisung

Warnung

Diese Erweiterung ist seit PHP 5.5.0 als veraltet markiert und wird in der Zukunft entfernt werden. Verwenden Sie stattdessen die Erweiterungen MySQLi oder PDO_MySQL. Weitere Informationen finden Sie im Ratgeber MySQL: Auswahl einer API und den zugehörigen FAQ. Alternativen zu dieser Funktion umfassen:

Beschreibung

string mysql_real_escape_string ( string $unescaped_string [, resource $link_identifier = NULL ] )

Maskiert spezielle Zeichen im unescaped_string unter Berücksichtigung des aktuellen Zeichensatzes der Verbindung, so dass das Ergebnis ohne Probleme in mysql_query() verwendet werden kann. Wenn Sie Binärdaten einfügen wollen, müssen Sie die Funktion auf jeden Fall verwenden.

mysql_real_escape_string() ruft die Funktion mysql_real_escape_string der MySQL-Bibliothek auf, die folgende Zeichen mit einem Backslash ('\') versieht: \x00, \n, \r, \, ', " und \x1a.

Die Funktion muss immer (mit wenigen Ausnahmen) verwendet werden, um Daten abzusichern, bevor sie per Query an MySQL übermittelt werden.

Achtung

Sicherheit: Der Standardzeichensatz

Der Zeichensatz muss entweder auf Ebene des Servers oder mittels der API-Funktion mysql_set_charset() gesetzt werden, damit dieser mysql_real_escape_string() beeinflusst. Sehen sie das Grundlagenkapitel zum Thema Zeichensätze für mehr Informationen.

Parameter-Liste

unescaped_string

Der zu maskierende String.

Verbindungs-Kennung

Die MySQL-Verbindung. Wird die Verbindungskennung nicht angegeben, wird die letzte durch mysql_connect() geöffnete Verbindung angenommen. Falls keine solche Verbindung gefunden wird, wird versucht, eine Verbindung aufzubauen, wie es beim Aufruf von mysql_connect() ohne Angabe von Argumenten der Fall wäre. Falls zufällig keine Verbindung gefunden oder aufgebaut werden kann, wird eine Warnung der Stufe E_WARNING erzeugt.

Rückgabewerte

Gibt einen maskierten String oder im Fehlerfall FALSE zurück.

Beispiele

Beispiel #1 Einfaches mysql_real_escape_string()-Beispiel

<?php
// Verbindung herstellen
$link mysql_connect('mysql_host''mysql_user''mysql_password')
    OR die(
mysql_error());

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

Beispiel #2 Ein beispielhafter SQL Injection Angriff

<?php
// Wir haben $_POST['password'] nicht geprüft, dies könnte
// ein beliebiger Wert sein den der Benutzer will
// Zum Beispiel:
$_POST['username'] = 'aidan';
$_POST['password'] = "' OR ''='";

// Datenbankabfrage zur Ueberpruefung der Logindaten
$query "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'";
mysql_query($query);

// Das bedeutet, der an MySQL gesendete Query wuerde sein:
echo $query;
?>

Die Abfrage, die an MySQL übermittelt wird:

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

Dies würde jedermann erlauben, sich ohne valides Passwort einzuloggen.

Anmerkungen

Hinweis:

Sie müssen eine Verbindung zu MySQL geöffnet haben, bevor Sie mysql_real_escape_string() verwenden, ansonsten erhalten Sie einen Fehler vom Typ E_WARNING und der Rückgabewert wird zu FALSE. Ist link_identifier nicht angegeben, wird die letzte MySQL-Verbindung verwendet.

Hinweis:

Ist magic_quotes_gpc aktiviert, wenden Sie zuerst stripslashes() auf die Daten an. Das Bearbeiten bereits in irgend einer Form maskierter Daten durch mysql_real_escape_string führt ansonsten dazu, dass bereits Maskiertes doppelt maskiert wird.

Hinweis:

Wenn die Funktion nicht verwendet wird, um die Daten zu maskieren, ist der Query anfällig für SQL Injection Angriffe.

Hinweis: mysql_real_escape_string() maskiert weder % noch _. Diese Zeichen werden in MySQL als Platzhalter interpretiert, wenn sie mit LIKE, GRANT oder REVOKE kombiniert werden.

Siehe auch

add a note add a note

User Contributed Notes 7 notes

up
66
feedr
4 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
9
Walter Tross
3 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
16
nicolas
9 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
8
sam at numbsafari dot com
2 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
strata_ranger at hotmail dot com
5 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'

?>
up
0
presto dot dk at gmail dot com
5 years ago
If you want to make sure that the ID you're using to do a query is a number, use sprint() of (int) or intval(), but don't use mysql_real_escape_string.

There is no difference between ISO-8859-1's number 10 and UTF-8's number 10.
up
-2
plgs at ozemail dot com dot au
6 years ago
Don't forget that if you're using Mysqli (ie, the "improved" Mysql extension) then you need to use the corresponding mysqli function mysqli_real_escape_string().  The parameter order is also different.
To Top