Взлом и защита PHP-скриптов

Давайте-ка, обсудим, как можно ломать PHP3-скрипты. Меня часто об этом просят. Итак, первый способ - подмена переменной. Делается это предельно просто через браузер. Допустим, нодо, что бы переменная root была равна 1. Набиваем строку http://www.xxx.com/admin.php3?$root=1 и у нас переменная root делается равной единице. Но тут есть один маленький напряг. Подменить ее таким образом можно только в том случае, если переменная передается от скрипта скрипту, а не определяется внутри самого скрипта. Следующий метод обхода авторизации заключается в следующем: большинство скриптов проверяют Ты это или не Ты, по переменной $HTTP_REFERER. Она содержит URL, откуда Ты сюда пришел.Его можно подменить без особых проблем только что описанным методом. Если пользуешься таким методом, то надо написать в строке браузера $HTTP_REFERER=адрес_с_которого_прошла_авторизация. Но на самом деле переменных типа этой есть огромная куча. Давай посмотрим как ломать все из них, которые могут помочь при авторизации. HTTP_VIA, HTTP_USER_AGENT, HTTP_X_FORWARDED_FOR, HTTP_REFERER - ломаются обычной подменой через браузер по HTTP. REMOTE_ADDR - для подмены можно использовать прокси сервер. REMOTE_PORT - вероятность того, что защияются этим, мала, но если все таки есть, то надо будет покопаться в настройках своих портов и поменять их. Или просто поставить смотрелку, использующую другой порт. HTTP_COOKIE_VARS, HTTP_GET_VARS, HTTP_POST_VARS - тоже ломаются через браузер. PHP_AUTH_USER, PHP_AUTH_PW - эти скрипты перехватывают для захвата пароля. Вот эти ломануть - уже проблема. Как их ломать сам не знаю. Есть подозрение, что методом подделки HTML-страничек с соответствующим JavaScript-кодом для вывода их на экран. Но это только подозрение. Если кто знает получше, напиши как. Хотя если используется SSL, то перехватить можно просто при использовании прокси сервера, зарегестрированого в компании, выдающей сертификаты. Тогда Тебе все само на монитор выползет. Следующий способ относится только к людям, хорошо знающим PHP. Фишка такая: "root\0"!="root". Но strcmp ("root\0", "root")==true. Так что делай выводы. Следующий способ заключается в том, что размер отсылаемой инфы не проверяется PHP3 (так же как и в Perl'е). Если отсылаемая инфа сохраняется на сервере (например, ГК, форум, регистрация и т. д.), то может возникнуть ошибка типа Out of Memory. Но это только в том случае, если максимальный размер сообщения не задан вручную. Есть еще возможность вставки PHP3-скриптов в такие поля как textarea или <input type=text>. Если на экране это будет парсится, то выполнются введенные тобой команды. Примерно такой способ я использовал в статье "Взлом московского провайдера". Только там был Perl. Откровенно говоря, из методов, которые я привел тут, реально могут помочь только метод подмена перменной и последний. Просто теоретически возможен каждый, но я еще не встречал такой защиты. На самом деле способов гораздо больше и я продолжу про них рассказывать в следующих номерах. У многих программистов, подписывающихся на рассылку возникнет вопрос: а как же тогда защищаться? Вот именно им и посвящается второй раздел статьи. Самый надежный метод - использовать $HTTP_REFERER. Что бы его не подменили надо использовать тактику перехода от одного скрипта другому. То есть логин и пароль отправляются в скрипт login.php3, который после их проверки переводит Тебя на 1.php3, на котором стоит редирект в enter.php3. $HTTP_REFERER должен равняться 1.php3. Узнать на какую страницу идет редирект невозможно, если только у него нет шелла с доступом для чтения с папке с CGI-скриптами. Но если у него есть шелл, вряд ли он будет ломать этот CGI-скрипт, ведь там уже открывается необъятное поле для эксперементов с файлами настроек. Второй способ защиты более полезен и надежен. Если логин и пароль правильный, то из файла считываются права, которыми обладает этот пользователь под этим логином и паролем в виде цифры. Потом по придуманному тобой алгоритму логин пароль и права достуа шифруфруются и заносятся в $ID. Далее этот ID передается из скрипта в скрипты, в которых происходит дешифровка и вытягивание цифры с правами. Этот способ более надежен, неломаем напрямую и разграничением прав доступа.

Защита Web-сервера

