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

 

Брянская государственная  инженерно-технологическая академия

 

 

 

 

Кафедра информационных технологий

 

 

 

РГР

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

Дисциплина: Информационная безопасность

 

 

Выполнил:

 

 

 

 

 

 

 

 

Брянск 2013 

Содержание:

 

Введение3

Опубликование информации на web-сайтах 3

Обеспечение безопасности технологий создания активного  содержимого5

URLs и cookies 6

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

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

Список действий для обеспечения  безопасности web-содержимого.16

 

Введение

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

Опубликование информации на web-сайтах

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

1. Определение типа информации, которая может быть публично доступна;
2. Определение типа информации с ограниченным доступом;
3. Определение типа информации, которая не должна публиковаться в публично доступном репозитории.

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

Публичный web-сайт обычно не содержит следующую информацию:

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

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

Для гарантирования согласованного подхода  организация должна создать формальную политику и описать процесс определения  того, какая информация публикуется  на web-сервере. Во многих организациях за это отвечает офицер информационной службы (Chief Information Officer — CIO). Такой процесс должен включать следующие шаги.

1. Определить информацию, которая должна публиковаться в web.
2. Определить целевую аудиторию.
3. Определить возможные негативные последствия опубликования информации.
4. Определить, кто отвечает за создание, опубликование и сопровождение конкретной информации.
5. Создать или отформатировать информацию для опубликования в web.
6. Просмотреть информацию на предмет наличия чувствительных данных.
7. Определить соответствующий доступ и управление безопасностью.
8. Опубликовать информацию.
9. Проверить опубликованную информацию.
10. Периодически просматривать опубликованную информацию на соответствие текущим требованиям политики безопасности.

Областью web-содержимого, про которую  часто забывают, является информация, находящаяся в исходном коде HTML-страницы. Она может быть просмотрена из web-браузера использованием опции меню view source code. Разработчики часто не придают значения содержимому исходного кода их HTML страниц, даже если этот код содержит чувствительную информацию. Он может, например, содержать указатели на контактную информацию и показывать части структуры директории web-сервера. Атакующие могут проанализировать не только очевидное содержимое web-сайта, но также и исходный код; следовательно, web-администраторы должны проверять создаваемые HTML страницы своего web-сервера.

Обеспечение безопасности технологий создания активного содержимого

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

Активное содержание на стороне  клиента относится к интерактивным  элементам, обрабатываемым web-браузером. Активное содержание может представлять серьезную угрозу для конечного  пользователя. Например, оно может  выполняться на машине клиента без  явного разрешения пользователя. Существуют различные технологии создания активного содержимого. Некоторые наиболее популярные примеры включают ActiveX, Java, VBScript и JavaScript. Организации, рассматривающие разработку активного содержимого на стороне клиента, должны тщательно изучить риски для своих пользователей, так как использование активного содержания часто требует от пользователя понижения установок безопасности в своем web-браузере.

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

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

Специальная осторожность также требуется  при загрузке заранее созданных  скриптов или выполняемых файлов из Интернета. Многие web-администраторы хотят сэкономить время, загружая свободно доступный код из Интернета. Хотя удобства очевидны, риск тоже велик. Существует много примеров вредоносного кода, распространяемого данным способом. В общем случае, никакие скрипты  третьих фирм не должны быть установлены  на web-сервер до тех пор, пока код  не просмотрит доверенный эксперт.

URLs и cookies

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

URLs часто содержатся в содержимом web. Хотя эти URLs могут не показываться в браузере пользователя, они могут быть легко раскрыты просмотром исходного кода. Следовательно, никакое содержимое web-страниц не должно включать чувствительных URLs, спрятанных в исходном коде. Многие атакующие осуществляют поиск чувствительных URLs в исходном коде, которыми могут быть:

• e-mail адреса;
• картинки, используемые в качестве ссылок на другие серверы;
• непосредственные ссылки на другие серверы;
• конкретные текстовые выражения (например, userid, password, root, administrator), спрятанные в виде значения формы.

Cookie – есть небольшой блок информации, которая может быть записана на жесткий диск пользователя, когда он посещает web-сайт. Цель cookies состоит в том, чтобы позволить серверу распознать конкретный браузер и, в конечном счете, пользователя при повторном посещении данного сервера. В сущности, они добавляют состояние в НТТР-протоколе, в котором состояние отсутствует. К сожалению, cookies обычно посылаются в явном виде и хранятся в явном виде на хосте пользователя, тем самым, они уязвимы для компрометации. Существуют уязвимости, например, в некоторых версиях IE, которые позволяют нарушителю удаленно собрать все cookies без оповещения об этом самого пользователя. Следовательно, cookies никогда не должны содержать данные, которые могут быть использованы непосредственно атакующим (например, аутентификационная информация, такая, как имя пользователя, пароль).

Существует два типа cookies.

Cookies, которые являются причиной большинства проблем, называются постоянные (persistent) cookies. Эти cookies могут использоваться для отслеживания деятельности пользователя в течение всего времени и на различных web-сайтах. Наиболее общее использование постоянных cookies состоит в сохранении соответствия информации о пользователях между сессиями. Часто запрещается использование постоянных cookies на публично доступных web-сайтах.

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

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

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

Java – полнофункциональный, объектно-ориентированный язык программирования, который компилируется в платформонезависимый байт-код, выполняемый интерпретатором, называемым Java Virtual Machine (JVM). Результирующий байт-код может быть выполнен в том месте, где он был скомпилирован, или передан на другую поддерживающую Java платформу (например, передан с помощью HTML-страницы как апплет). Java используется для добавления функциональности в web-сайтах. Многие сервисы, предлагаемые популярными web-сайтами, требуют от пользователя иметь поддерживающий Java браузер. Когда web-браузер видит ссылки на Java-код, он загружает код и затем выполняет его, используя встроенную JVM.

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

Тем не менее, апплеты хоста представляют угрозы для безопасности, даже если выполняются внутри sandbox. Апплеты хоста могут использовать различными способами не предназначенные для этого системные ресурсы или могут заставить пользователя выполнить различные нежелательные действия. Примеры нежелательных действий апплетов на хосте включают DoS-атаки, подделку e-mail адресов, вторжение в частную жизнь (например, экспорт идентификации e-mail адреса и информации о платформе) и инсталлирование люков (backdoors) в систему. Так как модель безопасности Java является более сложной, пользователю может быть трудно понять ее и управлять ею. Такая ситуация может увеличить риск.

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