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.

Источник

Экранирование кавычек в 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 ленту блога.

Источник

Защита от 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() :

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

Источник

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.

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

Источник

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

Что такое SQL-инъекция

Как начинающие разработчики обычно пишут запрос к базе данных:

При запуске этого запроса будут выбраны все записи вместо одной, поскольку записей с отрицательными идентификаторами скорее всего нет в базе, а условие 1=1 всегда истинно.

Но суть в другом. После фрагмента 1=1 злоумышленник может дополнить запрос любым произвольным SQL-кодом.

Что может сделать злоумышленник?

Это зависит от конкретного запроса, а также способа его запуска.

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

Но кое-что плохое злоумышленник сделать может. Например, с помощью UNION можно получить любые данные из любых таблиц.

Поскольку UNION позволяет объединять данные из таблиц только с одинаковым количеством столбцов, злоумышленник может указать 2 необходимых ему столбца, а остальные 2 заполнить любыми значениями, например единицами:

В итоге вместо title и content на страницу будут выведены login и password одного из пользователей. И это только один из десятков возможных вариантов взлома.

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

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

Возьмём такой пример:

С этим запросом всё в порядке, он выполнится как мы и ожидаем:

Тогда SQL-запрос станет таким:

Попытка выполнить этот запрос приведёт к ошибке синтаксиса. Чтобы её не было, вторую кавычку нужно экранировать, т.е. добавить к ней обратный слеш.

Способы экранирования и их надёжность разберём чуть ниже, а сейчас для простоты возьмём addslashes() :

Готово, запрос выполнится даже при наличии кавычек.

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

А теперь важный момент. Некоторые разработчики считают, экранирования достаточно для полной защиты от SQL-инъекций.

Хорошо, ещё раз посмотрим на самый первый пример с SQL-инъекцией:

В этом запросе нет никаких кавычек. Но уязвимость есть. Отсюда делаем вывод, что экранирование не гарантирует защиту от SQL-инъекций.

Неэффективные способы защиты от SQL-инъекций

Никогда так не делай! Любые данные перед подстановкой в SQL-запрос должны проходить фильтрацию и/или валидацию.

1. Функция htmlspecialchars()

Время от времени встречаю статьи, где авторы используют функцию htmlspecialchars() для экранирования данных:

Это опасно! Штука в том, что функция htmlspecialchars() пропускает без экранирования опасные символы: \ (слеш), \0 (nul-байт) и \b (backspace).

Вот полный пример кода, демонстрирующего уязвимость:

В итоге SQL-запрос будет таким:

2. Фильтрация по чёрному списку символов

По каким-то непонятным мне причинам ещё существуют разработчики, использующие чёрные списки символов:

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

Я не хочу сказать, что этот подход не будет работать, но его применение под большим вопросом:

К примеру, пользователь хочет использовать логин

Я считаю, лучше уточнить у пользователя, нравится ли ему такой отфильтрованный логин или он хотел бы что-то поменять. Короче, я за валидацию по белому списку вместо фильтрации по чёрному.

3. Функция stripslashes()

Редко, но встречается код, использующий stripslashes() перед записью в базу. Поскольку новички до сих пор копируют этот код в свои проекты, объясню, зачем эта функция нужна.

Сделано это было для защиты новичков, которые подставляли данные напрямую в SQL-запросы. На практике это было не самое удачное решение:

Вот почему функцию stripslashes() можно встретить в старых учебниках. Чтобы отменить экранирование символов и получить исходную строку.

Начиная с PHP 5.4 функционал волшебных кавычек удалён, поэтому использовать stripslashes() перед записью в базу нет никакого смысла.

4. Функция addslashes()

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

Эффективные способы защиты

1. Функция mysql(i)_real_escape_string

Есть две важные детали, которые вы должны знать, когда используете эту функцию.

Вторая опасность подстерегает тех, кто использует некоторые специфические кодировки вроде GBK. В этом случае вам обязательно нужно указывать кодировку при установке соединения с базой.

Почитать о проблеме можно тут (блог разработчика, обнаружившего ошибку), здесь и подробней с примерами там.

2. Приведение к числу

Кавычки здесь не обязательны, поскольку в запрос в любом случае подставится число.

Есть один нюанс. Как я писал выше, мне не очень нравится идея фильтрации данных и здесь она может выйти боком с точки зрения SEO.

Если алгоритм поиска статьи заключается в том, что мы берём вторую часть URL и приводим её к числу, вроде такого:

Тогда можно писать какие угодно символы после числа 15 (только один следующий символ должен быть не цифровым), например /product/15abcde13824_ahaha_lol и система всё равно будет отображать статью c >

3. Подготовленные запросы

Один из лучших способов защиты от SQL инъекций. Суть в том, что SQL запрос сначала «подготавливается», а затем в него отдельно передаются данные.

Такой подход гарантирует отсутствие SQL-инъекций в момент подстановки данных, поскольку запрос уже «подготовлен» и не может быть изменён.

Но, как обычно, всё портят детали.

Первая деталь. Чуть выше я указывал ссылку на обсуждение уязвимости mysql_real_escape_string.

Вторая деталь. Нужно понимать, что защита от SQL-инъекций будет действовать только в том случае, если мы не подставляем никаких данных напрямую в запрос. Если разработчик решит сделать так:

Тогда его не спасут никакие подготовленные запросы.

И третья деталь. В подготовленные запросы нельзя подставлять названия столбцов и таблиц.

Прекрасно. И что теперь делать?

В общем, опять надо что-то вручную допиливать, придумывать собственные функции генерации запросов. Не комильфо. Рекомендую поступить иначе.

4. Готовые библиотеки

Разработчики популярных библиотек наверняка гораздо умней и опытней нас. Они давно всё продумали и протестировали на десятках тысяч программистов. Так почему нет?

Для простых проектов вполне хватит Medoo или RedBeanPHP, для средних рекомендую (и всегда использую) Eloquent, ну а для крупных проектов лучше всего подойдёт мощная и суровая Doctrine.

Источник