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

• Перевод
• Tutorial

SQL инъекции, подделка межсайтовых запросов, поврежденный XML… Страшные, страшные вещи, от которых мы все бы хотели защититься, да вот только знать бы почему это все происходит. Эта статья объясняет фундаментальное понятие, стоящее за всем этим: строки и обработка строк внутри строк.

Основная проблема Это всего лишь текст. Да, просто текст - вот она основная проблема. Практически все в компьютерной системе представлено текстом (который, в свою очередь, представлен байтами). Разве что одни тексты предназначены для компьютера, а другие - для людей. Но и те, и те, всё же остаются текстом. Чтобы понять, о чем я говорю, приведу небольшой пример:
Homo Sapiens Suppose, there is the English text, which I don"t wanna translate into Russian
Не поверите: это - текст. Некоторые люди называют его XML, но это - просто текст. Возможно, он не подойдет для показа учителю английского языка, но это - всё еще просто текст. Вы можете распечатать его на плакате и ходить с ним на митинги, вы можете написать его в письме свое маме… это - текст.

Тем не менее, мы хотим, чтобы определенные части этого текста имели какое-то значение для нашего компьютера. Мы хотим, чтобы компьютер был в состоянии извлечь автора текста и сам текст отдельно, чтобы с ним можно было что-то сделать. Например, преобразовать вышеупомянутое в это:
Suppose, there is the English text, which I don"t wanna translate into Russian by Homo Sapiens
Откуда компьютер знает, как сделать это? Ну, потому что мы весьма кстати обернули определенные части текста специальными словами в забавных скобках, как, например, и. Поскольку мы сделали это, мы можем написать программу, которая искала бы эти определенные части, извлекала текст и использовала бы его для какого-нибудь нашего собственного изобретения.

Иными словами, мы использовали определенные правила в нашем тексте, чтобы обозначить некое особое значение, которое кто-то, соблюдая те же правила, мог бы использовать.
Ладно, это всё не так уж и трудно понять. А что если мы хотим использовать эти забавные скобки, имеющие какое-то особое значение, в нашем тексте, но без использования этого самого значения?.. Примерно так:
Homo Sapiens < n and y >
Символы "" не являются ничем особенным. Они могут законно использоваться где угодно, в любом тексте, как в примере выше. Но как же наша идея о специальных словах, типа? Значит ли это, что тоже является каким-то ключевым словом? В XML - возможно да. А возможно нет. Это неоднозначно. Поскольку компьютеры не очень справляются с неоднозначностями, то что-то в итоге может дать непредвиденный результат, если мы не расставим сами все точки над i и не устраним неоднозначности.
Решить эту дилемму можно, заменив неоднозначные символы чем-то однозначным.
Homo Sapiens Basic math tells us that if x < n and y > n, x cannot be larger than y.
Теперь, текст должен стать полностью однозначным. "".
Техническое определение этого - экранирование , мы избегаем специальные символы, когда не хотим, чтобы они имели свое особое значение.
escape |iˈskāp| [ no obj. ] вырваться на свободу [ with obj. ] не заметить / не вспомнить [...] [ with obj. ] IT: причина быть интерпретированным по-разному [...]
Если определенные символы или последовательности символов в тексте имеют особое значение, то должны быть правила, определяющие, как разрешить ситуации, когда эти символы должны использоваться без привлечения своего особого значения. Или, другими словами, экранирование отвечает на вопрос: "Если эти символы такие особенные, то как мне их использовать в своем тексте?" .
Как можно было заметить в примере выше, амперсанд (&) - это тоже специальный символ. Но что делать, если мы хотим написать "

Если ваши пользователи будут хорошими и добрыми, то они будут размещать цитаты старых философов, а сообщения будут иметь примерно следующий вид:

Posted by Plato on January 2, 15:31

I am said to have said "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."

Если пользователи будут умниками, то они, наверное, будут говорить о математике, и сообщения будут такие:

Posted by Pascal on November 23, 04:12

