Безопасность web-содержимого

Уязвимости технологий создания содержимого на стороне сервера

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

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

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

Генераторы содержимого на стороне сервера могут создать уязвимости на сервере следующим образом:

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

Идеально, чтобы скрипты на стороне сервера ограничивали пользователей небольшим множеством хорошо определенных функциональностей и проверяли корректность длины и значений входных параметров, чтобы атакующий не мог переполнить память или заставить выполнить произвольные команды. Скрипт должен выполняться с минимальными привилегиями (не от имени администратора или root’а) для избежания компрометации всего web-сайта. Тем не менее, могут остаться потенциальные дыры безопасности, даже если приложения выполняются с минимальными привилегиями. Например, скрипт может иметь достаточно привилегий, чтобы отправить по почте файл с паролями системы, проанализировать сетевую информацию или просканировать открытые порты.

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

Common Gateway Interface ( CGI ) – CGI-скрипты определяют механизм, используемый для взаимодействия web-сайтов с базами данных и другими приложениями на стороне сервера. Существуют различные методы обработки информации на стороне сервера, такие, как Microsoft ASP для IIS-сервера, Java-сервлеты и РНР, поддерживаемые большинством web-платформ, включая Apache и IIS. Перечислим основные требования, которым должна удовлетворять лежащая в основе ОС:

• файловая система хоста должна обеспечивать безопасность для CGI-программ;
• web-сервер должен обеспечивать ограничения доступа к CGI-программам с точностью до директории;
• возможности безопасного программирования на Perl больше, чем у других языков (например, С, С++, shell).

