Экономический университет – Варна

КУРСОВАЯ РАБОТА

по дисциплине «Безопасность и защита Microsoft сетей и приложений»

Защита и безопасность веб-приложений

Студент А.Н. Долганов

Руководитель Стефан Дражев

Болгария, Варна

2015

УЯЗВИМЫЕ МЕСТА В ЗАЩИТЕ ВЕБ-ПРИЛОЖЕНИЙ

Популярность Web-приложений и постоянные проблемы, связанные с

их защитой, привели к появлению целой индустрии, работающей, прежде

всего, над вопросами защиты Web, а также над проблемами методологий

открытых исходников и технических описаний как потенциальных средств

атаки и защиты. В частности, организация Open Source Web Application

Security Project (OWASP) постоянно работает в области безопасности Web-

приложений и публикует непрерывно обновляемый список из 10 наиболее

распространенных уязвимых мест в защите. В приведенном ниже списке

перечислены 10 таких уязвимых мест:

1. Неподтвержденный ввод данных

Информация из запросов не подтверждается перед использованием в

Web-приложении. Хакеры могут использовать эти дефекты для атаки

внутренних компонентов системы через Web-приложение.

2. Управление взломанным доступом

Не существует ограничений на доступ аутентифицированных

пользователей. Злоумышленники могут использовать эти слабые места для

получения доступа к учетным записям других пользователей и просмотра

важных файлов или применения неавторизованных функций.

3. Управление аутентификацией и сессией

Мандаты доступа и сессионные маркеры не защищены надлежащим

образом. Злоумышленники, взламывая пароли, ключи, фрагменты

сессионных данных и другие маркеры, могут обойти ограничения

аутентификации и войти в систему под видом других пользователей.

4. Межсайтовые сценарии (Cross-site scripting)

Web-приложение может использоваться как механизм для перенесения

атаки на браузер конечного пользователя. Злоумышленник может определить

сессионный маркер конечного пользователя, атаковать локальную машину

или заменить содержимое для неопытного пользователя.

5. Переполнение буфера

В некоторых языках программирования компоненты Web-приложения,

не подтверждающие соответствующим образом ввод данных, могут

использоваться злоумышленниками для получения контроля над процессом.

Эти компоненты могут содержать Common Gateway Interface (CGI),

библиотеки, драйверы и серверные компоненты Web-приложений. Атаки,

связанные с переполнением буфера, не распространены в ASP.NET, однако с

технической точки зрения они являются слабыми местами методов

подтверждения ввода данных.

6. Вложение программного кода

Web-приложения передают параметры при получении доступа к

внешним системам или локальной операционной системе. Если

злоумышленник может внедрить в данные параметры свои команды, то

внешняя система выполнит эти команды от имени Web-приложения.

Злонамеренные вложения кода используют слабые места в подтверждении

ввода данных.

7. Неправильная обработка ошибок

Неправильно обрабатываются ошибочные условия, возникающие во

время выполнения стандартных операций. Если злоумышленник вызовет

ошибки, которые Web-приложение не в состоянии обработать, он сможет

получить подробную информацию о системе, отключить службы, вызвать

сбой механизмов зашиты сервера.

8. Незащищенное хранилище

Для защиты информации и учетных записей Web-приложения часто

используют функции криптографии. Такие функции и код для их интеграции

довольно сложно запрограммировать должным образом, что приводит к

ослаблению защиты.

9. Отказ в обслуживании приложения

Если злоумышленники полностью используют ресурсы Web-

приложения, то законные пользователи не могут получить доступ к нему.

Кроме того, злоумышленники могут блокировать учетные записи

пользователей и даже вызвать аварийный сбой всего приложения.

10. Незащищенное управление конфигурацией

Наличие жестких стандартов конфигурации сервера очень важно для

защиты Web-приложения. Многие опции конфигурации серверов влияют на

защиту и требуют настройки.

ОСНОВНЫЕ ПРИНЦИПЫ ВЫЖИВАНИЯ

Решая различные специфические проблемы, всегда следует помнить об

основных принципах проектирования и реализации приложений. Эти

принципы не зависят от технологий и применяются к каждой части системы.

1. Защита

Защита является столь же важной характеристикой приложения, как и

производительность или, скажем, пользовательские интерфейсы. Функции

защиты проектируются согласно определенным требованиям. Это означает,

что защита и тестирование защитных функций внедряются во время

