mysql_real_escape_string

(PHP 4 >= 4.3.0, PHP 5)

mysql_real_escape_string — Escapa os caracteres especiais em uma string para uso em uma instrução SQL

Aviso

Esta extensão tornou-se defasada a partir do PHP 5.5.0 e foi removida no PHP 7.0.0. Em vez disso, as extensões MySQLi ou PDO_MySQL devem ser usadas. Veja também o guia MySQL: escolhendo uma API. Alternativas a esta função incluem:

Descrição

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

Escapa caracteres especiais do parâmtro unescaped_string, levando em conta o conjunto de caracteres atual da conexão, de forma que seja seguro inseri-la na função mysql_query(). Se forem inseridos dados binários, esta função precisa ser usada.

mysql_real_escape_string() cchama a função mysql_real_escape_string da biblioteca do MySQL, que prefixa com barras invertidas os seguintes caracteres: \x00, \n, \r, \, ', " e \x1a.

Esta função precisa sempre ser usada (com poucas exceções) para tornar os dados seguros antes de enviá-los em uma consulta ao MySQL.

Cuidado

Segurança: o conjunto de caracteres padrão

O conjunto de caracteres precisa ser definido no nível do servidor ou com a função mysql_set_charset() da API para que afete a função mysql_real_escape_string(). Consulte a seção de conceitos sobre conjuntos de caracteres para mais informação.

Parâmetros

unescaped_string: A string a ser escapada.
link_identifier: A conexão MySQL. Se o identificador da conexão não for especificado, a última conexão aberta por mysql_connect() será usada. Se não houver uma conexão anterior, haverá uma tentativa de criar uma como se mysql_connect() tivesse sido chamada sem argumentos. Se nenhuma conexão for encontrada ou estabelecida, um erro de nível E_WARNING será gerado.

Valor Retornado

Retorna a string escapada ou false em caso de erro.

Erros/Exceções

Executar esta função sem uma conexão MySQL presente emitirá um erro de nível E_WARNING. Esta função deve ser executada somente comuma conexão MySQL válida presente.

Exemplos

Exemplo #1 Exemplo de mysql_real_escape_string()

<?php
// 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));
?>

Exemplo #2 mysql_real_escape_string() requer um exemplo de conexão

Este exemplo demonstra o que acontece se uma conexão MySQL não estiver presente ao chamar esta função.

<?php
// Ainda não foi feita conexão ao MySQL

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

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

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

O exemplo acima produzirá algo semelhante a:

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 = ''"

Exemplo #3 Um exemplo de Ataque de Injeção SQL

<?php
// Não verificamos $_POST['password'], ela pode conter qualquer coisa que o usuário quiser! Por exemplo:
$_POST['username'] = 'aidan';
$_POST['password'] = "' OR ''='";

// Consulta o banco de dados para verificar se existe algum usuário correspondente
$query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'";
mysql_query($query);

// Isto significa que a consulta enviada ao MySQL seria:
echo $query;
?>

A consulta enviada ao MySQL:

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

Isto permitiria que qualquer pessoa fizesse login sem uma senha válida.

Notas

Nota:
Uma conexão MySQL é requerida antes que mysql_real_escape_string() seja usada, caso contrário um erro de nível E_WARNING será gerado e false é retornado. Se link_identifier não estiver definido, a últimoa conexão MySQL será usada.

Nota:
Se esta função não for usada para escapar dados, a consulta ficará vulnerável a Ataques de Injeção SQL.

Nota: mysql_real_escape_string() não escapa % e _. Estes caracteres são coringas no MySQL se combinados com LIKE, GRANT ou REVOKE.

Veja Também

mysql_set_charset() - Define o conjunto de caracteres do cliente
mysql_client_encoding() - Retorna o nome do conjunto de caracteres

Melhore Esta Página

Aprenda Como Melhorar Esta Página • Envie uma Solicitação de Modificação • Reporte um Problema

＋adicione uma nota

Notas Enviadas por Usuários (em inglês) 6 notes

down

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;

}

?>

down

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.

down

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)

down

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.

down

-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

down

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'

?>

＋adicione uma nota