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.

Источник

mysql_real_escape_string — Экранирует специальные символы в строках для использования в выражениях SQL

Данное расширение устарело, начиная с версии PHP 5.5.0, и будет удалено в будущем. Используйте вместо него MySQLi или PDO_MySQL. Смотрите также инструкцию MySQL: выбор API и соответствующий FAQ для получения более подробной информации. Альтернативы для данной функции:

Описание

mysql_real_escape_string() вызывает библиотечную функцию MySQL mysql_real_escape_string, которая добавляет обратную косую черту к следующим символам: \x00, \n, \r, \, ‘, « и \x1a.

Эта функция должна всегда (за несколькими исключениями) использоваться для того, чтобы обезопасить данные, вставляемые в запрос перед отправкой его в MySQL.

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

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

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

Возвращает строку, в которой экранированы все необходимые символы, или FALSE в случае ошибки.

Примеры

Пример #1 Простой пример использования mysql_real_escape_string()

Пример #2 Пример взлома с использованием SQL-инъекции

Запрос, который будет отправлен в MySQL:

Это позволит кому угодно войти в систему без пароля.

Примечания

Если не пользоваться этой функцией, то запрос становится уязвимым для взлома с помощью SQL-инъекций.

Замечание: mysql_real_escape_string() не экранирует символы % и _. Эти знаки являются масками групп символов в операторах MySQL LIKE, GRANT и REVOKE.

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

Источник

Экранирование кавычек в php, javascript и sql

Здравствуйте, уважаемые читатели блога LifeExample, сегодня я бы хотел раскрыть тему экранирования кавычек в php, javascript и sql, рассказать что это такое и зачем нужно, а также привести несколько полезных примеров показывающих необходимость экранирования.

Что такое экранирование кавычек

Чтобы дать определение этому понятию, для начала приведу небольшой пример объявления строки.

Практически в любом языке программирования мы используем следующий принцип объявления строковой переменной:

Все, что содержится между кавычек — понимается интерпретатором как строка.

Если нам нужно передать в строковую переменную текст содержащий кавычки и мы попытаемся сделать это таким образом:

то произойдет ошибка, поскольку вместо одной строки интерпретатор увидит две:

Чтобы такого не происходило необходимо экранировать кавычки. В javascript, например, это будет выглядеть таким образом:

После данного практического примера можно дать определение понятию экранирования кавычек.

Экранирование кавычек – это действие, совершаемое над строковой переменной в ходе работы скрипта. Действие это позволяет использовать кавычки в строке. Частным но довольно распространенным способом экранирования является подстановка обратного слеша \ перед внутренними кавычками.

Php экранирование кавычек

В php экранировать кавычки можно несколькими способами, первый из них аналогичен рассматриваемому выше.

Например, мы имеем строку с авторской и прямой речью, которая содержит кавычки:

«Как же вы поживаете?» – спросила Екатерина Ивановна. «Ничего, живем понемножечку», – ответил Старцев (Чехов)

Чтобы вывести ее на страницу, в PHP следует делать одним из следующих способов.

Экранирование обратным слешем:

Экранирование одинарными кавычками

В случае, когда внутренних кавычек в строке много проще при объявлении строки использовать одинарные кавычки, а внутри нее двойные. Либо, наоборот, в зависимости от наличия в тексте тех или иных кавычек.

Зачем может понадобиться экранирование кавычек в PHP

Помимо разобранного примера с выводом строк, экранирование кавычек и других спец символов зачастую необходимо при работе с БД.

Чтобы не допустить, различного рода проблем при работе с базой данных, перед сохранением данных в таблицы можно использовать функцию addslashes

Обе эти функции являются стандартными в php и экранируют спецсимволы строк. Когда и какую использовать, зависит от конкретных задач. Например addslashes лучше использовать для сериализованной строки при записи ее в базу, а mysql_real_escape_string для всех пользовательских данных пришедших с формы на сайте.

В небольших web-приложениях, можно не использовать ручное экранирование addslashes или mysql_real_escape_string если включить «Магические кавычки» — magic_quotes_gpc

Зачастую магические кавычки включены по умолчанию на сервере, это можно узнать из информацией полученной при выполнении функции

javascript экранирование кавычек

Очень часто, особенно в javascript приходится работать со строками, содержащими HTML разметку.

В javascript экранирование кавычек происходит аналогичным образом, либо обратным слешем, либо использованием разного типа кавычек.
Пример с обратным слешем:

Пример с внутренними кавычками:

Когда строка с HTML разметкой слишком длинная и требует переноса строки, снова появляется необходимость экранирования, в этом случае уже не кавычек, а символа переноса строки

Если в данном примере не использовать обратный слешь перед переносом строки, то скрипт работать не будет.

Довольно редко, но можно столкнуться с задачей передать HTML разметку в сериализованной строке формата JSON. Если строка содержит символы переноса, то формат JSON будет нарушен.