жизненного цикла разработки приложения.

В реализации защитных функций приложения наиболее важно

определить потенциальные проблемы безопасности и уязвимые места,

нуждающиеся в защите. Весьма эффективным методом решения этих

проблем является моделирование угроз. После профилактического

моделирования реализация контрмер представляет чисто механическую

задачу. Для визуализации доступа к приложениям и генерирования ситуаций

вместе со списком возможных атак и контрмер можно применить инструмент

Microsoft Threat Analysis and Modeling (http://msdn.microsoft.com/security/se-

curecode/threatmodeling/acetm/). Следует помнить, что обеспечение и

тестирование защиты требуют времени и денежных затрат, что обязательно

необходимо учитывать при управлении проектом.

Кроме того, на некоторых стадиях цикла разработок для проведения

испытаний на проникновение целесообразно использовать программное

обеспечение от независимых производителей.

2. Использование минимальных привилегий

Всегда проектируйте свои приложения так, чтобы они корректно

работали со стандартными учетными записями. Использование учетных

записей с высокими привилегиями для запуска Web-приложений считается

плохим тоном программирования. Ведь Web-приложения являются

непосредственными мишенями для атак, и при захвате контроля над

приложением злоумышленник обычно получает такие же привилегии, с

какими было запущено приложение. Вам вряд ли понравится, если хакер

сразу получит привилегии Administrator или System.

Довольно часто возникают ситуации, когда для работы с различными

частями приложения требуется использовать разные привилегии. Однако вы

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

использованием определенного коммуникационного канала между

интерфейсной частью и кодом. Данный метод является более безопасным,

чем запуск целого приложения с высокими привилегиями.

3. Предупреждение, обнаружение и реагирование

Система защиты складывается не только из контрмер (то есть одной

только защиты). В нее следует еще добавить механизмы для обнаружения

атак и внедрить стратегию реагирования.

4. Создание уровней защиты

Обычно Web-приложение является последней преградой между

пользователями (или злоумышленниками) и внутренними ресурсами, такими,

например, как корпоративная база данных. Вам следует обязательно

продумать защиту внутренних систем.

Хорошим примером того, как можно подтвердить ввод данных,

является работа некоторых встроенных служб ASP.NET, предназначенных

для фильтрации злонамеренных данных. Однако в этом случае всегда

следует применять дополнительные функции подтверждения ввода данных, а

также задавать ограничения ввода в базы данных, используя типы данных,

ограничения по длине и т. д.

5. Некорректный ввод данных

При компиляции приложения неизвестно, какие данные будут в него

вводиться. Во время работы приложение получает данные из различных

источников, в том числе от пользователей из баз данных и файлов

конфигурации. Если приложение полагается на корректность функций ввода

данных, вам следует обеспечить гарантии того, что ввод некорректных

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

данных.

6. Виды отказов

Обычно разработчики основное внимание уделяют функциональности.

Злоумышленники же больше интересуются состояниями ошибок.

Вспомните, сколько было протестировано в процентном соотношении

обработчиков ошибок и блоков catch в вашем последнем проекте? Больше

пятидесяти процентов? Очень сложно полностью протестировать каждое

состояние ошибки. Тестирование элементов в комбинации с областью

действия кода обеспечивает эффективный метод автоматизации испытаний и

уменьшает вероятность того, что вы забудете выполнить какой-то важный

тест или проверить условие.

Следует внимательно относиться к каждому проявлению ошибки и

предоставлять информацию о ней пользователям. Сообщения об ошибках

могут быть представлены пользователям в виде каких-то общих фраз, но для

себя всегда нужно записывать в журнал подробную информацию об ошибке.

7. Отказы в обслуживании

По традиции атаки DoS (Denial of Service) являются сетевыми. Тем не

менее вы также можете невольно стать инициаторами таких атак в своих

приложениях. Типичные примеры атак DoS — автоматические блокировки

неудачных попыток регистрации, особенно когда не обеспечен механизм

автоматического снятия блокировок. Примером может служить и хранение

данных и сессионном состоянии ASP.NET для каждого анонимного

подключения. Злоумышленник может легко создать множество подключений

к сайту (хотя бы путем использования вымышленных IP-адресов), чтобы

вызвать переполнение памяти.

8. Настройки защиты по умолчанию

Если вы создаете приложение, которое будет инсталлироваться

другими пользователями, постарайтесь протестировать настройки защиты по

