Mysql real escape string error

mysql_real_escape_string

(PHP 4 >= 4.3.0, PHP 5)

mysql_real_escape_string — Escapes special characters in a string for use in an SQL statement

This extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide. Alternatives to this function include:

Description

Escapes special characters in the unescaped_string , taking into account the current character set of the connection so that it is safe to place it in a mysql_query() . If binary data is to be inserted, this function must be used.

mysql_real_escape_string() calls MySQL’s library function mysql_real_escape_string, which prepends backslashes to the following characters: x00 , n , r , , ‘ , » and x1a .

This function must always (with few exceptions) be used to make data safe before sending a query to MySQL.

Security: the default character set

The character set must be set either at the server level, or with the API function mysql_set_charset() for it to affect mysql_real_escape_string() . See the concepts section on character sets for more information.

Parameters

The string that is to be escaped.

The MySQL connection. If the link identifier is not specified, the last link opened by mysql_connect() is assumed. If no such link is found, it will try to create one as if mysql_connect() had been called with no arguments. If no connection is found or established, an E_WARNING level error is generated.

Return Values

Returns the escaped string, or false on error.

Errors/Exceptions

Executing this function without a MySQL connection present will also emit E_WARNING level PHP errors. Only execute this function with a valid MySQL connection present.

Examples

Example #1 Simple mysql_real_escape_string() example

// Connect
$link = mysql_connect ( ‘mysql_host’ , ‘mysql_user’ , ‘mysql_password’ )
OR die( mysql_error ());

// Query
$query = sprintf ( «SELECT * FROM users WHERE user=’%s’ AND password=’%s’» ,
mysql_real_escape_string ( $user ),
mysql_real_escape_string ( $password ));
?>

Example #2 mysql_real_escape_string() requires a connection example

This example demonstrates what happens if a MySQL connection is not present when calling this function.

// We have not connected to MySQL

$lastname = «O’Reilly» ;
$_lastname = mysql_real_escape_string ( $lastname );

$query = «SELECT * FROM actors WHERE last_name = ‘ $_lastname ‘» ;

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

The above example will output something similar to:

Example #3 An example SQL Injection Attack

// We didn’t check $_POST[‘password’], it could be anything the user wanted! For example:
$_POST [ ‘username’ ] = ‘aidan’ ;
$_POST [ ‘password’ ] = «‘ OR »=’» ;

// Query database to check if there are any matching users
$query = «SELECT * FROM users WHERE user=’ < $_POST [ ‘username’ ]>‘ AND password=’ < $_POST [ ‘password’ ]>‘» ;
mysql_query ( $query );

// This means the query sent to MySQL would be:
echo $query ;
?>

The query sent to MySQL:

This would allow anyone to log in without a valid password.

Notes

A MySQL connection is required before using mysql_real_escape_string() otherwise an error of level E_WARNING is generated, and false is returned. If link_identifier isn’t defined, the last MySQL connection is used.

If magic_quotes_gpc is enabled, first apply stripslashes() to the data. Using this function on data which has already been escaped will escape the data twice.

If this function is not used to escape data, the query is vulnerable to SQL Injection Attacks.

Note: mysql_real_escape_string() does not escape % and _ . These are wildcards in MySQL if combined with LIKE , GRANT , or REVOKE .

See Also

• mysql_set_charset() — Sets the client character set
• mysql_client_encoding() — Returns the name of the character set
• addslashes() — Quote string with slashes
• stripslashes() — Un-quotes a quoted string
• The magic_quotes_gpc directive
• The magic_quotes_runtime directive

User Contributed Notes 10 notes

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.

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

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.

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
>
>

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:

// 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 ] ‘» ;

// 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 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.» ]

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.

Источник

mysqli::real_escape_string

mysqli_real_escape_string