Сервер Web организации обеспечивает ее присутствие в Internet. Однако распространяемые этим сервером данные могут содержать сведения частного характера, не предназначенные для чужих глаз. К сожалению, серверы Web представляют собой лакомую приманку для злоумышленников. Широкую огласку получили случаи "нападения" на серверы Министерства юстиции и даже ЦРУ: злоумышленники подменяли домашние страницы этих организаций на непристойные карикатуры. Поборники прав животных проникли на сервер Kriegsman Furs и заменили домашнюю страницу ссылкой на узлы, посвященные защите братьев наших меньших. Схожая судьба постигла серверы Министерства юстиции США, ЦРУ, Yahoo! и Fox. Дэн Фармер, один из создателей программы SATAN, для поиска брешей в защите сетей использовал еще не завершенную официально версию своего сканера для зондирования Web-серверов Internet и установил, что почти две трети из них имеют серьезные изъяны в защите.

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

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

Лучшим выходом было бы компромиссное решение: размещение сервера Web в его собственной сети, запрет внешних соединений или ограничение доступа к внутренним серверам.

СКВОЗНОЙ ТУННЕЛЬ

Немало пользователей размещают серверы Web за брандмауэром во внутренней сети. Такая диспозиция обеспечивает простоту управления, но ценой безопасности. Кроме того, в этом случае работать с сервером защищенным образом становится намного труднее.

Вернемся на несколько лет назад, чтобы посмотреть, что может случиться, когда общедоступный сервер Web размещается во внутренней сети (см. Рисунок 1). Допустим, конфигурация брандмауэра такова, что он пропускает только трафик, предназначенный серверу Web (HTTP и, возможно, HTTPS). Если злоумышленник прощупывает сеть в поисках слабых мест, то его зонд обнаружит только порт сервиса Web, и ничего более. Посылать пакеты UDP или TCP для других служб (SMTP, telnet, ftp, finger и других) злоумышленник не может, так как они полностью блокированы. Что же еще может случиться?

Рисунок. 1.
Туннелирование HTTP через брандмауэр (пунктирная линия) позволяет установить непосредственное TCP-соединение с внутренней системой.

Первой выяснить это имела несчастье компания General Electric. В 1994 году (как назло, как раз в День Благодарения) хакер обнаружил лазейку на сервере Web компании, расположенном за брандмауэром во внутренней сети. Он послал HTTP-запрос по стандартному соединению TCP и воспользовался невыявленной ошибкой сервера Web. Исследовав систему, хакер сохранил TCP-соединение с сервером Web, однако теперь он уже мог взаимодействовать не с программным обеспечением сервера, а с интерпретатором команд.

Иными словами, изначально стандартное Web-соединение функционировало уже скорее как сеанс telnet. сервер Web теперь можно было использовать как базу для проникновения во внутрикорпоративную сеть. У хакера был удачный день - он пробрался во множество систем, и все благодаря туннелю через сервер Web, с которым брандмауэр разрешал устанавливать соединение извне.

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

ОТКРЫТЫЙ ВСЕМ ВЕТРАМ

Другая стратегия состоит в размещении сервера Web по другую сторону брандмауэра (в данном случае под брандмауэром мы понимаем шлюз приложений или брандмауэр с контекстной проверкой). Чаще всего между сервером Web и Internet по-прежнему располагается маршрутизатор, с помощью которого сервер Web можно защитить средствами фильтрации пакетов. Так что и в этом случае сервер Web не оказывается полностью беззащитным.

Достоинство такой конфигурации, безусловно, состоит в том, что, даже проникнув на сервер Web, злоумышленник все же остается по внешнюю сторону брандмауэра. При "атаке" на сервер брандмауэр ограничит доступ с сервера во внутрикорпоративную сеть (см. Рисунок 2).

Рисунок. 2.
Если сервер Web размещен по внешнюю сторону брандмауэра, он более уязвим для атак и менее удобен для администрирования.

С другой стороны, администрировать сервер Web становится намного труднее, поскольку доступ к нему оказывается в значительной мере затруднен - теперь между администратором и сервером Web находится брандмауэр. Кроме того, конфиденциальная информация оказывается как бы "за дверью" - за пределами внутренней сети. Допустим, сервер Web находился под охраной брандмауэра, и пользователи работали с ним, как с обычным сервером базы данных, и размещали на нем конфиденциальные данные, которые имеющие на то надлежащие права пользователи Web могли просматривать контролируемым образом. Теперь же сервер со всеми закрытыми данными надо вынести наружу.

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

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

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

КОМПРОМИССНЫЙ ПУТЬ

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

Рисунок. 3.
Сервер Web защищен брандмауэром; администрирование сервера Web упрощено благодаря зеркалированию.

