Десять уязвимых мест защиты

Популярность Web-приложений и постоянные проблемы, связанные с их защитой, привели к появлению целой индустрии, работающей, прежде всего, над вопросами защиты Web, а также над проблемами методологий открытых исходников и технических описаний как потенциальных средств атаки и защиты. В частности, организация Open Source Web Application Security Project (OWASP) постоянно работает в области безопасности Web-приложений и публикует непрерывно обновляемый список из 10 наиболее распространенных уязвимых мест в защите. В приведенном ниже списке перечислены 10 таких уязвимых мест:

• Неподтвержденный ввод данных Информация из запросов не подтверждается перед использованием в Web-приложении. Хакеры могут использовать эти дефекты для атаки внутренних компонентов системы через Web-приложение.
• Управление взломанным доступом Не существует ограничений на доступ аутентифицированных пользователей. Злоумышленники могут использовать эти слабые места для получения доступа к учетным записям других пользователей и просмотра важных файлов или применения неавторизованных функций.
• Управление аутентификацией и сессией Мандаты доступа и сессионные маркеры не защищены надлежащим образом. Злоумышленники, взламывая пароли, ключи, фрагменты сессионных данных и другие маркеры, могут обойти ограничения аутентификации и войти в систему под видом других пользователей.
• Межсайтовые сценарии (Cross-site scripting) Web-приложение может использоваться как механизм для перенесения атаки на браузер конечного пользователя. Злоумышленник может определить сессионный маркер конечного пользователя, атаковать локальную машину или заменить содержимое для неопытного пользователя.
• Переполнение буфера В некоторых языках программирования компоненты Web-приложения, не подтверждающие соответствующим образом ввод данных, могут использоваться злоумышленниками для получения контроля над процессом. Эти компоненты могут содержать Common Gateway Interface (CGI), библиотеки, драйверы и серверные компоненты Web-приложений. Атаки, связанные с переполнением буфера, не распространены в ASP.NET, однако с технической точки зрения они являются слабыми местами методов подтверждения ввода данных.
• Вложение программного кода Web-приложения передают параметры при получении доступа к внешним системам или локальной операционной системе. Если злоумышленник может внедрить в данные параметры свои команды, то внешняя система выполнит эти команды от имени Web -приложения. Злонамеренные вложения кода используют слабые места в подтверждении ввода данных.
• Неправильная обработка ошибок Неправильно обрабатываются ошибочные условия, возникающие во время выполнения стандартных операций. Если злоумышленник вызовет ошибки, которые Web-приложение не в состоянии обработать, он сможет получить подробную информацию о системе, отключить службы, вызвать сбой механизмов зашиты сервера.
• Незащищенное хранилище Для зашиты информации и учетных записей Wcb-приложения часто используют функции криптографии. Такие функции и код для их интеграции довольно сложно запрограммировать должным образом, что приводит к ослаблению зашиты.
• Отказ в обслуживании приложения Если злоумышленники полностью используют ресурсы Web-приложения, то законные пользователи не могут получить доступ к нему. Кроме того, злоумышленники могут блокировать учетные записи пользователей и лаже вызвать аварийный сбой всего приложения.
• Незащищенное управление конфигурацией Наличие жестких стандартов конфигурации сервера очень важно для защиты 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-приложений в последнее время открыто не было, настораживает сам факт возможности таких атак. Перемещение приложений из внутренних селей в Интернет всегда привлекает внимание злоумышленников, которые пытаются найти уязвимые места в коде. Поэтому следует больше уделять внимания защите таких приложений. Всегда следуйте главным принципам, перечисленным в этой главе, и применяйте их в своей работе.

Защита приложений ASP.NET, аутентификация и управление разрешениями, аутентификация Windows и аутентификация средствами Web-форм

Аутентификация - процеcc получения имени пользователя и пароля и проверка полученной информации (через AD, базу данных и т.п.). Если проверка прошла успешно, то пользователь относится к категории аутентифицировавшихся пользователей.

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

В ASP.NET поддерживается три метода аутентификации:

• аутентификация Windows;
• аутентификация средствами Web-форм;
• аутентификация средствами Microsoft Passport.

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

При использовании аутентификации средствами Web-форм пользователю предоставляется форма, на которой он должен ввести свое имя и пароль. Полученная информация проверяется не средствами Windows, а средствами Web-приложения. Если все нормально, на компьютер пользователя передается специальная authentification cookie, которая в дальнейшем и удостоверяет права пользователя на доступ к страницам этого Web-приложения.

Работать через Microsoft Passport могут только доверенные партнеры Microsoft. при использовании этого метода аутентификацией занимается Web-служба Microsoft Passport.

В каких ситуациях каждый режим аутентификации используется:

• Windows - как правило, только для Интранет-приложений, поскольку каждому пользователю нужно создавать учетную запись Windows.
• Web-формы - для большинства приложений, которые предназначены для доступа через Интернет;
• Microsoft Passport - требует платы и соглашения с Microsoft, поэтому большого смысла в использовании нет. Удобно, поскольку пользователь может использовать одно имя пользователя и один пароль для доступа ко многим Web-сайтам - меньше риск забыть.

При использовании аутентификации Windows вам потребуется настроить аутентификацию на уровне IIS. В IIS предусмотрено четыре режима аутентификации:

• Anonymous - пользователю не требуется предоставлять имя пользователя и пароль. Реально этот пользователь будет обладать на Web-сервере правами специальной учетной записи IUSR_имя_компьютера (можно поменять на другую учетную запись из консоли Internet Services Manager);
• Basic - имя пользователя и пароль учетной записи Windows будут передаваться на сервер практически открытым текстом. (base64 - encoded). Поддерживаются все броузеры, но такой режим небезопасен (лучше использовать только вместе с SSL).
• Digest - вместо пароля передается хэш в формате MD5. Метод защищенный и основанный на открытых стандартах, однако работает только с доменными учетными записями и только с теми. для которых установлено хранение пароля в режиме reversible encryption, поэтому малоприменимо. Работает с только с Internet Explorer версии 5.0 или более поздних.
• Integrated Windows - передается хэш Windows. Работает только с Internet Explorer. Наиболее часто используется для Интранет-приложений.

Возможность зашифровать весь обмен информацией между клиентом и Web-сервером - применение SSL.

В ASP.NET предусмотрена возможность проверить, установлено защищенное соединение или нет. Для этой цели используется проверка значения свойства Request.IsSecureConnection.