PHP-4 Эффективная работа


Уязвимые места РНР при автономной установке
Установка машины в виде модуля Apache
Безопасность файловой системы
Генерация сообщений об ошибках
Данные, вводимые пользователем
Философский взгляд на проблему
Не теряйте бдительности!

20.4. Генерация сообщений об ошибках

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

Стандартные сообщения об ошибках при выполнении PHP-программ обычно информативны только для разработчика, отлаживающего программное обеспечение: вы можете лишь получить указание на ошибку в выполнении функции «имярек», с указанием имени файла и номера строки, в которой зафиксирована ошибка. Этой информации достаточно для программиста, имеющего под рукой исходный файл, но совершенно недостаточно для взломщика. Понятно, что обычно разработчики не используют для отладки такие функции, как show_source (), highlight_string () или highlight_file(), но в «живых сайтах» вы можете столкнуться с их применением.

Впрочем, и общая информация об ошибках полезна для «пытливых умов». Предположим, например, что взломщик получил с сервера HTML-страницу, адресуемую URL с окончанием .html. Казалось бы, все очевидно: это статическая страница и с ней ничего сделать нельзя. Но грамотный злоумышленник попытается передать ей в качестве параметров какие-либо некорректные данные и, обнаружив общее сообщение об ошибке PHP-машины, поймет, что на самом деле это динамическая страница, с которой можно «поиграть».

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

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

В принципе, существуют три основных решения проблемы «болтливых» сообщений об ошибках.

  • Вы полностью отказываетесь от использования библиотечных функций и тщательно «вылизываете» весь программный код собственной разработки.
  • Вы отключаете режим генерации сообщений об ошибках из исполняемых программ. Приемлемый компромисс — перенаправить все сообщения в системный журнал сервера.
  • Вы используете библиотеку РНР для реализации своего собственного обработчика сообщений об ошибках.

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

20.5. Данные, вводимые пользователем

Наибольшая опасность при пострении WWW-систем на базе РНР проистекает не от особенностей самого языка, а от организации процесса разработки, который попросту игнорирует существование злоумышленников и возможности взлома системы. Именно поэтому вы должны всегда находить время на анализ того или иного участка кода с точки зрения возможных последствий ввода непредусмотренных программой (и разработчиком) данных,

Вот примеры безответственного подхода:
<?php
// Удаляем файл из домашнего каталога пользователя
// А может, и из чужого...
unlink ($evi\_var);

// Регистрируем результат операции
//А может, быть и нет...
fputs ($fp, $evil_var);

// Выполнение вполне тривиальной операции
// Но ею может оказаться rm -rf * ...
system ($evil_var);
exec ($evil_var);
?>

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

  • Может ли программа модифицировать, создать или удалить файлы, отличные от тех, для обработки которых она задумывалась?
  • Может ли программа корректно обработать неожиданные или неверные входные данные?
  • Можно ли использовать данную программу необычным образом, приводящим к получению неожиданных для пользователя результатов?
  • Можно ли использовать данную программу совместно с другими для получения необходимого злоумышленнику результата?
  • Все ли операции, выполняемые данной программой, действительно регистрируются (могут регистрироваться) в журнале?

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

Вы можете также рассмотреть в качестве одного из возможных направлений повышения надежности программы отключение таких установок, как register_globals, magi c_quotes и других механизмов, которые могут ввести вас в заблуждение относительно содержимого, корректности или источника данных переменных.

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

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

Полностью безопасная (абсолютно защищенная) распределенная система представляется на сегодняшний день настолько же абстрактным понятием, как и абсолютно черное тело. На практике же обычно используется подход, основанный на оценках ущерба от несанкционированного доступа, затрат на реализацию и эксплуатацию средств защиты (аутентификации, верификации и т. д.) и выгоды, получаемой при штатном использовании программно-аппаратного комплекса. Если для подтверждения значения каждого поля данных, введенного пользователем, требуется проверка сетчатки его глаза и отпечатка его пальца, по всей видимости, вам удастся достигнуть достаточно высокой степени защиты. Правда при этом вам потребуется затрачивать по полчаса на заполнение самых простых форм, что, попросту говоря, будет стимулировать пользователей к обходу столь «свирепой» системы защиты.

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

Не стоит также забывать старую народную мудрость: прочность цепи определяется прочностью ее самого слабого звена. Если вы, например, регистрируете все выполняемые пользователем операции, учитывая и анализируя время выполнения, адрес пользователя, тип операции и все прочее, но при этом проверяете личность удаленного пользователя только по значению «плюшки» на его машине, то ценность всего вашего журнала, а следовательно, и решений, принимаемых на основании содержащейся в нем информации, значительно снижается.

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

Интернет, да и ваше родное предприятие, одинаково наполнены людьми, желающими сделать себе имя и карьеру на ваших промахах. Не умея сделать ничего своими руками и головой, эти люди готовы интриговать и мешать работать другим исходя из того, что «другие еще хуже, чем Я». Не имеет значения, насколько сложна ваша система или насколько серьезные для работы организации проблемы она решает. В любом случае, выводя ее в сеть, вы неизбежно становитесь объектом нападения.

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

20.7.Не теряйте бдительности!

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

назад
далее

Сайт управляется системой uCoz