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

Теоретически ограничение языка  скрипта границами web-браузера должно обеспечивать относительно безопасное окружение. На практике это выполняется не во всех случаях. Многие основанные на браузерах атаки используют скриптовый язык в сочетании с конкретной уязвимостью безопасности. Основной источник проблем двойной: существование изъянов в реализации в выполняемом окружении и скрытое связывание браузера с соответствующей функциональностью, такой, как клиент e-mail. Подобные внедрения включают посылку списка истории URL на удаленный сайт и использование e-mail адреса пользователя для подделки почты. Возрастающее использование HTML и других языков разметки в качестве содержимого электронной почты и в сервисах push-технологий может открыть новые бреши для внедрения ошибок с использованием встроенных скриптов.

Visual Basic Script (VBScript) – язык программирования, разработанный Microsoft для создания скриптов, которые могут быть встроены в web-страницы, просматриваемые с помощью браузера IE. Netscape Navigator, однако, не поддерживает VBScript. ПодобноJavaScript, VBScript является интерпретируемым языком, который дает возможность обрабатывать скрипты на стороне клиента. VBScript, который является подмножеством широко используемого Microsoft языка программирования Visual Basic, работает под управлением Microsoft ActiveX. Язык подобен JavaScript и имеет аналогичные риски.

ActiveX – это множество технологий от Microsoft, которые предоставляют инструментальные средства для связывания desktop-приложений с web. Управления ActiveX являются переиспользуемыми программными компонентными объектами, которые могут быть присоединены к e-mail или быть загруженными с web-сайта. Управления ActiveX также могут быть заранее инсталлированы на Windows-платформе. Web-страницы включают управления ActiveX, используя скриптовый язык или с помощью HTML-тега OBJECT.

Модель безопасности ActiveX значительно отличается от модели sandbox Java. Модель Java ограничивает апплет множеством безопасных действий. В противоположность этому, ActiveX не имеет ограничений на то, что он может делать. Вместо этого управляющие элементы ActiveX имеют цифровую подпись своего автора в соответствии с технологией, называемой Authenticcode. Цифровые подписи проверяются, используя сертификаты, выпущенные доверенными сертификационными центрами. Сертификационный центр должен гарантировать, что никакого опасного кода не будет сознательно распространено. Технология Authenticcode гарантирует, что управления ActiveX не могут быть распространены анонимно и что модификация управления может быть определена. Такой процесс сертификации, однако, не гарантирует, что поведение управления будет корректным.

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

Рассмотрим риск ActiveX в сравнении с другими популярными технологиями активного содержимого на стороне клиента.

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

В отличие от описанных  выше технологий, 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-серверов инсталлируют примеры скриптов или выполняемых программ. Многие из них имеют известные уязвимости и должны быть немедленно удалены.