В такой конфигурации брандмауэр пропускает из Internet на сервер только трафик HTTP (и, возможно, S/HTTP). Кроме того, он контролирует доступ сервера Web во внутреннюю сеть, ограничивая его внутренними серверами баз данных. В дополнение к этому, внутренним пользователям следует разрешить доступ к серверу Web для тестирования.

Несмотря на все достоинства, этот подход имеет свои "подводные камни". Как пользователи внутренней сети будут администрировать сервер Web? Он по-прежнему остается лакомым кусочком для злоумышленников и нуждается в очень тщательном администрировании. Если администраторы Web станут относиться к нему так же, как к внутреннему серверу, - жди неприятностей.

Общедоступные серверы Web нужно конфигурировать как неприступные хосты (форт-хосты): все ненужные службы программного обеспечения с них следует удалить. В идеале на сервере должно остаться только необходимое ПО, и ничего более. Так, систему UNIX вполне можно настроить как форт-хост: при этом она будет содержать менее 100 файлов, без учета документов и сценариев. Все прочее программное обеспечение следует удалить, а лучше вообще не устанавливать. Если вы не хотите удалять ненужное ПО, то по крайней мере блокируйте те сетевые сервисы, которые не требуются серверу Web для выполнения его непосредственных функций.

Необходимо убедиться, что сервер Web допускает удаленное администрирование. Для безопасного удаленного администрирования мы рекомендуем использовать шифруемое соединение, организовать которое можно с помощью защищенного программного обеспечения telnet или Secure Shell (SSH).

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

ДЫМ В ЗЕРКАЛАХ

Еще большей защищенности можно добиться, исключив необходимость человеческого вмешательства и автоматизировав администрирование общедоступного сервера Web. Невозможно? Это и так, и не так. Систему следует настроить таким образом, чтобы администраторы Web работали с внутренними серверами Web. Все изменения, сделанные на внутреннем сервере, затем нужно перенести на внешний, общедоступный сервер Web. В принципе, это можно сделать с помощью протокола совместного использования файлов, таких как Microsoft Server Message Block или Unix Network File System. Однако подобные протоколы не гарантируют защиты, и пользоваться ими не следует.

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

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

Нежелательно, однако, чтобы в систему было легко проникнуть изнутри. Ее по-прежнему требуется защитить от внутренних атак. Здесь мы можем предложить воспользоваться программным обеспечением контроля версий для данных на сервере Web. Оно позволяет определить, кто производил изменения, и обеспечивает возможность отката.

ЛЕГКАЯ МИШЕНЬ

Windows NT приобрела популярность в качестве платформы сервера Web (в особенности для сетей Intranet), но не по заслугам. Считается, что администрировать NT проще, чем серверы UNIX аналогичного масштаба, и это в определенной степени верно. Другие особенности серверов NT, такие как аутентификация доменов и возможности совместного использования файлов, также привлекают внимание администраторов к этой ОС. И все же, сколь бы весомыми ни были соображения в пользу выбора NT в качестве сервера Web, все они ничего не стоят по сравнению с недостатками защиты.

Большинство администраторов Web до сих пор даже не знают, каким собственно образом злоумышленники атакуют их серверы. Сообщество пользователей UNIX уже накопило достаточный опыт для противодействия нападениям и укрепления своих систем. У адептов Microsoft такого опыта пока нет. К счастью, уделив внимание нескольким вполне очевидным вещам, вы сможете избавить себя от многих серьезных проблем.

КОНТРОЛЬ ДАННЫХ

Windows NT обладает прекрасными функциональными возможностями настройки и контроля доступа к файлам и каталогам. В качестве первого шага к обеспечению безопасности сервера Web на базе NT администратору следует воспользоваться списками контроля доступа (Access Control Lists, ACL). И все же, прежде чем переходить к описанию списков, мы хотели бы пояснить, кто имеет доступ к файлам на сервере Web.

Ниже мы будем предполагать, что сервер Web представляет собой Internet Information Server (IIS) на базе NT. (Кстати, тем, кто действительно использует этот сервер, следует обязательно установить и Service Patch 3, и последние "заплатки" для IIS. Без них любой сможет прочитать исходные тексты сценариев, добавив точку [.] или символы %2е в конец имен файлов.)

IIS предоставляет три метода подтверждения прав доступа к информации Web: анонимный, базовая регистрация открытым текстом и процедура "запрос-ответ" Windows NT. Большинство серверов Internet поддерживает только анонимный доступ, который на серверах IIS по умолчанию соответствует пользовательскому бюджету IUSR-computername. При инсталляции IIS программа установки автоматически добавляет на сервер NT этот бюджет, который затем используется службами IIS FTP, а также Gopher.

⇐ Предыдущая55565758596061626364Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: