Безопасность доступа к данным

Статья
10/22/2014

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

Большинство веб-приложений ASP.NET тем или иным образом используют доступ к данным. Многие приложения аккумулируют данные в базе данных или файле, а хранимые данные часто основаны на сведениях, предоставленных пользователями. Поскольку исходные данные могут поступать из ненадежных источников, а информация хранится длительное время и необходимо быть уверенным в том, что неавторизованные пользователи не смогут получить непосредственный доступ к данным, требуется уделить особое внимание проблеме безопасности доступа к данным. В этом разделе приводятся рекомендации, которые помогут повысить безопасность доступа к данным в веб-приложении ASP.NET.

Предлагаемые рекомендации в отношении конфигурации и кодирования помогут повысить безопасность приложений. Но не менее важно на постоянной основе следить за тем, чтобы на веб-сервере были установлены последние обновления для системы безопасности Microsoft Windows и служб IIS, а также обновления для системы безопасности Microsoft SQL Server или другого программного обеспечения, обеспечивающего доступ к источникам данных.

Более подробные советы и рекомендации по написанию безопасного кода и защите приложений приведены в книге «Защищенный код» Майкла Ховарда и Дэвида Леблана, а также на веб-узле Шаблоны и методики Майкрософт (на английском языке).

Обеспечение безопасного доступа к источнику данных

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

Строки подключения

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

Не храните строки подключения на странице. Например, избегайте установки строк подключения в декларативных свойствах элемента управления SqlDataSource или других элементов управления источниками данных. Вместо этого храните строки подключения в файле Web.config веб-узла. Пример см. в разделе Практическое руководство. Безопасность строк подключения при использовании элементов управления источником данных.
Не храните строки подключения в виде обычного текста. Чтобы обеспечить безопасность подключения к серверу базы данных, рекомендуется зашифровать строку подключения в файле конфигурации, воспользовавшись защищенной конфигурацией. Дополнительные сведения см. в разделе Шифрование сведений о конфигурации с помощью функции защищенной конфигурации.

Подключение к SQL Server с помощью встроенных средств безопасности

По возможности следует подключаться к экземпляру SQL Server с помощью встроенных средств безопасности вместо явного задания имени пользователя и пароля. Это позволит избежать риска раскрытия строки соединения, идентификатора пользователя и пароля.

Рекомендуется, чтобы удостоверением процесса (например, пула приложений), который выполняет приложения ASP.NET, являлась учетная запись для процессов по умолчанию или учетная запись пользователя с ограниченными правами. Дополнительные сведения см. в разделе Олицетворение ASP.NET.

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

Разрешения базы данных SQL Server

Рекомендуется назначать минимальные разрешения идентификатору пользователя, с помощью которого выполняется подключение к базе данных SQL Server приложения.

Ограничение операций SQL

Элементы управления с привязкой к данным могут поддерживать разнообразные операции с данными, включая выбор, вставку, удаление и обновление записей в таблицах данных. Рекомендуется настраивать элементы управления данными на выполнение минимальных функций, требующихся странице или приложению. Например, если элемент управления не должен позволять пользователям удалять данные, не включайте с элементом управления источником данных запрос на удаление и не разрешайте удаление в этом элементе управления.

SQL Server, экспресс-выпуск

Когда процесс подключается к базе данных SQL Server, экспресс-выпуск (к MDF-файлу), он должен иметь права администратора. В общем, это делает базы данных SQL Server, экспресс-выпуск непрактичными для разработки веб-узлов, так как процесс ASP.NET не выполняется (и не должен) с правами администратора. Поэтому используйте базы данных SQL Server, экспресс-выпуск только при соблюдении следующих условий:

База данных используется в качестве тестовой при разработке веб-приложения. Когда приложение будет готово для развертывания, следует перенести базу данных с SQL Server, экспресс-выпуск в рабочий экземпляр SQL Server.
База данных используется в составе веб-узла, поддерживающего олицетворение и позволяющего управлять правами олицетворяемого пользователя. Эта стратегия действенна, только если приложение работает в локальной сети (не на общедоступном веб-узле).
Храните файл MDF в папке App_Data веб-узла, поскольку содержимое этой папки не будет возвращено в ответ на прямой HTTP-запрос. Следует также сопоставить расширение MDF с ASP.NET в службах IIS и в обработчике ASP.NET HttpForbiddenHandler с помощью следующего элемента в файле Web.config веб-узла:
```
<httpHandlers>
  <add verb="*" path="*.mdf" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Сведения о том, как сопоставить в службах IIS расширение имени файла с ASP.NET см. в разделе Практическое руководство. Регистрация обработчиков HTTP-данных.

Базы данных Microsoft Access

Базы данных Microsoft Access (файлы MDB) имеют меньше возможностей по обеспечению безопасности, чем базы данных SQL Server. Базы данных Microsoft Access не рекомендуются для создания веб-узлов. Однако, если есть причины использовать MDB-файл как часть веб-приложения, придерживайтесь следующих правил:

Храните MDB-файл в папке App_Data веб-узла, поскольку содержимое этой папки не будет возвращено в ответ на прямой HTTP-запрос. Следует также сопоставить расширение MDB с ASP.NET в службах IIS и в обработчике ASP.NET HttpForbiddenHandler с помощью следующего элемента в файле Web.config веб-узла:
```
<httpHandlers>
  <add verb="*" path="*.mdb" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Сведения о том, как сопоставить в службах IIS расширение имени файла с ASP.NET см. в разделе Практическое руководство. Регистрация обработчиков HTTP-данных.
