Уязвимости технологий создания содержимого на стороне сервера
В отличие от описанных выше технологий, 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.
- ASP в отношении безопасности полагается на ОС и приложение web-сервера;
- безопасность клиента хорошо интегрируется с сервисами аутентификации web-сервера и ОС;
- ASP не поддерживает выполнение политики безопасности, тем самым, не существует метода ограничения привилегий для различных групп пользователей;
- ASP часто использует СОМ-объекты, которые могут иметь слабую безопасность.
Тем не менее, существуют определенные гарантии от переполнения буфера.
Java Servlets – сервлеты, основанные на технологии Java и являющиеся Java-программами на стороне сервера. Web-сервер первым делом определяет, требует ли запрос пользователя динамически создаваемую сервлетом информацию. Если так, web-сервер может создать экземпляр объекта сервлета, соответствующий запросу, и вызвать его для получения необходимых результатов. Web-сервер обычно сам управляет жизненным циклом своих сервлетов. Следуя возможности портирования Java и обеспечивая общий прикладной программный интерфейс, объекты сервлета могут выполняться в любом окружении сервера. Сервлеты используют объектно-ориентированное окружение на web-сервере, которое является гибким и расширяемым. Более того, недоверяемые объекты сервлета могут выполняться в безопасной области, динамически создавая информацию, которая будет передаваться из безопасной области в оставшееся окружение сервера.
Основные особенности, которые следует учитывать при использовании Java сервлетов:
хорошая интеграция с возможностями обеспечения безопасности ОС и аутентификацией web-сервера для обеспечения строгой безопасности;
возможности безопасного программирования:
возможности безопасности языка Java;
строгая модель безопасности, поддерживающая ограничения, которые вводятся разработчиками и администраторами сервера;- безопасная обработка ошибок.
PHP (Hypertext Preprocessor) – скриптовый язык, используемый для создания динамических web-страниц. Синтаксис РНР аналогичен С, Java и Perl, при этом код РНР встроен в HTML страницы для выполнения на стороне сервера.
Например, в большинстве форм возможны только такие категории данных, как буквы a-z, A-Z и цифры 0-9. Имена устройств, например, AUX, COM, LPT, NUL и PRN должны также отфильтровываться из входных данных;
гарантировать, что динамически создаваемые страницы не содержат опасных метасимволов. Нарушитель может разместить эти теги в базе данных или файле. Когда динамическая страница создается, используя измененные данные, вредоносный код, встроенный в теги, может быть передан браузеру клиента. Затем браузер клиента может быть обманут, что приведет к выполнению программы атакующего. Данная программа будет выполняться в контексте безопасности браузера для соединения не с законным web-сервером, а с атакующим;
множество символов кодировки должно быть явно установлено на каждой странице. Затем данные пользователя должны быть просканированы относительно последовательностей байтов, которые означают специальные символы для данной схемы кодирования;
каждый символ в конкретном множестве символов может быть представлен в виде числового значения. Используя это свойство, можно обойти фильтрацию данных. Такое представление становится особенно важным, когда специальные символы являются частью динамических данных. Это представление может быть достаточно трудоемким, поэтому должен соблюдаться баланс между фильтрацией числового представления и другими методами фильтрации данных;
cookies должны быть проанализированы относительно наличия любых специальных символов. Любые специальные символы должны быть отфильтрованы;
для web-приложений, которые имеют ограничения по имени пользователя и паролю, никакие web-страницы не должны быть доступны без выполнения соответствующего процесса аутентификации;
При рассмотрении генератора содержимого на стороне сервера важно просмотреть различные базы данных уязвимостей (такие как ICAT метабаза, http://icat.nist.gov) для определения возможного риска использования различных технологий.
Например, скрипт может иметь достаточно привилегий, чтобы отправить по почте файл с паролями системы, проанализировать сетевую информацию или просканировать открытые порты.
Уязвимость может потенциально воздействовать на весь 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.
- ASP в отношении безопасности полагается на ОС и приложение web-сервера;
- безопасность клиента хорошо интегрируется с сервисами аутентификации web-сервера и ОС;
- ASP не поддерживает выполнение политики безопасности, тем самым, не существует метода ограничения привилегий для различных групп пользователей;
- ASP часто использует СОМ-объекты, которые могут иметь слабую безопасность.
Тем не менее, существуют определенные гарантии от переполнения буфера.
Java Servlets – сервлеты, основанные на технологии Java и являющиеся Java-программами на стороне сервера. Web-сервер первым делом определяет, требует ли запрос пользователя динамически создаваемую сервлетом информацию. Если так, web-сервер может создать экземпляр объекта сервлета, соответствующий запросу, и вызвать его для получения необходимых результатов. Web-сервер обычно сам управляет жизненным циклом своих сервлетов. Следуя возможности портирования Java и обеспечивая общий прикладной программный интерфейс, объекты сервлета могут выполняться в любом окружении сервера. Сервлеты используют объектно-ориентированное окружение на web-сервере, которое является гибким и расширяемым. Более того, недоверяемые объекты сервлета могут выполняться в безопасной области, динамически создавая информацию, которая будет передаваться из безопасной области в оставшееся окружение сервера.
Основные особенности, которые следует учитывать при использовании Java сервлетов:
хорошая интеграция с возможностями обеспечения безопасности ОС и аутентификацией web-сервера для обеспечения строгой безопасности;
возможности безопасного программирования:
возможности безопасности языка Java;
строгая модель безопасности, поддерживающая ограничения, которые вводятся разработчиками и администраторами сервера;- безопасная обработка ошибок.
PHP (Hypertext Preprocessor) – скриптовый язык, используемый для создания динамических web-страниц. Синтаксис РНР аналогичен С, Java и Perl, при этом код РНР встроен в HTML страницы для выполнения на стороне сервера.
Например, в большинстве форм возможны только такие категории данных, как буквы a-z, A-Z и цифры 0-9. Имена устройств, например, AUX, COM, LPT, NUL и PRN должны также отфильтровываться из входных данных;
гарантировать, что динамически создаваемые страницы не содержат опасных метасимволов. Нарушитель может разместить эти теги в базе данных или файле. Когда динамическая страница создается, используя измененные данные, вредоносный код, встроенный в теги, может быть передан браузеру клиента. Затем браузер клиента может быть обманут, что приведет к выполнению программы атакующего. Данная программа будет выполняться в контексте безопасности браузера для соединения не с законным web-сервером, а с атакующим;
множество символов кодировки должно быть явно установлено на каждой странице. Затем данные пользователя должны быть просканированы относительно последовательностей байтов, которые означают специальные символы для данной схемы кодирования;
каждый символ в конкретном множестве символов может быть представлен в виде числового значения. Используя это свойство, можно обойти фильтрацию данных. Такое представление становится особенно важным, когда специальные символы являются частью динамических данных. Это представление может быть достаточно трудоемким, поэтому должен соблюдаться баланс между фильтрацией числового представления и другими методами фильтрации данных;
cookies должны быть проанализированы относительно наличия любых специальных символов. Любые специальные символы должны быть отфильтрованы;
для web-приложений, которые имеют ограничения по имени пользователя и паролю, никакие web-страницы не должны быть доступны без выполнения соответствующего процесса аутентификации;
При рассмотрении генератора содержимого на стороне сервера важно просмотреть различные базы данных уязвимостей (такие как ICAT метабаза, http://icat.nist.gov) для определения возможного риска использования различных технологий.
