php как экранировать get
Экранирование (или что нужно знать для работы с текстом в тексте)
SQL инъекции, подделка межсайтовых запросов, поврежденный XML… Страшные, страшные вещи, от которых мы все бы хотели защититься, да вот только знать бы почему это все происходит. Эта статья объясняет фундаментальное понятие, стоящее за всем этим: строки и обработка строк внутри строк.
Основная проблема
Это всего лишь текст. Да, просто текст — вот она основная проблема. Практически все в компьютерной системе представлено текстом (который, в свою очередь, представлен байтами). Разве что одни тексты предназначены для компьютера, а другие — для людей. Но и те, и те, всё же остаются текстом. Чтобы понять, о чем я говорю, приведу небольшой пример:
Не поверите: это — текст. Некоторые люди называют его XML, но это — просто текст. Возможно, он не подойдет для показа учителю английского языка, но это — всё еще просто текст. Вы можете распечатать его на плакате и ходить с ним на митинги, вы можете написать его в письме своей маме… это — текст.
Тем не менее, мы хотим, чтобы определенные части этого текста имели какое-то значение для нашего компьютера. Мы хотим, чтобы компьютер был в состоянии извлечь автора текста и сам текст отдельно, чтобы с ним можно было что-то сделать. Например, преобразовать вышеупомянутое в это:
Иными словами, мы использовали определенные правила в нашем тексте, чтобы обозначить некое особое значение, которое кто-то, соблюдая те же правила, мог бы использовать.
Ладно, это всё не так уж и трудно понять. А что если мы хотим использовать эти забавные скобки, имеющие какое-то особое значение, в нашем тексте, но без использования этого самого значения. Примерно так:
Теперь, текст должен стать полностью однозначным. » » — «>».
Техническое определение этого — экранирование, мы избегаем специальные символы, когда не хотим, чтобы они имели свое особое значение.
Если определенные символы или последовательности символов в тексте имеют особое значение, то должны быть правила, определяющие, как разрешить ситуации, когда эти символы должны использоваться без привлечения своего особого значения. Или, другими словами, экранирование отвечает на вопрос: «Если эти символы такие особенные, то как мне их использовать в своем тексте?».
Как можно было заметить в примере выше, амперсанд (&) — это тоже специальный символ. Но что делать, если мы хотим написать » & «, т.е. мы должны написать: » < «
Другие примеры
XML — не единственный случай «страдания» от специальных символов. Любой исходный код, в любом языке программирования может это продемонстрировать:
Всё просто — обычный текст четко отделяется от «не текста» двойными кавычками. Таким же образом можно использовать и мой текст из курса математического анализа:
Клево! И даже не нужно прибегать к экранированию! Но, подождите, а что, если я хочу процитировать кого-нибудь?
Хм… печаль, тоска. Как человек, Вы можете определить где начинается и заканчивается текст и где находится цитата. Однако это снова стало неоднозначным для любого компьютера. Мы должны придумать какие-то правила экранирования, которые помогали бы нам различить буквальный » и «, который означает конец текста. Большинство языков программирование используют косую черту:
«\» делает символ после него не специальным. Но это, опять-таки, значит, что «\» — специальный символ. Для однозначного написания этого символа в тексте, к нему нужно добавить такой же символ, написав: «\\». Забавно, не так ли?
Атака!
Не всё было бы так плохо, если бы просто должны были прибегать к экранированию. Напрягает конечно, но это не так ужасно. Проблемы начинаются, когда одни программы пишут текст для других программ, чтобы те могли его «читать». И нет, это не научная фантастика, это происходит постоянно. Например, на этом сайте, вы, публикуя сообщение, не набираете его в ручную в формате HTML, а пишите лишь только текст, который, в последствие, преобразуется этим сайтом в HTML, после чего, уже браузер, преобразует «сгенерированный» HTML снова в читабельный текст.
Другой распространенный пример и источник многих проблем безопасности — SQL запросы. SQL — язык, предназначенный для упрощения общения с базами данных:
В этом тексте практически нет никаких специальных символов, в основном английские слова. И все же, фактически у каждого слова в SQL есть особое значение. Это используется во многих языках программирования во всем мире в той или иной форме, например:
Эти две простые строки абстрагируют от нас ужасно сложную задачу запроса программой у БД данных, удовлетворяющих нашим требованиям. БД «просеивает», возможно, терабайты битов и байтов, чтобы вернуть красиво отформатированный результат программе, сделавшей запрос. Серьезно, вся эта хрень инкапсулирована в простом англо-подобном предложении.
Для того, чтобы сделать это полезным, подобные запросы не хард-кодятся, а строятся на основе пользовательского ввода. Это же предложение, направленное на использование разными пользователями:
В случае, если Вы просто просматриваете эту статью: Это — анти-пример! Это худшее, что Вы когда-либо могли сделать! Это кошмар безопасности! Каждый раз, когда Вы будете писать что-то подобное, будет погибать один невинный котенок! Ктулху сожрет Вашу душу за это!
Вроде бы звучит все не так ужасно, да? Давайте попробуем ввести несколько случайных значений, которые можно ввести на вашем случайном веб-сайте и какие запросы из этого получатся:
Первый запрос выглядит не страшно, а вполне себе мило, правда? Номер 2, кажется, «несколько» повреждает наш синтаксис из-за неоднозначного ‘. Чертов немец! Номер 4 какой-то дурацкий. Кто бы такое написал? Это ведь не имеет смысла…
Но не для БД, обрабатывающей запрос… БД понятия не имеет от куда этот запрос поступил, и что он должен значить. Единственное, что она видит — это два запроса: найти номер пользователя по имени Joe, а затем удалить таблицу users (что сопровождается комментарием ‘), и это будет успешно сделано.
Для вас это не должно быть новостью. Если это так, то, пожалуйста, прочитайте эту статью еще раз, ибо Вы либо новичок в программировании, либо последние 10 лет жили в пещере. Этот пример иллюстрирует основы SQL-инъекций, применяемых во всем мире. для того, чтобы удалить данные, или получить данные, которые не должны быть просто так получены, или войти в систему, не имея на то прав и т.д. А все потому, что БД воспринимает англо-подобный «приговор» слишком буквально.
Впереееееед!
Следующий шаг: XSS атаки. Действуют они аналогично, только применяются к HTML.
Допустим, Вы решили проблемы с БД, получаете данные от пользователя, записываете в базу и выводите их назад на веб-сайт, для доступа пользователям. Это то, что делает типичный форум, система комментариев и т.д. Где-то на вашем сайте есть что-то подобное:
Если ваши пользователи будут хорошими и добрыми, то они будут размещать цитаты старых философов, а сообщения будут иметь примерно следующий вид:
Если пользователи будут умниками, то они, наверное, будут говорить о математике, и сообщения будут такие:
Хм… Опять эти осквернители наших скобок. Ну, с технической точки зрения они могут быть неоднозначными, но браузер простит нам это, правда?
Хорошо, СТОП, что за черт? Какой-то шутник ввел javascript теги на ваш форум? Любой, кто смотрит на это сообщение на вашем сайте, сейчас загружает и выполняет скрипты в контексте вашего сайта, которые могут сделать не весть что. А это не есть хорошо.
Не следует понимать буквально
В вышеупомянутых случаях, мы хотим каким-то образом сообщить нашей БД или браузеру, что это просто текст, ты с ним ничего не делай! Другими словами, мы хотим «удалить» особые значения всех специальных символов и ключевых слов из любой информации, предоставленной пользователем, ибо мы ему не доверяем. Что же делать?
Что? Что говоришь, мальчишка? Ах, ты говоришь, «экранирование»? И ты абсолютно прав, возьми печеньку!
Если мы применим экранирование к пользовательским данным до объединения их с запросом, то проблема решена. Для наших запросов к БД это будет что-то вроде:
Просто одна строка кода, но теперь больше никто не может «взломать» нашу базу данных. Давайте снова посмотрим как будут выглядеть SQL-запросы, в зависимости от ввода пользователя:
Alex
mysql_real_escape_string без разбора помещает косую черту перед всем, у чего может быть какое-то особое значение.
Далее, заменим наш скрипт на форуме:
Мы применяем функцию htmlspecialchars ко всем пользовательским данным, прежде, чем вывести их. Теперь сообщение вредителя выглядит так:
Обратите внимание, что значения, полученные от пользователи, на самом деле не «повреждены». Любой браузер парсит этот как HTML и выведет на экран все в правильной форме.
Что возвращает нас к.
Все вышеупомянутое демонстрирует проблему, характерную для многих систем: текст в тексте должно быть подвергнут экранированию, если предполагается, что он не должен иметь специальных символов. Помещая текстовые значения в SQL, они должны быть экранированы по правилам SQL. Помещая текстовые значения в HTML, они должны быть экранированы по правилам HTML. Помещая текстовые значения в (название технологии), они должны быть экранированы по правилам (название технологии). Вот и все.
Для полноты картины
При этом отправка происходит в два этапа, четко разграничивая запрос и переменные. БД имеет возможность сначала понять структуру запроса, а потом заполнить его значениями.
В реальном мире, все это используется вместе для различных ступеней защиты. Вы должны всегда использовать проверку допустимости (валидацию), чтобы быть уверенным, что пользователь вводит корректные данные. Затем вы можете (но не обязаны) сканировать введенные данные. Если пользователь явно пытается «втюхать» вам какой-то скрипт, вы можете просто удалить его. Затем, вы всегда, всегда должны экранировать пользовательские данные прежде, чем поместить их в SQL-запрос (это же касается и HTML).
Защита от 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.
Экранирование кавычек в 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 ленту блога.
Уроки по PHP: типы переменных, экранирование, спецсимволы и синтаксис heredoc в PHP
Рад снова приветствовать всех на страницах блога посвящённому всем тонкостям успешного создания и продвижения сайтов – Site on! В сегодняшнем уроке по PHP мы затронем такие темы как: типы переменных, экранирование, спецсимволы, а также синтаксис heredoc в PHP.
Типы переменных
PHP имеет восемь различных типов переменных, из них
2 специальных типа:
Прежде чем перейти к рассмотрению каждого из типов более подробно, стоит уточнить, что PHP НЕ строго типизированный язык, а язык с динамической типизацией. Это значит, что нам не нужно заранее (при создании) объявлять тип каждой переменной. PHP сам догадается, какой тип имеет та или иная переменная, исходя из того, что мы в эту переменную положим. Это также значит, что в отличие от языков со строгой типизаций мы можем в переменную с числом (integer) взять и положить строку (string) и это не будет ошибкой! Это одна из особенностей PHP, которая очень нравится людям (новичкам), ранее не имевшим дело с программированием. Как правило, в итоге все приходят к тому, что это минус языка, а не плюс.
Boolean (логический) – простейший тип. Может принимать всего 2 значения: true или false (верно или неверно), они регистра-независимы (можно писать TRUE, trUe и тд.). Наглядный пример:
Как видите, браузер не понимает булев тип, в отличие от PHP, поэтому при попытке вывести true или false он выведет на страницу число 1 или пустую строку.
При преобразовании в логический тип следующие значения рассматриваются как FALSE:
Все остальные значения рассматриваются как TRUE.
Идём далее: разница между integer и float, как вы уже могли догадаться – в точке 🙂 Смотрим пример:
Однако самым часто применяемым типом в PHP можно считать именно строки (string). Строки можно записывать либо в одинарных, либо в двойных кавычках, но записывать строки в двойных кавычках я никогда и никому не советую, так как тем самым вы заставляете интерпретатор PHP «парсить» вашу строку на наличие переменных в ней, чем хоть и незначительно, но замедляете работу. Даже если вы хотите использовать в вашей строке переменные – это можно сделать с помощью одинарных кавычек + конкатенации (склеивание двух и более строк в одну). Для чего тогда двойные кавычки вообще нужны? Например, когда мы хотим использовать спецсимволы (\n, \r и тд.), но о них немного позже.
Также стоит отметить, что использование одинарных кавычек + конкатенации делает код гораздо читабельней, чем если всё без разбора засовывать в двойные кавычки. Но хватит предисловий, сейчас вы сами всё увидите и поймёте:
Подробнее о конкатенации мы поговорим в следующей статье.
Далее мы рассмотрим такой тип переменных в PHP как NULL. Здесь всё очень просто, переменная считается NULL если:
Изучение оставшихся типов переменных на данном этапе было бы бессмысленным. С остальными типами мы столкнёмся и разберём их при более глубоком изучении PHP.
Экранирование в PHP
В первом варианте (с двойными кавычками) мы использовали экранирование спецсимвола доллара, благодаря чему данный спецсимвол перестал иметь своё специальное назначение (обозначение переменных) и превратился в обыкновенный знак доллара.
Во втором варианте (с одинарными кавычками) как вы уже знаете – PHP интерпретатор даже не пытался найти переменных в строке, а потому экранирование не потребовалось.
Далее про экранирование: в одинарных кавычках ничего и никогда экранировать не нужно, попросту нечего. От экранирования мы плавно переходим к уже упомянутым спецсимволам в PHP.
Спецсимволы в PHP
Специально для читателей блога Site on! я подготовил небольшой список специальных символов в языке программирования PHP:
Посмотрим на работу спецсимволов на примере \n – спецсимвол, который делает перевод на новую строку (как Энтер), однако браузеры не понимают (и не должны) его и игнорируют, но результат его работы можно посмотреть в исходном коде страницы:
Исходный код (Ctrl + U):
Если для посетителей в браузере спецсимвол \n никак не отображается, тогда в чём его смысл?
Во-первых, с помощью спецсимволов и \n в частности можно удобно форматировать код на странице (как в примере выше).
Во-вторых, \n можно использовать, например, при операциях записи в файл, чтобы сделать перенос (Энтер) и продолжить запись на новой строке.
Альтернативой такого форматирования является heredoc.
Синтаксис heredoc в PHP
Исходный код (Ctrl + U):
Результат говорит сам за себя, теперь давайте разберемся, как же всё устроено: