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;
}
?>
mysql_real_escape_string
(PHP 4 >= 4.3.0, PHP 5)
mysql_real_escape_string — Dodaje znaki unikowe w łańcuchu znaków do użycia w instrukcji SQL
Ostrzeżenie
To rozszerzenie zostało uznane za przestarzałe w PHP 5.5.0 i usunięte w PHP 7.0.0. Zamiast niego należy stosować rozszerzenia MySQLi lub PDO_MySQL. Zobacz też przewodnik MySQL: wybieranie API i stosowne FAQ aby uzyskać więcej informacji. Alternatywy dla tej funkcji to między innymi:
Opis
mysql_real_escape_string
( string
$łańcuch_bez_znaków_unikowych
[, resource $identyfikator_połączeniar = NULL
] ) : string
Dodaje znaki unikowe do łańcucha_bez_znaków_unikowych,
mając na uwadze aktualnie używany w połączeniu zestaw znaków by tak przygotowanego łańcucha
można bezpiecznie użyc w funkcji mysql_query(). Jeśli dopisywane
dane mają postać binarną wymagane jest użycie tej funkcji.
mysql_real_escape_string() wywołuje funkcję biblioteki MySQL mysql_real_escape_string, która dodaje lewe ukośniki (backslash) do następujących znaków: \x00, \n, \r, \, ', " and \x1a.
Użycie tej funkcji jest wymagane zawsze (poza kilkoma wyjątkami) przed wysłaniem zapytania do bazy danych, aby zabezpieczyć dane.
Uwaga
Bezpieczeństwo: domyślne kodowanie znaków
Domyślne kodowanie znaków musi zostać ustawione na poziomie serwera lub funkcją mysql_set_charset() aby miało wpływ na mysql_real_escape_string(). Zobacz sekcję o on kodowaniu znaków, aby zdobyć więcej informacji.
Parametry
-
łańcuch_bez_znaków_unikowych -
Łańcuch, do którego zostaną dodane znaki unikowe.
-
identyfikator_połączenia -
Połączenie MySQL. Jeśli identyfikator połączenia nie zostanie podany, użyte zostanie ostatnie połączenie otwarte przez mysql_connect(). Jeśli połączenie takie nie zostanie znalezione, funkcja spróbuje nawiązać połączenie tak, jakby wywołana została funkcja mysql_connect() bez argumentów. Jeśli żadne połączenie nie zostanie znalezione lub nawiązane, wygenerowany zostanie błąd poziomu
E_WARNING.
Zwracane wartości
Zwraca łańcuch ze znakami unikowymi lub FALSE w przypadku błędu.
Błędy/Wyjątki
Wywołanie tej funkcji bez ustanowionego połączenia MySQL spowoduje
wyemitowanie błędu o poziomie E_WARNING. Używaj
tej funkcji tylko przy ustanowionym poprawnym połączeniu MySQL.
Przykłady
Przykład #1 Przykład użycia mysql_real_escape_string()
<?php
// Połączenie
$link = mysql_connect('host', 'uzytkownik', 'haslo')
OR die(mysql_error());
// Zapytanie
$query = sprintf("SELECT * FROM uzytkownicy WHERE uzytkownik='%s' AND haslo='%s'",
mysql_real_escape_string($uzytkownik),
mysql_real_escape_string($haslo));
?>
Przykład #2 mysql_real_escape_string() wymaga połączenia
Ten przykład przedstawia co dzieje się gdy nie ma ustanowionego połączenia MySQL przy wywoływaniu tej funkcji.
<?php
// Nie jesteśmy połączeni z MySQL
$nazwisko = "O'Reilly";
$_nazwisko = mysql_real_escape_string($nazwisko);
$zapytanie = "SELECT * FROM aktorzy WHERE nazwisko = '$_nazwisko'";
var_dump($_nazwisko);
var_dump($zapytanie);
?>
Powyższy przykład wyświetli coś podobnego do:
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 aktorzy WHERE nazwisko = ''"
Przykład #3 Przykład ataku SQL Injection
<?php
// Nie sprawdziliśmy zmiennej $_POST['password'], która może zawierać wszystko czego chciał użytkownik! Na przykład:
$_POST['username'] = 'aidan';
$_POST['password'] = "' OR ''='";
// Zapytanie pobierające pasujących użytkowników
$query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'";
mysql_query($query);
// Oznacza to, że zapytanie ma postać:
echo $query;
?>
Zapytanie wysłane do bazy danych:
SELECT * FROM users WHERE user='aidan' AND password='' OR ''=''
Zapytanie to pozwala zalogować się każdemu bez znajomości poprawnego hasła.
Notatki
Informacja:
Przed użyciem mysql_real_escape_string() należy otworzyć połączenie z MySQL, w przeciwnym razie zostanie wygenerowany błąd poziomu E_WARNING i zwrócona zostanie wartość
FALSE. Jeśliidentyfikator_połączenianie został zdefiniowany, zostanie użyte ostatnie połączenie do serwera MySQL.
Informacja:
Jeśli opcja magic_quotes_gpc została włączona, najpierw na danych należy użyć stripslashes(). Użycie tej funkcji samej spowoduje, że do danych zostaną dodane podwójne znaki unikowe.
Informacja:
Jeśli funkcja ta nie zostanie użyta na danych, zapytanie będzie podatne na ataki SQL Injection Attacks.
Informacja: mysql_real_escape_string() nie dodaje znaków unikowych do % i _. Te maski są stosowane w zapytaniach MySQL w połączeniu z LIKE, GRANT lub REVOKE.
Zobacz też:
- mysql_set_charset() - Sets the client character set
- mysql_client_encoding() - Zwraca nazwę zestawu znaków
- addslashes() - Quote string with slashes
- stripslashes() - Un-quotes a quoted string
- Dyrektywa magic_quotes_gpc
- Dyrektywa magic_quotes_runtime
add a note
User Contributed Notes 10 notes
feedr ¶
13 years ago
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)
nicolas ¶
17 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.
sam at numbsafari dot com ¶
11 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.
rohankumar dot 1524 at gmail dot com ¶
2 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
strata_ranger at hotmail dot com ¶
14 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'
?>
plgs at ozemail dot com dot au ¶
14 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.
jonnie ¶
7 years ago
To Quote Sam at Numb Safari
[ "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." ]
Sam is right........
However I do not think it is sensible to stop all sanitising and simply pass the task on to parametric prepared statements.
A particular developer working in a particular situation will always know more about valid input (specific to that context).
If you ask a user to pass in a value you have already given them and you know that all such values start AB****** and the string should be of length 7 or 11 but never any other length then you have the basis of a good pre-sanitiser - different allowable lengths of a string might indicate legacy data.
I would never want to simply pass the rubbish that a malicious user may have passed in through a form to the parametric prepared statements, I would always want to do my own sanity checks first and in some cases these may err on the side of caution and simply choose to abort the Database op completely.
That way my DB does not get clogged up with unsafe statements made safe - it simply does not get clogged up which is better.
Security in layers - sanitisation and validation should still be considered in every situation BEFORE using prepared statements.
In addition as far as I can read into the official doc
==============================================
"Escaping and SQL injection
Bound variables are sent to the server separately from the query and thus cannot interfere with it. The server uses these values directly at the point of execution, after the statement template is parsed. Bound parameters do not need to be escaped as they are never substituted into the query string directly"
That suggests to me that danger is avoided in the internals by alternative handling not by nullification.
This means that a large project with incomplete conversion to prepared statements, legacy code in different parts of an organisation or servers talking to one another could all pass on the bad news from an immune location or situation to one that is not immune.
As long as the sanitisation is competently performed without incurring additional risks then personally I would stick with certain layers of sanitisation and then call the prepared statements.
Aljo ¶
6 years ago
@feedr
I elaborated his note as following:
$string = "asda\0sd\x1aas\\\\\\\\dasd\'asdasd\na\'\'sdasdad";
$array1 = array('\\\\\\\\', '\0', '\n', '\r', "'", '"', '\x1a');
$array2 = array('\\\\\\\\\\\\\\\\', '\\\0', '\\\n', '\\\r', "\\\'", '\\\"', '\\\Z');
echo($string);
echo(PHP_EOL);
for( $i=0; $i<count($array1); $i++ ) {
if ($i==0)
$p = '/(?<!\\\\)'.$array1[$i].'(?!\\\\)/';
else
$p = '/(?<!\\\\)'.$array1[$i].'/';
echo($i);
echo($p);
echo( $array2[$i]);
$string = preg_replace($p, $array2[$i], $string);
echo("\t");
echo($string);
echo(PHP_EOL);
}
echo(PHP_EOL);
echo($string);
presto dot dk at gmail dot com ¶
14 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.
