Популярность Web-приложений и постоянные проблемы, связанные с их защитой, привели к появлению целой индустрии, работающей, прежде всего, над вопросами защиты Web, а также над проблемами методологий открытых исходников и технических описаний как потенциальных средств атаки и защиты. В частности, организация Open Source Web Application Security Project (OWASP) постоянно работает в области безопасности Web-приложений и публикует непрерывно обновляемый список из 10 наиболее распространенных уязвимых мест в защите. В приведенном ниже списке перечислены 10 таких уязвимых мест:
Решая различные специфические проблемы, всегда следует помнить об основных принципах проектирования и реализации приложений. Эти принципы не зависят от технологий и применяются к каждой части системы.
Защита является столь же важной характеристикой приложения, как и производительность или, скажем, пользовательские интерфейсы. Функции защиты проектируются согласно определенным требованиям. Это означает, что зашита и тестирование защитных функций внедряются во время жизненного цикла разработки приложения.
В реализации защитных функций приложения наиболее важно определить потенциальные проблемы безопасности и уязвимые места, нуждающиеся в защите. Весьма эффективным методом решения этих проблем является моделирование угроз. После профилактического моделирования реализация контрмер представляет чисто механическую задачу. Для визуализации доступа к приложениям и генерирования ситуаций вместе со списком возможных атак и контрмер можно применить инструмент Microsoft Threat Analysis and Modeling (http://msdn.microsoft.com/security/se-curecode/threatmodeling/acetm/). Следует помнить, что обеспечение и тестирование защиты требуют времени и денежных затрат, что обязательно необходимо учитывать при управлении проектом.
Кроме того, на некоторых стадиях цикла разработок для проведения испытаний на проникновение целесообразно использовать программное обеспечение от независимых производителей.
Всегда проектируйте свои приложения так, чтобы они корректно работали со стандартными учетными записями. Использование учетных записей с высокими привилегиями для запуска Web-приложений считается плохим тоном программирования. Ведь Web-приложения являются непосредственными мишенями для атак, и при захвате контроля над приложением злоумышленник обычно получает такие же привилегии, с какими было запущено приложение. Вам вряд ли понравится, если хакер сразу получит привилегии Administrator или System.
Довольно часто возникают ситуации, когда для работы с различными частями приложения требуется использовать разные привилегии. Однако вы можете разделять эти части и запускать их в отдельных процессах с использованием определенного коммуникационного канала между интерфейсной частью и кодом. Данный метод является более безопасным, чем запуск целого приложения с высокими привилегиями.
Система защиты складывается не только из контрмер (то есть одной только защиты). В нее следует еше добавить механизмы для обнаружения атак и внедрить стратегию реагирования.
Обычно Web-ириложение является последней преградой между пользователями (или злоумышленниками) и внутренними ресурсами, такими, например, как корпоративная база данных. Вам следует обязательно продумать защиту внутренних систем.
Хорошим примером того, как можно подтвердить ввод данных, является работа некоторых встроенных служб ASP.NET, предназначенных для фильтрации злонамеренных данных. Однако в этом случае всегда следует применять дополнительные функции подтверждения ввода данных, а также задавать ограничения ввода в базы данных, используя типы данных, ограничения по длине и т. л.
При компиляции приложения неизвестно, какие данные будут в него вводиться. Во время работы приложение получаст данные из различных источников, в том числе от пользователей из баз данных и файлов конфигурации. Если приложение полагается на корректность функций ввода данных, вам следует обеспечить гарантии того, что ввод некорректных данных не вызовет сбоя в работе приложения независимо от источника этих данных.
Обычно разработчики основное внимание уделяют функциональности. Злоумышленники же больше интересуются состояниями ошибок.
Вспомните, сколько было протестировано в процентном соотношении обработчиков ошибок и блоков catch в вашем последнем проекте? Больше пятидесяти процентов? Очень сложно полностью протестировать каждое состояние ошибки. Тестирование элементов в комбинации с областью действия кода обеспечивает эффективный метод автоматизации испытаний и уменьшает вероятность того, что вы забудете выполнить какой-то важный тест или проверить условие.
Следует внимательно относиться к каждому проявлению ошибки и предоставлять информацию о ней пользователям. Сообщения об ошибках могут быть представлены пользователям в виде каких-то общих фраз, но для себя всегда нужно записывать в журнал подробную информацию об ошибке.
По традиции атаки DoS (Denial of Service) являются сетевыми. Тем не менее вы также можете невольно стать инициаторами таких атак в своих приложениях. Типичные примеры атак DoS — автоматические блокировки неудачных попыток регистрации, особенно когда не обеспечен механизм автоматического снятия блокировок. Примером может служить и хранение данных и сессионном состоянии ASP.NET для каждого анонимного подключения. Злоумышленник может легко создать множество подключений к сайту (хотя бы путем использования вымышленных IP-адресов), чтобы вызвать переполнение памяти.
Если вы создаете приложение, которое будет инсталлироваться другими пользователями, постарайтесь протестировать настройки защиты по умолчанию. Вы должны иметь в килу, что позиция зашиты будет гораздо сильнее, если тот, кто устанавливает приложение выберет новый пароль, вместо используемого по умолчанию. Если ваше приложение содержит опциональные разделы, не инсталлируйте их по умолчанию, поскольку они могут быть не так тщательно протестированы в отличие от функциональности ядра - в таком случае они станут певыполняемыми участками программы на сервере.
Один из наиболее распространенных мифов о защите заключается в нелеших сказках о том, что криптографии гарантирует безопасность. Фраза "У нас все защищено, потому что зашифровано" у опытного взломщика может вызвать смех. Сама по себе криптография не обеспечивает зашиты — ее всегда следует использовать в комбинации с другими факторами. Например, необходимо учитывать следующее:
Брандмауэры — это средства, препятствующие проникновению в разделы сети, доступ к которым запрещен. Ваши приложения должны быть доступны только для избранных. Так чем же может помочь брандмауэр в защите приложения?
Брандмауэры могут снизить фронт атак на уровне серверов и сетей, однако не разрешают проблем, связанных с зашитой приложений.
Несмотря на то что никаких новых типов атак Web-приложений в последнее время открыто не было, настораживает сам факт возможности таких атак. Перемещение приложений из внутренних селей в Интернет всегда привлекает внимание злоумышленников, которые пытаются найти уязвимые места в коде. Поэтому следует больше уделять внимания защите таких приложений. Всегда следуйте главным принципам, перечисленным в этой главе, и применяйте их в своей работе.
Аутентификация - процеcc получения имени пользователя и пароля и проверка полученной информации (через AD, базу данных и т.п.). Если проверка прошла успешно, то пользователь относится к категории аутентифицировавшихся пользователей.
Авторизация - процесс определения того, какие права предоставлены пользователю на указанный ресурс. В итоге пользователю предоставляется доступ к указанному ресурсу или такой доступ запрещается.
В ASP.NET поддерживается три метода аутентификации:
При использовании аутентификации Windows при обращении пользователя к Web-странице Web-сервер запрашивает у него имя пользователя (с доменом) и парольный хэш. Полученная информация проверяется средствами Windows (на локальном компьютере или через контроллер домена).
При использовании аутентификации средствами Web-форм пользователю предоставляется форма, на которой он должен ввести свое имя и пароль. Полученная информация проверяется не средствами Windows, а средствами Web-приложения. Если все нормально, на компьютер пользователя передается специальная authentification cookie, которая в дальнейшем и удостоверяет права пользователя на доступ к страницам этого Web-приложения.
Работать через Microsoft Passport могут только доверенные партнеры Microsoft. при использовании этого метода аутентификацией занимается Web-служба Microsoft Passport.
В каких ситуациях каждый режим аутентификации используется:
При использовании аутентификации Windows вам потребуется настроить аутентификацию на уровне IIS. В IIS предусмотрено четыре режима аутентификации:
Возможность зашифровать весь обмен информацией между клиентом и Web-сервером - применение SSL.
В ASP.NET предусмотрена возможность проверить, установлено защищенное соединение или нет. Для этой цели используется проверка значения свойства Request.IsSecureConnection.