Поделиться через


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

Обновлен: Ноябрь 2007

Проблема создания безопасного веб-приложения очень обширна. Для ее рассмотрения необходимо полное понимание слабых мест в системе безопасности. Также необходимо ознакомиться с функциями обеспечения безопасности Windows, .NET Framework и ASP.NET. И, наконец, очень важно понимать способы использования этих функций безопасности для борьбы с угрозами.

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

  • Общие рекомендации по обеспечению безопасности веб-приложения

  • Запускайте приложения с наименьшими привилегиями

  • Выполняйте идентификацию и проверку подлинности пользователей

  • Защита от ввода вредоносных данных

  • Безопасный доступ к базам данных

  • Безопасные сообщения об ошибках

  • Безопасное хранение секретной информации

  • Безопасное использование файлов Cookie

  • Защита от атак типа "отказ в обслуживании"

    zdh19h94.alert_note(ru-ru,VS.90).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.

    zdh19h94.alert_note(ru-ru,VS.90).gifПримечание.

    Состояние просмотра сохраняется в скрытом поле в закодированном формате. По умолчанию оно включает код проверки подлинности сообщения (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 — это простой и удобный способ предоставления доступа к специфичной для пользователя информации. Однако, поскольку файлы С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 для снижения объема используемой памяти при загрузке больших объемов и передаче форм.

См. также

Основные понятия

Общие сведения об угрозах безопасности веб-приложений