Basic math tells us that if x < n and y > n, x cannot be larger than y.

Хм... Опять эти осквернители наших скобок. Ну, с технической точки зрения они могут быть неоднозначными, но браузер простит нам это, правда?

Хорошо, СТОП, что за черт? Какой-то шутник ввел javascript теги на ваш форум? Любой, кто смотрит на это сообщение на вашем сайте, сейчас загружает и выполняет скрипты в контексте вашего сайта, которые могут сделать не весть что. А это не есть хорошо.

Не следует понимать буквально В вышеупомянутых случаях, мы хотим каким-то образом сообщить нашей БД или браузеру, что это просто текст, ты с ним ничего не делай! Другими словами, мы хотим "удалить" особые значения всех специальных символов и ключевых слов из любой информации, предоставленной пользователем, ибо мы ему не доверяем. Что же делать?

Что? Что говоришь, мальчишка? Ах, ты говоришь, "экранирование"? И ты абсолютно прав, возьми печеньку!
Если мы применим экранирование к пользовательским данным до объединения их с запросом, то проблема решена. Для наших запросов к БД это будет что-то вроде:
$name = $_POST["name"]; $name = mysql_real_escape_string($name); $query = "SELECT phone_number FROM users WHERE name = "$name""; $result = mysql_query($query);
Просто одна строка кода, но теперь больше никто не может "взломать" нашу базу данных. Давайте снова посмотрим как будут выглядеть SQL-запросы, в зависимости от ввода пользователя:
Alex
SELECT phone_number FROM users WHERE name = "Alex"
Mc"Donalds
SELECT phone_number FROM users WHERE name = "Mc\"Donalds"
Joe"; DROP TABLE users; --
SELECT phone_number FROM users WHERE name = "Joe\"; DROP TABLE users; --"
mysql_real_escape_string без разбора помещает косую черту перед всем, у чего может быть какое-то особое значение.

Мы применяем функцию htmlspecialchars ко всем пользовательским данным, прежде, чем вывести их. Теперь сообщение вредителя выглядит так:

Posted by JackTR on July 18, 12:56

Обратите внимание, что значения, полученные от пользователи, на самом деле не "повреждены". Любой браузер парсит этот как HTML и выведет на экран все в правильной форме.

Что возвращает нас к... Все вышеупомянутое демонстрирует проблему, характерную для многих систем: текст в тексте должно быть подвергнут экранированию, если предполагается, что он не должен иметь специальных символов. Помещая текстовые значения в SQL, они должны быть экранированы по правилам SQL. Помещая текстовые значения в HTML, они должны быть экранированы по правилам HTML. Помещая текстовые значения в (название технологии), они должны быть экранированы по правилам (название технологии). Вот и все.Для полноты картины Есть, конечно, другие способы борьбы с пользовательским вводов, который должен или не должен содержать специальные символы:

• Validation
  Вы можете проверить, соответствует ли пользовательский ввод некоторой заданной спецификации. Если Вы требуете ввода числа, а пользователь вводит нечто другое, программа должна сообщить ему об этом и отменить ввод. Если все это правильно организовать, то нет никакого риска схватить "DROP TABLE users" там, где, предполагалось, пользователь введет "42". Это не очень практично, для избегания HTML/SQL-инъекций, т.к. часто требуется принять текст свободного формата, который может содержать "подковырки". Обычно валидацию используют в дополнение к другим мерам.
• Sanitization
  Вы можете так же "втихую" удалить любые символы, которые считаете опасными. Например, просто удалить что-либо похожее на HTML-тег, что избежать добавления на ваш форум. Проблема в том, что вы можете удалить вполне законные части текста.
  Prepared SQL statements
  Есть специальные функции, делающие то, чего мы и добивались: заставляют БД понять различия между самим SQL-запросом и информацией, предоставленной пользователями. В РНР они выглядят примерно так:
  $stmt = $pdo->prepare("SELECT phone_number FROM users WHERE name = ?"); $stmt->execute($_POST["name"]);
  При этом отправка происходит в два этапа, четко разграничивая запрос и переменные. БД имеет возможность сначала понять структуру запроса, а потом заполнить его значениями.