Server Side Includes ( SSI ) – ограниченный скриптовый язык на стороне сервера, поддерживаемый большинством web-серверов. SSI предоставляет множество динамических возможностей, например, включение текущего момента времени или даты последней модификации HTML файла, и является альтернативой использованию CGI-программ для выполнения определенных функций. Когда браузер запрашивает документ со специальным типом файла, таким, как .shtml, это говорит о том, что сервер должен обработать его перед тем, как послать клиенту (web-браузеру). Команды SSI встроены в HTML комментарии (к примеру, <!--#include file="standard.html"--> ). Сервер читает файл и ищет HTML комментарии, содержащие встроенные команды SSI. Когда он находит их, он заменяет часть исходного HTML-текста выходом найденной команды. Например, команда SSI, приведенная выше ( #include file ), заменяет весь SSI-комментарий содержимым другого HTML файла. Это позволяет показать соответствующий логотип или другую статическую информацию, подготовленную в другом файле, для реализации унифицированного способа изображения во всех web-страницах. Некоторые доступные директивы дают возможность серверу выполнить произвольные системные команды и CGI-скрипты, которые могут создать нежелательные эффекты на стороне сервера. Вот некоторые проблемы, которые возникают при использовании SSI:

• безопасность SSI является очень слабой, если на сервере разрешена команда exec ;
• выполнение SSI может существенно сказаться на производительности сильно загруженных web-серверов;
• безопасность SSI сильно зависит от безопасности ОС или приложения web-сервера.

Microsoft Active Server Pages (ASP) – скриптовая технология на стороне сервера от Microsoft, аналогичная SSI, может быть использована для создания динамических и интерактивных web-приложений. ASP-страница представляет собой образец HTML, который содержит скрипты на стороне сервера, выполняющиеся, когда браузер запрашивает ресурс *.asp от web-сервера. Web-сервер обрабатывает запрошенную станицу и выполняет любые команды скрипта перед посылкой полученного результата браузеру пользователя. Поддерживаются скриптовые языки Jscript и VBScript, но могут быть включены и другие скриптовые языки, которые поддерживаются ASP-совместимым интерпретатором. Например, доступны скриптовые средства для языков PERL, REXX и Python. Скриптовые возможности могут быть расширены использованием объектов ActiveX, которые могут быть разработаны в различных языках, скажем, Visual Basic, C++, COBOL и Java. Скрипт, который включает объект ActiveX, может создать объект и передать ему необходимые входные параметры. Заметим, что ActiveX является необязательной технологией и не требуется для ASP.

Некоторые проблемы, которые следует рассмотреть при использовании ASP:

• ASP в отношении безопасности полагается на ОС и приложение web-сервера;
• безопасность клиента хорошо интегрируется с сервисами аутентификации web-сервера и ОС;
• ASP не поддерживает выполнение политики безопасности, тем самым, не существует метода ограничения привилегий для различных групп пользователей;
• ASP часто использует СОМ-объекты, которые могут иметь слабую безопасность.

Тем не менее, существуют определенные гарантии от переполнения буфера.

Java Servlets – сервлеты, основанные на технологии Java и являющиеся Java-программами на стороне сервера. Web-сервер первым делом определяет, требует ли запрос пользователя динамически создаваемую сервлетом информацию. Если так, web-сервер может создать экземпляр объекта сервлета, соответствующий запросу, и вызвать его для получения необходимых результатов. Web-сервер обычно сам управляет жизненным циклом своих сервлетов. Следуя возможности портирования Java и обеспечивая общий прикладной программный интерфейс, объекты сервлета могут выполняться в любом окружении сервера. Сервлеты используют объектно-ориентированное окружение на web-сервере, которое является гибким и расширяемым. Более того, недоверяемые объекты сервлета могут выполняться в безопасной области, динамически создавая информацию, которая будет передаваться из безопасной области в оставшееся окружение сервера.

Основные особенности, которые следует учитывать при использовании Java сервлетов:

• хорошая интеграция с возможностями обеспечения безопасности ОС и аутентификацией web-сервера для обеспечения строгой безопасности;

• возможности безопасного программирования:

  • возможности безопасности языка Java ;
  • строгая модель безопасности, поддерживающая ограничения, которые вводятся разработчиками и администраторами сервера;
  • безопасная обработка ошибок.

PHP (Hypertext Preprocessor) – скриптовый язык, используемый для создания динамических web-страниц. Синтаксис РНР аналогичен С, Java и Perl, при этом код РНР встроен в HTML страницы для выполнения на стороне сервера. РНР обычно используется для извлечения данных из базы данных и представления их на web-странице. Большинство web-серверов на Windows и Unix поддерживают данный язык, и он широко применяется вместе с базой данных MySQL. Некоторые проблемы, которые следует учитывать при разработке на РНР:

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

При анализе или написании выполняемого активного содержимого или скрипта следует рассмотреть следующие вопросы:

• гарантировать, что выполняемый код является максимально простым. Большой и сложный код с большей вероятностью будет иметь проблемы, связанные с безопасностью;
• ограничить возможность выполняемого кода читать файлы и писать в файлы. Код, который читает файлы, может непредумышленно нарушить ограничения доступа или передать чувствительную системную информацию. Код, который выполняет запись в файлы, может модифицировать повредить документы или внедрить Троянских коней;
• проанализировать взаимодействие кода с другими программами или приложениями. Например, многие CGI-скрипты посылают e-mail в ответ на ввод данных формы, открывая соединение с программой sendmail. Гарантировать, что такое взаимодействие выполняется безопасным способом;
• на Linux/Unix-хостах код должен выполняться без установленного бита suid ;
• код должен использовать полные имена пути при вызове внешних программ. Полагаться на переменную окружения PATH для определения части имени пути не рекомендуется, так как она может быть модифицирована атакующим, в результате чего может выполниться программа атакующего, которая была им вставлена в какой-либо каталог;
• web-серверы (даже если они не используют активное содержимое) должны периодически сканироваться относительно наличия уязвимостей;
• для данных формы следует определить список допустимых символов и фильтровать все остальные символы из введенных данных до того, как будет обработана форма. Например, в большинстве форм возможны только такие категории данных, как буквы a-z, A-Z и цифры 0-9. Имена устройств, например, AUX, COM, LPT, NUL и PRN должны также отфильтровываться из входных данных;
• гарантировать, что динамически создаваемые страницы не содержат опасных метасимволов. Нарушитель может разместить эти теги в базе данных или файле. Когда динамическая страница создается, используя измененные данные, вредоносный код, встроенный в теги, может быть передан браузеру клиента. Затем браузер клиента может быть обманут, что приведет к выполнению программы атакующего. Данная программа будет выполняться в контексте безопасности браузера для соединения не с законным web-сервером, а с атакующим;
• множество символов кодировки должно быть явно установлено на каждой странице. Затем данные пользователя должны быть просканированы относительно последовательностей байтов, которые означают специальные символы для данной схемы кодирования;
• каждый символ в конкретном множестве символов может быть представлен в виде числового значения. Используя это свойство, можно обойти фильтрацию данных. Такое представление становится особенно важным, когда специальные символы являются частью динамических данных. Это представление может быть достаточно трудоемким, поэтому должен соблюдаться баланс между фильтрацией числового представления и другими методами фильтрации данных;
• cookies должны быть проанализированы относительно наличия любых специальных символов. Любые специальные символы должны быть отфильтрованы;
• следует использовать шифрование для паролей, вводимых с помощью форм;
• для web-приложений, которые имеют ограничения по имени пользователя и паролю, никакие web-страницы не должны быть доступны без выполнения соответствующего процесса аутентификации;
• многие web-серверы и некоторое другое ПО web-серверов инсталлируют примеры скриптов или выполняемых программ. Многие из них имеют известные уязвимости и должны быть немедленно удалены.

При рассмотрении генератора содержимого на стороне сервера важно просмотреть различные базы данных уязвимостей (такие как ICAT метабаза, http://icat.nist.gov) для определения возможного риска использования различных технологий. Хотя история в полной мере и не отражает будущего возможного риска, на ее основе можно сделать вывод о том, какие технологии считаются более уязвимыми.

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

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

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

• Определить файлы, которым необходимо установить возможность записи. Такие файлы должны быть расположены в отдельных каталогах. Никаких файлов скриптов не должно существовать в каталогах, в которых существует возможность записи. Как пример, данные гостевой книги обычно сохраняются в простых текстовых файлах. Эти файлы должны иметь разрешения на запись для гостевых аккаунтов, чтобы иметь возможность получать их комментарии.
• Выполняемые файлы (например, .CGI, .EXE, .CMD и .PL ) разместить в отдельных каталогах. Никаких других файлов с возможностью чтения или записи не должно быть размещено в этих каталогах.
• Файлы скриптов (например, .ASP, .PHP и .PL ) разместить в отдельных каталогах.
• Включаемые файлы (например, .INC, .SHTML, .SHTM и .ASP ), создаваемые для возможности повторного использования некоторого кода, разместить в отдельных директориях. SSI по возможности не должно использоваться на публичных web-серверах. Заметим, что большинство рисков, связанных с файлами включения, состоит в возможности их выполнения. Если такую возможность выполнения запретить, то риск сильно уменьшится.