php mysqli real escape string php
Функция mysqli_real_escape_string в PHP
mysqli_real_escape_string(идентификатор сервера MySQL, строка)
Рассмотрим пример использования этой функции. Сначала в примере создадим таблицу в базе ‘tester’, потом будем добавлять в неё данные.
Но что будет, если пользователь передаст такие данные:
Строка «bob’ #» будет закрывать SQL-запрос символом ‘, а после него будет следовать символ #, который в SQL обозначает комментарий.
В этом случае произойдёт сбой при добавлении пользователя, функция mysqli_error() выведет текст ошибки: «You have an error in your SQL syntax. «, что в принципе не очень критично для системы в целом.
Возьмём тот же самый код, только немного изменим его.
Этот код будет работать, пока пользователь не передаст данные:
В таком случае мы получим SQL-запрос:
UPDATE users SET password = » #
Всё, что за символом # будет комментарием, а не частью запроса. Получается, что этот запрос изменит все пароли в таблице ‘users’.
Пример обезвреживания данных для MySQL
В PHP есть встроенное свойство «волшебных кавычек», которое автоматически экранирует все одинарные и двойные кавычки, чем создаёт проблемы. Некоторые программисты отключают это свойство, чтобы вставить свой код, отвечающий за безопасность. Расчитывать на свойство «волшебных кавычек» не стоит.
Свойство «волшебных кавычек» не рекомендуется использовать начиная с PHP 5.3.0, а из PHP 6.0.0 оно вообще было удалено.
Вот корректное решение для обезвреживания данных, введённых пользователем, приемлемое для MySQL:
Функция get_magic_quotes_gpc() — получает текущую активную установку конфигурации «магических» кавычек gpc. Возвращает TRUE, если свойство «волшебных кавычек» находится в активном состоянии.
Если свойство «волшебных кавычек» включено, то любые добавленные слеши подлежат удалению, в противном случае функция mysql_real_escape_string() может отключить некоторые символы дважды, сделав строки не пригодными для дальнейшей работы.
Функция stripslashes() — удаляет экранирование символов.
Вот ещё один пример:
mysqli::real_escape_string
mysqli_real_escape_string
Описание
Эта функция используется для создания допустимых в SQL строк, которые можно использовать в SQL выражениях. Заданная строка кодируется для создания экранированной строки SQL с учётом текущего набора символов подключения.
Безопасность: набор символов по умолчанию
Список параметров
Строка, которую требуется экранировать.
Возвращаемые значения
Возвращает экранированную строку.
Примеры
Пример #1 Пример использования mysqli::real_escape_string()
Результатом выполнения данных примеров будет что-то подобное:
Смотрите также
User Contributed Notes 9 notes
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.
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
?>
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):
?>
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.
Что конкретно делает эта функция mysqli_real_escape_string()?
Что делает эта функция?
mysqli_real_escape_string();
P.S. Документацию читал, все равно не понятно?
Это хороший вопрос, в первую очередь потому что найти человека, который знает правильный ответ, практически нереально. Опроси 10 похапешников, 10 из них тебе наплетут ереси, которая не имеет с реальностью ничего общего. Любой, кто заикнется про SQL инъекции, уже облажался.
Как ты, наверное, уже знаешь, строки в SQL берутся в кавычки:
SELECT * FROM table WHERE name=’vasya’
Вот чтобы vasya не приняли за имя таблицы или ключевое слово, его берут в кавычки. Очень просто. Но иногда у человека имя не просто вася. Что будет вот с таким запросом?
то БД решит, что последняя кавычка экранирована, и строка не заканчивается. Снова мясорубка.
Также mysqli_real_escape_string() экранирует еще несколько символов, но уже из чисто эстетических соображений.
1. Строки надо форматировать в любом случае, независимо от того, ждем мы инъекцию, или нет. Мясорубка нам точно так же не нужна.
2. Строками синтаксис SQL запросов не исчерпывается. Есть числовые литералы, есть имена полей. Для всех них mysqli_real_escape_string() бесполезна чуть более чем полностью.
То есть, отсюда можно сделать вывод, что нельзя использовать mysqli_real_escape_string() для защиты от инъекций. Она предназначена для другого. Вот для этого другого, для форматирования строк, ее использовать можно. Но не нужно.
В принципе, mysqli умеет так делать, но не так удобно как PDO. Поэтому при возможности вместо нее лучше использовать PDO:
— и получить, в итоге, готовый массив с данными, которые вернула БД.
Если же возможности нет, то кода придется написать чуть побольше
Но при этом всё равно никакой тебе возни с кавычками, слешами, real, escape, и прочей ерундой. Просто, быстро, лаконично и безопасно.
mysql_real_escape_string
mysql_real_escape_string — Экранирует специальные символы в строках для использования в выражениях SQL
Данный модуль устарел, начиная с версии PHP 5.5.0, и удалён в PHP 7.0.0. Используйте вместо него MySQLi или PDO_MySQL. Смотрите также инструкцию MySQL: выбор API. Альтернативы для данной функции:
Описание
Эта функция должна всегда (за несколькими исключениями) использоваться для того, чтобы обезопасить данные, вставляемые в запрос перед отправкой его в MySQL.
Безопасность: кодировка символов по умолчанию
Список параметров
Возвращаемые значения
Возвращает строку, в которой экранированы все необходимые символы, или false в случае возникновения ошибки.
Ошибки
Примеры
Пример #1 Простой пример использования mysql_real_escape_string()
Пример #2 Пример использования mysql_real_escape_string() без наличия соединения
Этот пример показывает, что произойдёт, если вызвать эту функцию без наличия соединения с MySQL.
// Коннекта к MySQL нет
Результатом выполнения данного примера будет что-то подобное:
Пример #3 Пример взлома с использованием SQL-инъекции
Запрос, который будет отправлен в MySQL:
Это позволит кому угодно войти в систему без пароля.
Примечания
Если не пользоваться этой функцией, то запрос становится уязвимым для взлома с помощью SQL-инъекций.
Смотрите также
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.
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.
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`
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 » = ‘» ;
// 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).
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.
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.
mysql_real_escape_string
Описание
mysql_real_escape_string() вызывает библиотечную функцмю MySQL mysql_real_escape_string, которая добавляет обратную косую черту к следующим символам: \x00, \n, \r, \, ‘, » and \x1a.
Эта функция должна всегда (за несколькими исключениями) использоваться для того, чтобы обезопасить данные, вставляемые в запрос перед отправкой его в MySQL.
Строка, которая должна быть экранирована.
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() was called with no arguments. If by chance no connection is found or established, an E_WARNING level warning is generated.
Возвращает строку, в которой экранированы все необходимые символы, или FALSE в случае ошибки.
Пример 1. Простой пример использования mysql_real_escape_string()
Пример 2. Пример взлома с использованием SQL Injection
Запрос, который будет отправлен в MySQL:
Это позволит кому угодно войти в систему без пароля.
Пример 3. Лучший вариант составления запроса
Применение mysql_real_escape_string() к каждой переменной, вставляемой в запрос, предотвращает SQL Injection. Нижеследующий код является наилучшим вариантом составления запросов и не зависит от установки Magic Quotes.
Запрос, составленный таким образом, будет выполнен без ошибок, и взлом с помощью SQL Injection окажется невозможен.
Примечания
Замечание: Если не пользоваться этой функцией, то запрос становится уязвимым для взлома с помощью SQL Injection.
Замечание: mysql_real_escape_string() не экранирует символы % и _. Эти знаки являются масками групп символов в операторах MySQL LIKE, GRANT или REVOKE.