Добавьте соответствующие права для учетной записи пользователя или тех учетных записей, которые будут выполнять операции чтения и записи файла MDB. Если веб-узел поддерживает анонимный доступ, то, как правило, это будет локальная учетная запись ASPNET или учетная запись NETWORK SERVICE. Поскольку Microsoft Access создает LDB-файл сведений о блокировке, учетная запись пользователя должна иметь право на запись в папку, содержащую MDB-файл.
Если база данных защищена паролем, не следует использовать для подключения к ней элемент управления AccessDataSource, так как элемент управления AccessDataSource не поддерживает передачу учетных данных. Вместо этого используйте элемент управления SqlDataSource с поставщиком ODBC и передавайте учетные данные в строке подключения. Проверьте, что строки подключения защищены согласно рекомендациям подраздела Строки подключения.

XML-файлы

Если данные сохраняются в XML-файл, поместите его в папку App_Data веб-узла, так как содержимое этой папки не будет возвращено в ответ на прямой HTTP-запрос.

Защита от злоумышленного пользовательского ввода

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

Внедрение сценария. Атака методом внедрения сценария пытается отправить в приложение исполняемый сценарий с таким расчетом, чтобы его запустили другие пользователи. Обычно такая атака отправляет сценарий странице, которая сохраняет его в базе данных, так что другой пользователь, просматривающий данные, непреднамеренно инициирует выполнение этого кода.
Внедрение кода SQL. Атака путем внедрения кода SQL предпринимает попытку поставить под угрозу базу данных (и, потенциально, компьютер, на котором работает база данных) с помощью создания команд SQL, которые выполняются вместо или дополнительно к командам приложения.

Общие рекомендации

Во всех случаях пользовательского ввода соблюдайте следующие правила:

Везде, где только возможно, используйте проверочные элементы управления, чтобы ограничить пользовательский ввод допустимыми значениями.
Перед запуском серверного кода всегда проверяйте, что значение свойства IsValid равно true. Значение false означает, что один или несколько проверочных элементов управления сообщают об ошибке при проверке данных.
Всегда выполняйте проверку на стороне сервера, даже если обозреватель также выполняет проверку, чтобы защититься от пользователей, обходящих проверку на стороне клиента. Особенно это относится к элементу управления CustomValidator. Не следует использовать только логику проверки на стороне клиента.
Всегда перепроверяйте пользовательский ввод на уровне бизнес-логики приложения. Не полагайтесь на то, что вызывающий процесс предоставляет безопасные данные. Например, при использовании элемента управления ObjectDataSource добавьте в объект, выполняющий обновление данных, кодирование и дополнительную проверку.

Внедрение сценария

Для защиты от атак внедрения сценария соблюдайте следующие правила:

Кодируйте пользовательский ввод с помощью метода HtmlEncode, который преобразует символы HTML в их текстовое представление (например, <b> становится &ltb>), что позволяет не допустить выполнение обозревателем разметки.
Если используются объекты параметров для передачи пользовательского ввода в SQL-запрос, добавьте в элемент управления источника данных обработчики событий, вызывающиеся до выполнения запроса, и включите в эти обработчики кодирование. Например, в обработчике события Inserting элемента управления SqlDataSource кодируйте значение параметра перед выполнением запроса.
При использовании элемента управления GridView с присоединенными полями установите для объекта BoundField свойство HtmlEncode в true. Элемент управления GridView будет кодировать пользовательский ввод, когда строка находится в режиме редактирования.
Для элементов управления, которые могут быть переведены в режим редактирования, рекомендуется использовать шаблоны. Например, элементы управления GridView, DetailsView, FormView, DataList и Login могут отображать текстовые поля. Тем не менее, за исключением элемента управления GridView (см. выше) элементы управления автоматически не выполняют проверку данных или HTML-кодирование пользовательского ввода. Поэтому рекомендуется создавать шаблоны для таких элементов управления и включать в шаблон элемент управления вводом, например TextBox, и проверочный элемент управления. Кроме того, следует кодировать значение, извлекаемое из элемента управления.

Атака путем внедрения кода SQL

Для защиты от атак внедрения кода SQL соблюдайте следующие правила:

Не создавайте команды SQL путем соединения строк, особенно содержащих данные пользовательского ввода. Вместо этого используйте параметризованные запросы или хранимые процедуры.
При создании параметризованного запроса используйте объекты параметров для установки значений параметров. Дополнительные сведения см. в разделах Использование параметров с элементом управления SqlDataSource и Использование параметров с элементами управления источников данных.

Шифрование данных режима просмотра

В элементах управления с привязкой к данным, таких как GridView, иногда необходимо сохранять конфиденциальные сведения. Например, элемент управления GridView может содержать список ключей в свойстве DataKeys, даже если эта информация не отображается. Между циклами обмена данными элемент управления хранит эти сведения в режиме просмотра.

Данные режима просмотра кодируются и хранятся вместе с содержимым страницы и могут быть декодированы и предоставлены нежелательному источнику. Если необходимо хранить конфиденциальные сведения в режиме просмотра, можно потребовать, чтобы страница шифровала эти данные. Для шифрования данных присвойте свойству страницы ViewStateEncryptionMode значение true.

Кэширование

Рекомендуется избегать хранения конфиденциальных сведений в объекте Cache, если разрешено олицетворение клиента и результаты из источника данных извлекаются на основе удостоверения клиента. Если кэширование включено, кэшированные данные одного пользователя могут быть доступны для просмотра всем пользователям и возможно предоставление конфиденциальных сведений нежелательному источнику. Олицетворение клиента разрешается, когда атрибуту impersonate элемента конфигурации identity присваивается значение true и на веб-сервере для данного приложения отключена анонимная идентификация.

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