Основные методы обеспечения безопасности веб-приложений
Обновлен: Ноябрь 2007
Проблема создания безопасного веб-приложения очень обширна. Для ее рассмотрения необходимо полное понимание слабых мест в системе безопасности. Также необходимо ознакомиться с функциями обеспечения безопасности Windows, .NET Framework и ASP.NET. И, наконец, очень важно понимать способы использования этих функций безопасности для борьбы с угрозами.
Даже при отсутствии опыта обеспечения безопасности существуют основные меры обеспечения безопасности веб-приложения, которые следует предпринять. В следующем списке приводятся рекомендации по обеспечению минимального уровня безопасности, применимых к любым веб-приложениям, которые следует соблюдать.
Общие рекомендации по обеспечению безопасности веб-приложения
Запускайте приложения с наименьшими привилегиями
Выполняйте идентификацию и проверку подлинности пользователей
Защита от ввода вредоносных данных
Безопасный доступ к базам данных
Безопасные сообщения об ошибках
Безопасное хранение секретной информации
Безопасное использование файлов Cookie
Защита от атак типа "отказ в обслуживании"
.gif "Примечание")
Примечание.Более подробные рекомендации по обеспечению безопасности, позволяющие проектировать, разрабатывать, настраивать и развертывать более безопасные веб-приложения ASP.NET, см. в модулях по обеспечению безопасности на веб-узле Шаблоны и методики Майкрософт.
Общие рекомендации по обеспечению безопасности веб-приложения
Даже самые тщательно продуманные системы безопасности приложения могут быть взломаны, если злонамеренный пользователь может воспользоваться простыми способами доступа к компьютерам. Необходимо соблюдать следующие правила.
Чаще создавайте резервную копию и храните ее в физически безопасном месте.
Размещайте компьютер веб-сервера в физически безопасном месте, куда не могут попасть злоумышленники, выключайте его или забирайте с собой.
Используйте файловую систему Windows NTFS, а не FAT32. NTFS обеспечивает значительно более высокий уровень безопасности, чем FAT32. Подробные сведения см. в документации Microsoft Windows.
Компьютер веб-сервера и все компьютеры одной сети необходимо защитить с помощью надежных паролей.
Обеспечьте безопасность служб IIS. Подробнее см. сведения на веб-узле Цент безопасности TechNet.
Закройте неиспользуемые порты и отключите неиспользуемые службы.
Установите антивирусное программное обеспечение, отслеживающее входящий и исходящий трафик.
Создайте и внедрите политику, запрещающую пользователям записывать свои пароли в местах, где их легко найти.
Используйте брандмауэр. См. рекомендации на веб-узле обеспечения безопасности Майкрософт Рекомендации Майкрософт по использованию брандмауэра.
Установите последние пакеты исправлений от корпорации Майкрософт и других разработчиков. Например, на веб-узле Центр безопасности TechNet приводится список последних бюллетеней безопасности для всех продуктов Майкрософт. Другие разработчики имеют такие же веб-узлы.
Используйте журналы событий Microsoft Windows и регулярно проверяйте их на предмет подозрительных операций. Следует обращать внимание на частые попытки входа в систему или на слишком большое число запросов к веб-серверу.
Запускайте приложения с наименьшими привилегиями
Каждое приложение запускается в некотором контексте, обладающем определенными правами доступа на локальном компьютере, а также, возможно, на удаленных компьютерах. Сведения о настройке идентификации приложения см. в разделе Настройка удостоверения процесса ASP.NET. Чтобы запустить приложение с минимальными необходимыми привилегиями, выполняйте следующие рекомендации.
Не запускайте приложение с правами системного пользователя (администратора).
Запускайте приложение в контексте пользователя с минимальными необходимыми привилегиями.
Задайте разрешения доступа (списки управления доступом) ко всем ресурсам, необходимым приложению. Используйте настройки с минимальным уровнем разрешений. Например, сделайте файлы доступными только для чтения, если это приемлемо для приложения. Список минимальных разрешений списка управления доступом, необходимых для идентификации приложения ASP.NET, см. в разделе Обязательные списки управления доступом (ACL) ASP.NET.
Храните файлы веб-приложения в папке под корнем приложения. Не разрешайте пользователям задавать пути доступа к файлам приложения. Это позволит избежать получения пользователями доступа к корню сервера.
Выполняйте идентификацию и проверку подлинности пользователей
Во многих приложениях пользователи могут получить анонимный доступ к узлу (не вводя учетные данные). При этом приложение получает доступ к ресурсам, запускаясь в контексте стандартного пользователя. По умолчанию используется контекст локального пользователя ASPNET (для Windows 2000 или Windows XP) или пользователя NETWORK SERVICE (для Windows Server 2003) на компьютере веб-сервера. Чтобы разрешить доступ к ресурсам только тем пользователям, которые прошли проверку подлинности, необходимо соблюдать следующие правила.
Если приложение — это внутреннее сетевое приложение, настройте его так, чтобы оно использовало встроенные средства обеспечения безопасности Windows. Таким образом, учетные данные пользователя для входа в систему можно использовать для доступа к ресурсам. Дополнительные сведения см. в разделе Олицетворение ASP.NET.
Чтобы потребовать от пользователя ввода своих учетных данных, используйте одну из стратегий проверки подлинности ASP.NET. Пример см. в разделе Управление пользователями путем объединения их в группы.
Защита от ввода вредоносных данных
Как правило, вводимые пользователем данные не следует считать безопасными. Злоумышленники могут легко отправить потенциально опасную информацию из клиента в приложение. Чтобы защититься от данных, вводимых злоумышленником, соблюдайте следующие правила.
На страницах ASP.NET фильтруйте вводимые пользователем данные и проверяете их на наличие тегов HTML, которые могут содержать сценарий. Подробные сведения см. в разделе Практическое руководство. Защита от использования сценариев в веб-приложениях с помощью применения кодирования HTML к строкам.
Не отображайте введенные пользователем данные без их предварительной фильтрации. До отображения непроверенных данных выполните HTML-кодирование, для преобразования потенциально вредоносного сценария в отображаемые строки.
Никогда не храните нефильтрованные введенные пользователем данные в базе данных.
Чтобы принять от пользователя HTML-данные, фильтруйте их вручную. В фильтре следует явным образом определить принимаемые данные. Не пытайтесь создать фильтр, пытающийся отфильтровать вредоносные данные, поскольку трудно предусмотреть все возможные типы таких данных.
Не предполагайте, что информация, получаемая из заголовка HTTP-запроса (в объекте HttpRequest), безопасна. Принимайте меры безопасности в отношении строк запросов, файлов Сookie и других элементов. Если информация, передаваемая обозревателем серверу (информация агента пользователя), важна для приложения, следует помнить, что она может быть подделана.
По возможности не храните конфиденциальные сведения в местах, доступных из обозревателя (например в скрытых полях или файлах Cookie). К примеру, не следует сохранять имя пользователя или пароль в файле Cookie.
Примечание.Состояние просмотра сохраняется в скрытом поле в закодированном формате. По умолчанию оно включает код проверки подлинности сообщения (MAC), позволяющий определить, не были ли подделаны данные состояния просмотра. Если конфиденциальные данные хранятся в состоянии просмотра, шифруйте их, присвоив свойству ViewStateEncryptionMode страницы значение true.
Безопасный доступ к базам данных
Как правило, базы данных имеют собственные средства обеспечения безопасности. Важным аспектом при создании безопасного веб-приложения является разработка способа доступа к базе данных из приложения. Необходимо соблюдать следующие правила.
Для ограничения доступа к ресурсам базы данных используйте ее встроенные средства безопасности. Конкретная стратегия зависит от базы данных и приложения:
По возможности используйте встроенные средства безопасности, чтобы доступ к базе данных был возможен только для пользователей, прошедших проверку подлинности Windows. Встроенные функции обеспечения безопасности более надежны, чем передача явно указанных учетных данных в базу данных.
Если приложение позволяет анонимный вход в систему, создайте единого пользователя с очень ограниченным числом разрешений и выполняйте запросы, подключаясь как этот пользователь.
Не создавайте инструкции SQL путем объединения строк, содержащих введенные пользователем данные. Вместо этого лучше создать параметризованный запрос и использовать введенные пользователем данные в качестве значений этих параметров.
Если необходимо сохранять имя пользователя и пароля, чтобы использовать их в качестве учетных данных для входа в базу данных, храните из в файле Web.config и обеспечьте безопасность этого файле с использованием защищенной конфигурации. Дополнительные сведения см. в разделе Шифрование сведений о конфигурации с помощью функции защищенной конфигурации.
Дополнительные сведения о безопасном доступе к данным см. в разделах Безопасность доступа к данным и Защита приложений ADO.NET.
Создание безопасных сообщений об ошибках
Если не предпринять необходимые меры предосторожности, злонамеренный пользователь может почерпнуть важные сведения о приложении из отображаемых им сообщений об ошибках. Необходимо соблюдать следующие правила.
Не включайте в сообщения об ошибках информацию, которая может быть использована злонамеренными пользователями (например, имя пользователя).
Настройте приложение таким образом, чтобы оно не выводило подробных сведений об ошибках для пользователей. Для отображения подробных сообщений об ошибках в целях отладки сначала определите, является ли пользователь локальным пользователем веб-сервера. Дополнительные сведения см. в разделе Практическое руководство. Отображение безопасных сообщений об ошибках.
С помощью элемента конфигурации customErrors определите, кто может просматривать сведения об исключениях с сервера.
Для операций, при выполнении которых могут происходить ошибки, таких как доступ к базе данных, напишите код обработки ошибок. Дополнительные сведения см. в разделе Ошибка обработки на страницах ASP.NET и в приложениях.
Защита конфиденциальной информации
Конфиденциальная информация — это любые сведения, разглашение которых нежелательно. Типичными примерами важной информации являются пароль и ключ шифрования. Если злонамеренный пользователь получает доступ к важной информации, то эти данные подвергаются опасности. Необходимо соблюдать следующие правила.
Если приложение передает конфиденциальную информацию между обозревателем и сервером, используйте протокол SSL. Подробнее об использовании безопасного узла с использованием протокола SLL см. в Q307267 "ПРАКТИЧЕСКОЕ РУКОВОДСТВО. Обеспечение безопасности XML веб-служб с помощью протокола SSL в Windows 2000" в базе знаний Майкрософт по адресу https://support.microsoft.com.
Для защиты важной информации в файлах конфигурации, таких как Web.config или Machine.config, используйте защищенную конфигурацию. Дополнительные сведения см. в разделе Шифрование сведений о конфигурации с помощью функции защищенной конфигурации.
Чтобы хранить конфиденциальную информацию, не сохраняйте ее на веб-странице, даже в такой форме, в которой, по вашему мнению, пользователи не смогут ее увидеть (например, в серверном коде).
Используйте алгоритмы строгого шифрования, реализованные в пространстве имен System.Security.Cryptography.
Безопасное использование файлов Cookie
Файлы Cookie — это простой и удобный способ предоставления доступа к специфичной для пользователя информации. Однако, поскольку файлы Сookie отправляются на компьютер обозревателя, они уязвимы для подмены и других злонамеренных действий. Необходимо соблюдать следующие правила.
Не храните в файлах Сookie важную информацию. Например, не следует, даже временно, сохранять в файле Cookie пароль пользователя. Как правило, не следует сохранять в файлах Cookie такие сведения, которые при их краже могут нарушить безопасность приложения. Вместо этого храните в файлах Cookie ссылку на расположение информации на сервере.
Устанавливайте для файлов Cookie минимальный срок действия. По возможности избегайте использования постоянных файлов Cookie.
Шифруйте информацию в файлах Cookie.
Свойствам Secure и HttpOnly файла Cookie присвойте значение true.
Защита от атак типа "отказ в обслуживании"
Злонамеренный пользователь может причинить косвенный вред приложению, сделав его недоступным. Злоумышленник может настолько нагрузить приложение, что оно не может обслуживать других пользователей или происходит сбой приложения Соблюдайте следующие правила.
Используйте обработку ошибок (например, try-catch). Включите блок Finally, в который освобождаются ресурсы в случае сбоя.
Настройте службы IIS для регулирования процесса, что позволяет избежать использования неограниченного объема времени ЦПУ приложением.
Проверяйте вводимые пользователем данные на соответствие ограничению размера до их использования или сохранения.
Установите ограничения размера для запросов к базе данных. Например, до отображения результатов запроса на веб-странице ASP.NET убедитесь, что допустимое число записей не превышено.
Установите ограничения на размер для загрузки файлов, входящих в состав приложения. Можно задать ограничение в файле Web.config с помощью синтаксиса, аналогичного приведенному ниже, где значение maxRequestLength дано в килобайтах.
<configuration> <system.web> <httpRuntime maxRequestLength="4096" /> </system.web> </configuration>Можно также использовать свойство RequestLengthDiskThreshold для снижения объема используемой памяти при загрузке больших объемов и передаче форм.