умолчанию. Вы должны иметь в килу, что позиция защиты будет гораздо

сильнее, если тот, кто устанавливает приложение, выберет новый пароль

вместо используемого по умолчанию. Если ваше приложение содержит

опциональные разделы, не инсталлируйте их по умолчанию, поскольку они

могут быть не так тщательно протестированы в отличие от

функциональности ядра - в таком случае они станут невыполняемыми

участками программы на сервере.

9. Использование криптографии

Один из наиболее распространенных мифов о защите заключается в

нелепых сказках о том, что криптографии гарантирует безопасность. Фраза

"У нас все защищено, потому что зашифровано" у опытного взломщика

может вызвать смех. Сама по себе криптография не обеспечивает защиты —

ее всегда следует использовать в комбинации с другими факторами.

Например, необходимо учитывать следующее:

какой алгоритм используется для криптографии;

как генерируются ключи;

используются ли пароли с низкой энтропией;

как хранятся и передаются пароли;

как часто изменяются пароли.

10. Использование брандмауэра

Брандмауэры – это средства, препятствующие проникновению в

разделы сети, доступ к которым запрещен. Ваши приложения должны быть

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

защите приложения?

Брандмауэры могут снизить фронт атак на уровне серверов и сетей,

однако не разрешают проблем, связанных с защитой приложений.

Несмотря на то, что никаких новых типов атак Web-приложений в

последнее время открыто не было, настораживает сам факт возможности

таких атак. Перемещение приложений из внутренних селей в Интернет

всегда привлекает внимание злоумышленников, которые пытаются найти

уязвимые места в коде. Поэтому следует больше уделять внимания защите

таких приложений. Всегда следуйте главным принципам, перечисленным в

этой главе, и применяйте их в своей работе.

ПРОЕКТИРОВАНИЕ ВЕБ-ПРИЛОЖЕНИЙ

Веб-трафик и веб-приложения — тесно связанные вещи: если

приложение написано неправильно, его можно легко взломать. Безопасное

приложение — это не результат защиты внешними средствами: оно

появляется как результат правильного подхода к написанию кода. Если

приложение разработано группой разрозненных программистов, часть

которых находится в Индии, часть — в Китае и так далее, то высока

вероятность, что вопросы безопасности не решаются в комплексе с самого

начального этапа, и на выходе приложение будет представлять собой шаткую

конструкцию.

Как оценить правильность написания приложения? Единственный на

текущий момент способ — это сделать тест (например, скан), который

показывает все слабые и уязвимые места в приложении: где не шифруются

пароли, где возможны атаки cross-site scripting и т. д.

Серьезные ошибки веб-приложений — это оставшиеся уязвимости в

программном обеспечении. Причиной таких ошибок могут стать

использование слишком больших привилегий, неправильная реализация

шифрования, неудача в проверке входных и выходных данных, слабое

управление сессиями, неудачное исправление ошибок и проч. Неправильная

работа софта обычно происходит по причине недостаточных практик

разработки, где безопасность не является неотъемлемой частью цикла

разработки программного обеспечения. Хорошие практики

программирования значительно снижают количество уязвимостей,

порождаемых ошибками человека.

Способ, которым веб-приложение проектируется и разрабатывается,

влияет на его доступность, безопасность и на неприкосновенность данных.

Эксперты рекомендуют сервис-провайдерам, разработчикам и поставщикам

программного обеспечения, а также компаниям и клиентам, использующим

веб-приложения, относить вопросы безопасности к категории наивысшего

приоритета, в том числе с точки зрения законодательных и регуляторных

норм.

О безопасности веб-приложений специалисты советуют заботиться еще

на стадии проектирования, разработки, интеграции — и на протяжении всего

жизненного цикла приложения. «Безопасность должна стать

интегрированным компонентом приложения, а не добавляться в конце цикла

разработки, — считает Михаил Кондрашин. — За рамками проектирования и

реализации безопасность веб-приложения должна быть протестирована и

проверена перед тем, как оно запускается в продуктивный цикл или

развивается».

Если приложение написано бездумно, то ничто не мешает

пользователю написать, например, какой-нибудь хитрый запрос на

авторизацию, который всегда будет пропускать злоумышленника: ему даже

не потребуется где-то украсть пароль доступа. Это классический запрос SQL

Injection, с помощью которого можно удалить или даже выкачать всю базу.