(PHP 5, PHP 7, PHP

mysqli::real_escape_string — mysqli::escape_string — mysqli_real_escape_string — Экранирует специальные символы в строке для использования в SQL-выражении, используя текущий набор символов соединения

Описание

Эта функция используется для создания допустимых в SQL строк, которые можно использовать в SQL выражениях. Заданная строка кодируется для создания экранированной строки SQL с учётом текущего набора символов подключения.

Безопасность: набор символов по умолчанию

Набор символов должен быть задан либо на стороне сервера, либо с помощью API-функции mysqli_set_charset() . В противном случае mysqli_real_escape_string() работать не будет. За дополнительной информацией обращайтесь к документации наборы символов.

Список параметров

Только для процедурного стиля: объект mysqli , полученный с помощью mysqli_connect() или mysqli_init() .

Строка, которую требуется экранировать.

Экранируемые символы NUL (ASCII 0), n, r, , ‘, «, и Control-Z .

Возвращаемые значения

Возвращает экранированную строку.

Примеры

Пример #1 Пример использования mysqli::real_escape_string()

( MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT );
$mysqli = new mysqli ( «localhost» , «my_user» , «my_password» , «world» );

/* этот запрос с экранированным $city будет работать */
$query = sprintf ( «SELECT CountryCode FROM City WHERE name=’%s’» ,
$mysqli -> real_escape_string ( $city ));
$result = $mysqli -> query ( $query );
printf ( «Возвращённые строки: %d.n» , $result -> num_rows );

/* этот запрос завершится ошибкой, потому что мы не экранировали $city */
$query = sprintf ( «SELECT CountryCode FROM City WHERE name=’%s’» , $city );
$result = $mysqli -> query ( $query );

( MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT );
$mysqli = mysqli_connect ( «localhost» , «my_user» , «my_password» , «world» );

/* этот запрос с экранированным $city будет работать */
$query = sprintf ( «SELECT CountryCode FROM City WHERE name=’%s’» ,
mysqli_real_escape_string ( $mysqli , $city ));
$result = mysqli_query ( $mysqli , $query );
printf ( «Возвращённые строки: %d.n» , mysqli_num_rows ( $result ));

/* этот запрос завершится ошибкой, потому что мы не экранировали $city */
$query = sprintf ( «SELECT CountryCode FROM City WHERE name=’%s’» , $city );
$result = mysqli_query ( $mysqli , $query );

Результатом выполнения данных примеров будет что-то подобное:

Смотрите также

User Contributed Notes 9 notes

Presenting several UTF-8 / Multibyte-aware escape functions.

These functions represent alternatives to mysqli::real_escape_string, as long as your DB connection and Multibyte extension are using the same character set (UTF-8), they will produce the same results by escaping the same characters as mysqli::real_escape_string.

This is based on research I did for my SQL Query Builder class:
https://github.com/twister-php/sql

/**
* Returns a string with backslashes before characters that need to be escaped.
* As required by MySQL and suitable for multi-byte character sets
* Characters encoded are NUL (ASCII 0), n, r, , ‘, «, and ctrl-Z.
*
* @param string $string String to add slashes to
* @return $string with « prepended to reserved characters
*
* @author Trevor Herselman
*/
if ( function_exists ( ‘mb_ereg_replace’ ))
<
function mb_escape ( string $string )
<
return mb_ereg_replace ( ‘[x00x0Ax0Dx1Ax22x27x5C]’ , ‘\’ , $string );
>
> else <
function mb_escape ( string $string )
<
return preg_replace ( ‘

?>

Characters escaped are (the same as mysqli::real_escape_string):

Note: preg_replace() is in PCRE_UTF8 (UTF-8) mode (`u`).

When escaping strings for `LIKE` syntax, remember that you also need to escape the special characters _ and %

So this is a more fail-safe version (even when compared to mysqli::real_escape_string, because % characters in user input can cause unexpected results and even security violations via SQL injection in LIKE statements):

/**
* Returns a string with backslashes before characters that need to be escaped.
* As required by MySQL and suitable for multi-byte character sets
* Characters encoded are NUL (ASCII 0), n, r, , ‘, «, and ctrl-Z.
* In addition, the special control characters % and _ are also escaped,
* suitable for all statements, but especially suitable for `LIKE`.
*
* @param string $string String to add slashes to
* @return $string with « prepended to reserved characters
*
* @author Trevor Herselman
*/
if ( function_exists ( ‘mb_ereg_replace’ ))
<
function mb_escape ( string $string )
<
return mb_ereg_replace ( ‘[x00x0Ax0Dx1Ax22x25x27x5Cx5F]’ , ‘\’ , $string );
>
> else <
function mb_escape ( string $string )
<
return preg_replace ( ‘

?>

Additional characters escaped:

The original MySQL `utf8` character-set (for tables and fields) only supports 3-byte sequences.
4-byte characters are not common, but I’ve had queries fail to execute on 4-byte UTF-8 characters, so you should be using `utf8mb4` wherever possible.

However, if you still want to use `utf8`, you can use the following function to replace all 4-byte sequences.

// Modified from: https://stackoverflow.com/a/24672780/2726557
function mysql_utf8_sanitizer ( string $str )
<
return preg_replace ( ‘/[x<10000>-x<10ffff>]/u’ , «xEFxBFxBD» , $str );
>
?>

Pick your poison and use at your own risk!

Note that this function will NOT escape _ (underscore) and % (percent) signs, which have special meanings in LIKE clauses.

As far as I know there is no function to do this, so you have to escape them yourself by adding a backslash in front of them.

Caution when escaping the % and _ wildcard characters. According to an often overlooked note at the bottom of:

the escape sequences % and _ will ONLY be interpreted as % and _, *if* they occur in a LIKE! (Same for MySQL 8.0)

In regular string literals, the escape sequences % and _ are treated as those two character pairs. So if those escape sequences appear in a WHERE «=» instead of a WHERE LIKE, they would NOT match a single % or _ character!

Consequently, one MUST use two «escape» functions: The real-escape-string (or equivalent) for regular string literals, and an amended escape function JUST for string literals that are intended to be used in LIKE.

Note that the “like” operator requires an *additional* level of escaping for its special characters, *on top of* that performed by mysql_escape_string. But there is no built-in function for performing this escaping. Here is a function that does it:

function escape_sql_wild($s)
/* escapes SQL pattern wildcards in s. */
<
$result = array();
foreach(str_split($s) as $ch)
<
if ($ch == «\» || $ch == «%» || $ch == «_»)
<
$result[] = «\»;
> /*if*/
$result[] = $ch;
> /*foreach*/
return
implode(«», $result);
> /*escape_sql_wild*/

Источник

PHP 4 >= 4.3.0, PHP 5

mysql_real_escape_string — Escapes special characters in a string for use in an SQL statement

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

Parameters

Return Values

Returns the escaped string, or false on error.

Exceptions and Errors

Executing this function without a MySQL connection present will
also emit E_WARNING level PHP errors. Only
execute this function with a valid MySQL connection present.

Notes

Related Functions

Example of mysql_real_escape_string

Show all examples
for mysql_real_escape_string