В реальном мире, все это используется вместе для различных ступеней защиты. Вы должны всегда использовать проверку допустимости (валидацию), чтобы быть уверенным, что пользователь вводит корректные данные. Затем вы можете (но не обязаны) сканировать введенные данные. Если пользователь явно пытается "втюхать" вам какой-то скрипт, вы можете просто удалить его. Затем, вы всегда, всегда должны экранировать пользовательские данные прежде, чем поместить их в SQL-запрос (это же касается и HTML).

2007.11.08 16:07

Столкнулся с проблемой автоматического добавления кавычек в PHP при вводе информации в базу данных.

Немного покопавшись в интернете обнаружил, что проблему можно решить, изменив настройки сервера с помощью директив в.htaccess: magic_quotes_gpc и magic_quotes_runtime.

Говорят (и я этому даже верю), что разработчики языка php, будучи не в силах заставить основную массу php-программистов писать качественный код, решили позаботиться о безопасности наших СУБД и ввели автоматическое добавление слэшей перед спецсимволами. Слэши добавляются на основании директив php.ini (magic_quotes_gpc и magic_quotes_runtime).

Директивы имеют общее название "волшебные кавычки", я же зову их “адские кавычки”. Действительно, в грамотно написанном приложении необходимость в автоматическом закавычивании отсутствует, более того: лишние кавычки мешают, и их приходится удалять.

Первая директива - magic_quotes_gpc - означает, что PHP автоматически добавляет слэши к данным, пришедшим от пользователя - из POST-, GET-запросов и cookies. Вторая переменная - magic_quotes_runtime - означает, что слэши добавляются к данным, полученным во время исполнения скрипта - например, из файла или базы данных. Так, некоторые функции, представляющие подобную информацию, выполняют ее закавычивание.

Если вы хотите отказаться от столь навязчивого сервиса, то либо вы (в той редкой и счастливой ситуации, когда вы полновластный владелец сервера) в файле php.ini отключаете эти конфигурационные переменные, либо (если вы, конечно, не размещаете сайт на бесплатном хостинге) вы можете внести изменения в файл.htaccess. Это файл, в котором находятся локальные - для одного каталога, а не для всего сервера - настройки apache. И добавьте в него следующие строки.

Друзья!
Мы находимся в процессе большой чистки!
Возможны ошибки и кривизна страниц
Просмотреть всё и быстро не возможно!
Если нашли какую-то ошибку, то если вам не трудно напишите адрес...
Сейчас вы здесь:

http://сайт/page/php/039_php_kavyichki.html

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

Сегодня займёмся кавычками, но не простыми, а кавычками в PHP и плюс экранирование кавычек, варианты.

Начнем с того, что в PHP допускается применение и двойных кавычек и одинарных.

И есть несколько вариантов экранирования кавычек.

Где располагаются кавычки на клавиатуре?

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

буква Э – строчная:

и прописана буква э – это одинарные кавычки:

php символ двойных и одинарных кавычек

Естественно, что вам потребуется символ кавычек, т.е. если вам нужно вывести кавычку, но чтобы она не срабатывала, для этого и существуют символы кавычек.

Символ двойных кавычек:

"

Символ одинарных кавычек:

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

Что вы собственно подразумеваете под словами экранирование кавычек в php.

Давайте разберем пример, ведь на примерах всегда легче понять о чем идет речь!

Давайте напишем код php:

echo "Кавычки php ";

Но если мы вставим данный код сюда, то боюсь, что вы никогда бы не увидели данные строчки!?

Почему? Да просто потому, что код не сработает.

Специально для вас сделал , с вставленным в неё данным кодом, и если хотите то вы можете посмотреть, что из этого у вас получилось бы!

Почему такое произошло?

Потому что внутри echo появились дополнительные кавычки, которые воспринимаются как код php и если их становится больше чем положено, то и получается ошибка!

