Программист должен литерализовать все данные, обрабатываемые кодом Web-приложения. Литерализация означает изменение текста или других данных, получаемых из ненадежного источника — например, комментария, добавленного посетителем вашего Web-сайта — во избежание нежелательных побочных эффектов при обработке таких данных вашим приложением.
Проверка и литерализация входных данных — вполне обычная мера предосторожности, но в настоящее время большинство разработчиков заботятся об этом только в контексте SQL. Большинство опытных Web-разработчиков знают о необходимости литерализации или очистки данных, посылаемых в базу данных SQL. В противном случае специально подобранные входные данные могут сформировать вредоносный запрос, который способен похитить и/или запортить данные. Но, несмотря на это, многие программисты забывают выполнять литерализацию входных данных при работе с SQL, и еще больше программистов забывают делать все это в HTML.
Такая апатия повлияла даже на терминологию. Для SQL имеется РНР-функция,
выполняющая "литерализацию" (escape) — mysql_real_escape_string (), но РНРфункция для HTML "преобразовывает специальные символы" (convert special characters) — htmlspecialchars() или htmlentities().
В документации по mysql_real_escape_string () говорится, что "эта функции
должна применяться всегда (за несколькими исключениями) для обеспечения безопасности данных перед посылкой запроса в MySQL".
Но ни на одной из страниц документации по функциям литерализации для HTML
не написано ничего похожего на текст "Вы должны литерализовать текст, получаемый от пользователей, иначе найдутся умники, которые с помощью специально подобранных параметров смогут поместить на ваш сайт текст или ссылку на что-то совершенно неэтичное". Конечно, ваш сайт может также оказывать поддержку другим сайтам, которые используют странные, но не вызывающие особых подозрений средства. Но в любом случае вам, конечно, следует застраховаться, чтобы не стать невольным пособником злоумышленников.
Мы просим обратить самое серьезное внимание: это проблема) которая в основном игнорируется.
Вам следует устранить на своих сайтах все уязвимости, или однажды вам придется
устранить их. >Сейчас мы приведем пример кода до и после правильной литерализации. Сначала версия, в которой не применяется должная техника литерализации:
<?php
//не пробуйте этого дома
echo 'По вашему запросу об ' .
$_GET['parameter'] .
' ничего не найдено. ' ;
?>
А вот вариант с правильной литерализацией входных данных:
<?php
// правильная техника литерализации
echo 'По вашему запросу об ' .
htmlspecialchars($_GET['parameter']) .
1
ничего не найдено.';
?>
Разница будет продемонстрирована в следующем коротком упражнении.
Во всех упражнениях предполагается, что ваша машина сконфигурирована так как описано в главе 1. Обновления* связанные с этим кодом, можно найти по адресу http://seoegghead.com/seo-with-php-updates.html.
Литерализация входных данных
1. Создайте в папке seophp сценарий с именем param_no_escape .php и введите в
него следующий код:
<?php
//не пробуйте этого дома
echo 'По вашему запросу об ' .
$_6ЕТ['parameter'] .
' ничего не найдено. ' ;
?>
2. Создайте еще один сценарий, с именем paramescape .php, и введите в него следующий
код:
<?PHP
//
ПРАВИЛЬНАЯ ТЕХНИКА ЛИТЕРАЛИЗАЦИИ
ECHO 'ПО ВАШЕМУ ЗАПРОСУ ОБ ' .
HTMLSPECIALCHARS($_GET['PARAMETER']) .
НИЧЕГО НЕ НАЙДЕНО. ' ;
?>
3. Введите в адресную строку браузера текст http: / /seophp. example. com/param_
no_escape.php?parameter=cnaM спам спам.
Ваш такой симпатичный, но уязвимый сценарий спокойно принимает параметр
и преобразовывает его в HTML-ссылку. Теперь у вас появилась ссылка на сайт
http: //too .much. spam, как показано на рис. 8.3.
4.
Теперь загрузите с этим же параметром другой сценарий — param_escape.php.
В адресную строку будет занесен текст http://seophp.example.com/param_
escape.php?parameter=spam spam spam,
а результат работы сценария показан на рис. 8.4.
ПО ВАШЕМУ ЗАПРОСУ О <А BRE.=HTT)>:'LOO JBUCH.5PAM>CNAU СПАМ СПАМ<^А> НИЧЕГО НЕ НАЙДЕНО
Рис. 8.4. Результат работы сценария param_escape. php
Литерализация оказалась полезной, не так ли? Конечно, лучше бы никто не посылал на ваш Web-сайт ничего подобного, независимо от того, выполняется ли обработка входных данных. Однако литерализация данных очень полезна по трем описанным ниже причинам.
• Тщательная литерализация данных вообще значительно снижает вероятность
причинения вреда при дальнейшей обработке этих данных в вашем сценарии.
Кроме того, она выполняет и функции защиты, предотвращая атаки межсайтовыми
сценариями.
• Вы не размещает бесплатные ссылки на сайты спамеров.
• У спамеров не будет желания тратить время на ваш сайт.