Чтобы избежать этих проблем нужно прогнать текст с переносом строк через функцию JSON.stringify()

JSON.stringify() – доступна только после подключения библиотеки jquery.

Sql экранирование кавычек

В sql экранирование кавычек помимо разобранных нами в php и js способов — обратного слеша и внутренних кавычек, имеет еще одно решение.

Для экранирования кавычки в sql нужно их дублировать.

Убрать экранирование кавычек

Убрать экранирование кавычек в php можно стандартной функцией stripslashes();

В javascript не существует аналога stripslashes, но ведь мы всегда можем воспользоваться регулярным выражением, которое поможет нам убрать экранирование кавычек в javascript

В данной статье я постарался раскрыть тему экранирования кавычек в php, js, mysql и показать в каких случаях необходимо применять экранирование. Надеюсь, статья оказалась полезной. Подписывайтесь на рассылку, ставьте лайки, добавляйтесь в друзья 😉

Читайте также похожие статьи:

Чтобы не пропустить публикацию следующей статьи подписывайтесь на рассылку по E-mail или RSS ленту блога.

Источник

addslashes

(PHP 4, PHP 5, PHP 7, PHP 8)

addslashes — Экранирует строку с помощью слешей

Описание

Небольшой пример использования функции addslashes() для экранирования вышеперечисленных символов:

Иногда функцию addslashes() некорректно пытаются использовать для предотвращения SQL-инъекций. Не делайте так. Вместо неё используйте подготовленные запросы или функции экранирования соответствующих модулей работы с базами данных.

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

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

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

Примеры

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

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

User Contributed Notes 38 notes

@ mark at hagers dot demon dot nl :

Never use addslashes function to escape values you are going to send to mysql. use mysql_real_escape_string or pg_escape at least if you are not using prepared queries yet.

keep in mind that single quote is not the only special character that can break your sql query. and quotes are the only thing which addslashes care.

To output a PHP variable to Javascript, use json_encode().

Beware of using addslashes() on input to the serialize() function. serialize() stores strings with their length; the length must match the stored string or unserialize() will fail.

Such a mismatch can occur if you serialize the result of addslashes() and store it in a database; some databases (definitely including PostgreSQL) automagically strip backslashes from «special» chars in SELECT results, causing the returned string to be shorter than it was when it was serialized.

In other words, do this.

[Note to the maintainers: You may, at your option, want to link this note to serialize() as well as to addslashes(). I’ll refrain from doing such cross-posting myself. ]

I was stumped for a long time by the fact that even when using addslashes and stripslashes explicitly on the field values double quotes («) still didn’t seem to show up in strings read from a database. Until I looked at the source, and realised that the field value is just truncated at the first occurrence of a double quote. the remainder of the string is there (in the source), but is ignored when the form is displayed and submitted.

For PHP 7.3.* use FILTER_SANITIZE_ADD_SLASHES.

In response to Krasimir Slavov and Luiz Miguel Axcar:

There are several encoding schemes for inserting binary data into places it doesn’t typically belong, such as databases and e-mail bodies. Check out the base64_encode() and convert_uuencode() functions for the details.

May it is better use the function mysql_real_escape_string instead of addslashes when inserting data into a MySQL database. Check it at:

Regarding the previous note using addslashes/stripslahes with regular expressions and databases it looks as if the purpose of these functions gets mixed.

addslahes encodes data to be sent to a database or something similar. Here you need addslashes because you send commands to the database as command strings that contain data and thus you have to escape characters that are special in the command language like SQL.

Therefore the use of addslahses on a regex does properly store the regex in the database.

stripslashes does the opposite: it decodes an addslashes encoded string. However, retrieving data from a database works differently: it does not go through some string interpretation because you actually retrieve your binary data in your variables. In other words: the data stored in your variable is the unmodified binary data that your database returned. You do not run stripslahes on data returned from a database. That way, the regexs are retrieved correctly, too.

This is different from other data exchange like urlencoded strings that you exchange with your browser. Here the data channel uses the same encodings in both directions: therefore you have to encode data to be sent and you have to decode data received.

spamdunk at home dot com, your way is dangerous on PostgreSQL (and presumably MySQL). You’re quite correct that ANSI SQL specifies using ‘ to escape, but those databases also support \ for escaping (in violation of the standard, I think). Which means that if they pass in a string that includes a «\'», you expand it to «\»'» (an escaped quote followed by a non-escaped quote. WRONG! Attackers can execute arbitrary SQL to drop your tables, make themselves administrators, whatever they want.)

The best way to be safe and correct is to:

Plus, if the database supports prepared statements (the soon-to-be-released PostgreSQL 7.3, Oracle, etc), several executes on the same prepare can be faster, since it can reuse the same query plan. If it doesn’t (MySQL, etc), this way falls back to quoting code that’s specifically written for your database, avoiding the problem I mentioned above.