Что делать в таком случае!?

Нужно заменить двойные кавычки на одинарные.

Давайте возьмем этот же код и поменяем дойные кавычки на одинарные.

echo ‘"Кавычки php "’;

Смотрим, что у нас получилось!

Т.е. мы взяли верхний код и вставили прямо на эту страницу и вот получился вывод:

2. Второй вариант экранирования кавычек. Бывают такие ситуации, что использование одинарных кавычек невозможно!

Для такого случай используется наклонный на лево слеш. Перед каждым элементом, который нужно экранировать нужно ставить такой слеш.

Давайте возьмем предыдущую запись и сделаем все тоже самое, только с использованием слеша:

echo "Кавычки php ";

Смотрим результат:

Как вывести кавычки.

Для того, чтобы вывести кавычки на экран, и чтобы они не являлись кодом php – как бы странно это не звучало! Кавычки нужно поменять на html сущности, например:

Одинарная кавычка через html код::

" - одинарная кавычка « " »

Двойная кавычка через html код:

" - двойная кавычка « " »

Такая кавычка будет выглядеть как кавычка на экране, но в коде Php уже участвовать не будет…

И ещё!

Ко всему коду PHP надо относиться внимательно! Если вы к примеру писали что-то в программе Word, какой-то текст, потом, в нем же начали делать код, как получилось у меня в первый раз.

И я никак не мог понять в чем проблема – он реально мне не хотел показывать простой код. Я готов был сломать комп кувалдой!!!

А оказалась, что кавычки в редакторе кода отличаются от Word. И это никак невозможно понять, если вы через это не прошли!

Слеш, от английского slash - обратная косая черта, которая непонятным образом вдруг сама собой появляется в Ваших данных. Добавляется он к некоторым спецсимволам, но в основном его используют для расстановки кавычек. Слеш нужен только при работе с базой данных. Причем нужен обязательно. Во всех остальных случаях он только мешает. Сейчас мы рассмотрим оба случая, и научимся писать программы, не зависящие от настроек PHP.

За автоматическое добавление слешей отвечают директивы php.ini

magic_quotes_gpc
magic_quotes_runtime

Первая - если включена - автоматически добавляет слеши к данным пришедшим от пользователя - из POST, GET запросов и кук. Вторая - от полученных во время исполнения скрипта - например, из файла. Но не всегда есть доступ к настройкам PHP, особенно если программа пишется для распространения.

Для Вашей же безопасности прочтите ВЕСЬ текст, независимо от Вашего случая.

1. Если Вы работаете БЕЗ базы данных
Это значит, что автоматическое добавление слешей Вам не нужно. Если PHP добавил, то нужно избавиться.

Проверить, добавил ли PHP, можно с помощью функции get_magic_quotes_gpc().
Удаляет слеши функция stripslashes().
Теперь нам осталось только проверить, и если PHP добавил, то перебрать все переменные в скрипте, и удалить слеши. Сделать это можно одной функцией, с помощью массива $GLOBALS, содержащего все переменные, имеющиеся в скрипте:

if (get_magic_quotes_gpc()) strips($GLOBALS);

function strips(&$el) {
if (is_array($el)) {
foreach($el as $k=>$v) {
if($k!="GLOBALS") {
strips($el[$k]);
}
}
} else {
$el = stripslashes($el);
}
}

Слеши будут удалены как из глобальных массивов, так и из всех переменных, которые образуются при register_globals=on.

Здесь надо сделать небольшое отступление. Перебор массива $GLOBALS требуется только в том случае, если у вас включена register_globals, и Вы пользуетесь переменными, автоматически назначенными значениям, переданным в скрипт. Если Вы ими не пользуетесь, то достаточно убрать слеши из нужных массивов -
$_POST, $_GET и так далее.

Чтобы избавиться от добавления слешей при получении данных из файла, достаточно в начале скрипта написать:

set_magic_quotes_runtime(0);

2. Если Вы работаете с MySQL
Два основных правила составления запросов в mysql:

• Во всех переменных должны быть экранированы слешами спецсимволы.
  Важное замечание. Добавленные слеши НЕ идут в базу. Они нужны только в запросе.
  При попадании в базу слеши отбрасываются. Соответственно, распространенной
  ошибкой является применение stripslashes при получении данных из базы.


• Все строковые переменные должны быть заключены в кавычки (одинарные или двойные, но удобнее и чаще используются одинарные). Для простоты можно заключать в кавычки и числовые переменные - mysql сам преобразует их к нужному виду. То есть, для надежности, любые данные, вставляемые в запрос, надо заключать в кавычки. Сделать просто addslashes() будет неправильно. А вдруг PHP сам добавил уже? Это надо проверить. Для этого служит функция get_magic_quotes_gpc().
  Если данные пришли из браузера пользователя методом GET или POST, то надо писать так:
  
  

  if (!get_magic_quotes_gpc()) $var=addslashes($var);

  
  
  Если данные берутся из файла (что бывает редко, но все же), то
  
  

  if (!get_magic_quotes_runtime()) $var=addslashes($var);

  
  
  Но, что интересно. Специально для mysql в последних версиях PHP появилась функция mysql_escape_string(), которая экранирует на один символ больше, чем addslashes. Наверное, есть смысл пользоваться именно ей.
  Если у Вас есть специальная функция для составления запросов, то экранирование можно вставить в нее. Если нет, то можно воспользоваться такой функцией:

function adds(&$el,$level=0) {
if (is_array($el)) {
foreach($el as $k=>$v) adds($el[$k],$level+1);
} else {
$el = addslashes($el);
if (!$level) return $el;
}
}

Эта функция используется двояко.
Если параметром указать строку, то функция вернет ее с экранированными спецсимволами.
Удобно для вставления в запрос, вида

"SELECT * FROM table WHERE name="".adds($name).""";

Если же параметром будет массив, то функция ничего не возвратит, а просто "прослешит" рекурсивно все его элементы. Например, adds($_POST); выполнит обычную работу magic_quotes для этого массива.

Следует обратить внимание, что ни одна из функций, добавляющих слеши, не добавляет их к метасимволам поиска "%" и "_", используемым в операторе LIKE. Поэтому, если вы используете этот оператор, добавляйте слеши вручную.

$data=preg_replace("/(%|_)/","\\\\\1",$data);

Правила экранирования могут отличаться для других СУБД.

Примечание:.
При выводе value в тегах input форм, слеши не помогают. Чтобы текст в таком поле выводился целиком, надо value заключать в кавычки, а к выводимым данным применять функцию htmlspecialchars.
Пример:

Результат:

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

Во втором варианте (с одинарными кавычками) как вы уже знаете – PHP интерпретатор даже не пытался найти переменных в строке, а потому экранирование не потребовалось.

Спецсимволы в PHP

Специально для читателей блога Site on! я подготовил небольшой список специальных символов в языке программирования PHP:

• \n новая строка
• \r возврат каретки
• \t горизонтальная табуляция
• \\ обратная косая черта (обратный слеш)
• \$ знак доллара
• \" двойная кавычка

Посмотрим на работу спецсимволов на примере \n – спецсимвол, который делает перевод на новую строку (как Энтер), однако браузеры не понимают (и не должны) его и игнорируют, но результат его работы можно посмотреть в исходном коде страницы:

Результат:

Исходный код (Ctrl + U):

Если для посетителей в браузере спецсимвол \n никак не отображается, тогда в чём его смысл?

Во-первых, с помощью спецсимволов и \n в частности можно удобно форматировать код на странице (как в примере выше).

Во-вторых, \n можно использовать, например, при операциях записи в файл, чтобы сделать перенос (Энтер) и продолжить запись на новой строке.

Альтернативой такого форматирования является .

Синтаксис heredoc в PHP

Результат:

Исходный код (Ctrl + U):

Результат говорит сам за себя, теперь давайте разберемся, как же всё устроено:

• Строка начинается с трёх угловых скобочек