(Pardon my syntax if it’s off. I’m not really a PHP programmer; this is something I know from similar things in Java, Perl, PL/SQL, Python, Visual Basic, etc.)

//sql insert code goes here.
?>

to quote boris-pieper AT t-online DOT de, 15-Jan-2005 06:07,

Note: You should use mysql_real_escape_string() (http://php.net/mysql_real_escape_string) if possible (PHP => 4.3.0) instead of mysql_escape_string().

You may also want to us it instead of addslashes.

There are other functions «kind of» like this one but this should help adding slashes to a form post which also contains arrays (and you can’t access runtime quotes), or you need to add slashes to an array which is already stripped:

Be careful on whether you use double or single quotes when creating the string to be escaped:

$test = ‘This is one line\r\nand this is another\r\nand this line has\ta tab’;

$test = «This is one line\r\nand this is another\r\nand this line has\ta tab»;

re: encryption, addslashes and mysql

Note that mcrypt encryption may add in an apostrophe from the ascii table which cannot be protected by addslashes. It may not even be on your keyboard.

Because encryption strings are random, you may not discover it unless you test (or stumble?) on the correct sequence which inserts an apostrophe in the encrypted string.

This means that testing is even more important where encryption is concerned. If I create a solution I’ll post it here.

What happends when you add addslashes(addslashes($str))? This is not a good thing and it may be fixed:

checkaddslashes(«aa’bb»); => aa\’bb
checkaddslashes(«aa\’bb»); => aa\’bb
checkaddslashes(«\'»); => \’
checkaddslashes(«‘»); => \’

Hope this will help you

If all you want to do is quote a string as you would normally do in PHP (for example, when returning an Ajax result, inside a json string value, or when building a URL with args), don’t use addslashes (you don’t want both » and ‘ escaped at the same time). Instead, just use this function:

Hi,
I use this recursive function for POST. It handles multidimensional arrays.

Источник

Защита от SQL инъекций

Внедрение SQL-кода (SQL инъекция) — один из распространённых способов взлома сайтов, работающих с базами данных. Способ основан на внедрении в запрос произвольного SQL-кода.
Внедрение SQL позволяет хакеру выполнить произвольный запрос к базе данных (прочитать содержимое любых таблиц, удалить, изменить или добавить данные).

Атака этого типа возможна, когда недостаточно фильтруются входные данные при использовании в SQL-запросах.

Принцип атаки внедрения SQL

Если на сервере передан параметр city_id, равный 10 ( /weather.php?city_id=10 ), то выполнится SQL-запрос:

Отсутствие должной обработки параметров SQL-запроса — это одна из самых серьёзных уязвимостей. Никогда не вставляйте данные от пользователя в SQL запросы «как есть»!

Приведение к целочисленному типу

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

PHP умеет присваивать переменной новый тип. Этот код принудительно назначит переменной целочисленный тип:

Экранирование значений

Что делать, если в SQL запрос требуется подставить строковое значение? Например, на сайте есть возможность поиска города по его названию. Форма поиска передаст поисковый запрос в GET-параметр, а мы используем его в SQL-запросе:

Смысл запроса поменялся, потому что кавычка из параметра запроса считается управляющим символом: MySQL определяет окончание значение по символу кавычки после него, поэтому сами значения кавычки содержать не должны.
Очевидно, приведение к числовому типу не подходит для строковых значений. Поэтому, чтобы обезопасить строковое значение, используют операцию экранирования.

Подготовленные выражения

Вид атак типа «SQL-инъекция» возможен, потому что значения (данные) для SQL-запроса передаются вместе с самим запросом. Так как данные не отделены от SQL-кода, они могут влиять на логику всего выражения. К счастью, MySQL предлагает способ передачи данных отдельно от кода. Такой способ называется подготовленными запросами.

Выполнение подготовленных запросов состоит из двух этапов: вначале формируется шаблон запроса — обычное SQL-выражение, но без действительных значений, а затем, отдельно, в MySQL передаются значения для этого шаблона.
Первый этап называется подготовкой, а второй — выражением. Подготовленный запрос можно выполнять несколько раз, передавая туда разные значения.

Этап подготовки
На этапе подготовки формируется SQL-запрос, где на месте значений будут находиться знаки вопроса — плейсхолдеры. Эти плейсхолдеры в дальнейшем будут заменены на реальные значения. Шаблон запроса отправляется на сервер MySQL для анализа и синтаксической проверки.
Пример:

Этот код сформирует подготовленное выражение для выполнения вашего запроса.

После выполнения запроса получить его результат в формате mysqli_result можно функцией mysqli_stmt_get_result() :

Значения привязанных к запросу переменных сервер экранирует автоматически. Привязанные переменные отправляются на сервер отдельно от запроса и не могут влиять на него. Сервер использует эти значения непосредственно в момент выполнения, уже после того, как был обработан шаблон выражения. Привязанные параметры не нуждаются в экранировании, так как они никогда не подставляются непосредственно в строку запроса.

Источник