Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Приложение ASP.NET обычно хранит сведения о конфигурации в файле конфигурации Web.config. Некоторые из этих сведений являются конфиденциальными и гарантируют защиту. По умолчанию этот файл не будет обслуживаться посетителю веб-сайта, но администратор или хакер может получить доступ к файловой системе веб-сервера и просмотреть содержимое файла. В этом руководстве мы узнаем, что ASP.NET 2.0 позволяет защитить конфиденциальную информацию путем шифрования разделов файла Web.config.
Введение
Сведения о конфигурации для приложений ASP.NET обычно хранятся в XML-файле с именем Web.config. В ходе этих уроков мы обновили Web.config несколько раз. При создании типизированного Northwind набора данных в первом руководстве, например, сведения о строке подключения автоматически добавляются Web.config в <connectionStrings> раздел. Далее, в руководстве по главным страницам и навигации по сайтам, мы вручную обновили Web.config, добавив элемент <pages>, указывающий, что все страницы ASP.NET в нашем проекте должны использовать DataWebControls тему.
Так как Web.config может содержать конфиденциальные данные, такие как строка подключения, важно, чтобы содержимое Web.config хранилось в безопасности и скрытии от несанкционированных зрителей. По умолчанию любой HTTP-запрос к файлу с .config расширением обрабатывается подсистемой ASP.NET, которая возвращает сообщение этого типа страницы не обслуживается на рис. 1. Это означает, что посетители не могут просматривать содержимое вашего Web.config файла, просто введя http://www.YourServer.com/Web.config в адресной строке браузера.
При посещении Web.config через браузер отображается сообщение: "Страница этого типа не обслуживается".
Рис. 1. Посещение Web.config через браузер возвращает сообщение "Этот тип страницы не обслуживается" (нажмите, чтобы просмотреть изображение в полном размере)
Но что делать, если злоумышленник может найти другой эксплойт, позволяющий ей просматривать содержимое файла Web.config ? Что может сделать злоумышленник с этой информацией, и какие шаги можно предпринять для дальнейшего защиты конфиденциальной информации в пределах Web.config? К счастью, в большинстве разделов Web.config не содержится конфиденциальная информация. Какой вред может нанести злоумышленник, если он знает имя темы по умолчанию, используемой вашими страницами ASP.NET?
Однако некоторые Web.config разделы содержат конфиденциальную информацию, которая может включать такие элементы, как строки подключения, имена пользователей, пароли, имена серверов, ключи шифрования и т. д. Эти сведения обычно находятся в следующих Web.config разделах:
<appSettings><connectionStrings><identity><sessionState>
В этом руководстве мы рассмотрим методы защиты таких конфиденциальных сведений о конфигурации. Как мы увидим, платформа .NET Framework версии 2.0 включает в себя систему защищенных конфигураций, которая облегчает программное шифрование и расшифровку выбранных разделов конфигурации, делая их очень простыми.
Примечание.
В этом руководстве приведены рекомендации Майкрософт по подключению к базе данных из приложения ASP.NET. Помимо шифрования строка подключения, вы можете защитить систему, обеспечивая безопасное подключение к базе данных.
Шаг 1. Изучение параметров защищенной конфигурации ASP.NET 2.0
ASP.NET 2.0 включает защищенную систему конфигурации для шифрования и расшифровки сведений о конфигурации. Это включает методы в платформе .NET Framework, которые можно использовать для программного шифрования или расшифровки сведений о конфигурации. В защищенной системе конфигурации используется модель поставщика, которая позволяет разработчикам выбирать, какую криптографическую реализацию используется.
Платформа .NET Framework поставляется с двумя защищенными поставщиками конфигурации:
-
RSAProtectedConfigurationProvider— использует асимметричный алгоритм RSA для шифрования и расшифровки. -
DPAPIProtectedConfigurationProvider— использует API защиты данных Windows (DPAPI) для шифрования и расшифровки.
Так как защищенная система конфигурации реализует шаблон проектирования поставщика, можно создать собственный защищенный поставщик конфигурации и подключить его к приложению. Дополнительные сведения об этом процессе см. в статье о реализации защищенного поставщика конфигурации .
Поставщики RSA и DPAPI используют ключи для своих процедур шифрования и расшифровки, и эти ключи можно хранить на уровне компьютера или пользователя. Ключи на уровне компьютера идеально подходят для сценариев, когда веб-приложение работает на собственном выделенном сервере или если на сервере есть несколько приложений, которым требуется предоставить общий доступ к зашифрованной информации. Ключи уровня пользователя — это более безопасный вариант в общих средах размещения, где другие приложения на том же сервере не должны расшифровывать защищенные разделы конфигурации приложения.
В этом руководстве в наших примерах мы будем использовать провайдер DPAPI и ключи на уровне машины. В частности, мы рассмотрим шифрование <connectionStrings> раздела в Web.config, хотя защищенная система конфигурации может использоваться для шифрования большинства разделов Web.config . Сведения об использовании ключей уровня пользователя или использовании поставщика RSA см. в разделе "Дополнительные чтения" в конце этого руководства.
Примечание.
Поставщики RSAProtectedConfigurationProvider и DPAPIProtectedConfigurationProvider зарегистрированы в файле machine.config с именами поставщиков RsaProtectedConfigurationProvider и DataProtectionConfigurationProvider, соответственно. При шифровании или расшифровке сведений о конфигурации необходимо указать соответствующее имя поставщика (RsaProtectedConfigurationProvider или DataProtectionConfigurationProvider) вместо фактического имени типа (RSAProtectedConfigurationProvider и DPAPIProtectedConfigurationProvider). Файл можно найти machine.config в папке $WINDOWS$\Microsoft.NET\Framework\version\CONFIG .
Шаг 2. Программное шифрование и расшифровка разделов конфигурации
С помощью нескольких строк кода можно зашифровать или расшифровать определенный раздел конфигурации с помощью указанного поставщика. Код, как мы увидим вскоре, просто необходимо программно ссылаться на соответствующий раздел конфигурации, вызывать его ProtectSection или UnprotectSection метод, а затем вызывать Save метод для сохранения изменений. Кроме того, платформа .NET Framework включает полезную программу командной строки, которая может шифровать и расшифровывать сведения о конфигурации. Мы рассмотрим эту служебную программу командной строки на шаге 3.
Чтобы проиллюстрировать программную защиту сведений о конфигурации, создадим страницу ASP.NET, которая включает кнопки для шифрования и расшифровки раздела <connectionStrings> в Web.config.
Начните с открытия EncryptingConfigSections.aspx страницы в папке AdvancedDAL . Перетащите элемент управления TextBox из панели элементов в конструктор, присвоив свойству ID значение WebConfigContents, свойству TextMode значение MultiLine, а свойствам Width и Rows значения 95% и 15 соответственно. В этом элементе управления TextBox отображается содержимое Web.config , позволяющее быстро узнать, зашифровано ли содержимое. Конечно, в реальном приложении вы никогда не хотите отображать содержимое Web.config.
Под текстовым полем добавьте два элемента управления Button с именем EncryptConnStrings и DecryptConnStrings. Задайте свойства текста для шифрования строк подключения и расшифровки строк подключения.
На этом этапе экран должен выглядеть примерно так же, как на рис. 2.
Рис. 2. Добавление текстового поля и двух кнопки веб-элементов управления на страницу (щелкните, чтобы просмотреть изображение полного размера)
Затем необходимо написать код, который загружает и отображает содержимое текстового Web.config поля при WebConfigContents первой загрузке страницы. Добавьте следующий код в класс, связанный с кодом страницы. Этот код добавляет метод с именем DisplayWebConfig и вызывает его из обработчика события Page_Load, когда Page.IsPostBackfalse.
protected void Page_Load(object sender, EventArgs e)
{
// On the first page visit, call DisplayWebConfig method
if (!Page.IsPostBack)
DisplayWebConfig();
}
private void DisplayWebConfig()
{
// Reads in the contents of Web.config and displays them in the TextBox
StreamReader webConfigStream =
File.OpenText(Path.Combine(Request.PhysicalApplicationPath, "Web.config"));
string configContents = webConfigStream.ReadToEnd();
webConfigStream.Close();
WebConfigContents.Text = configContents;
}
Метод DisplayWebConfig использует File класс для открытия файла приложения Web.config , StreamReader класса для чтения его содержимого в строку и Path класса для создания физического пути к файлу Web.config . Эти три класса находятся в System.IO пространстве имен. Следовательно, необходимо добавить оператор usingSystem.IO в верхнюю часть класса code-behind или, альтернативно, добавить префикс к этим именам классов System.IO..
Затем необходимо добавить обработчики событий для элементов управления Click Button и добавить необходимый код для шифрования и расшифровки раздела <connectionStrings> с использованием ключа уровня компьютера и провайдера DPAPI. В конструкторе дважды щелкните каждую Click из кнопок, чтобы добавить обработчик событий в класс программной части, а затем добавьте следующий код:
protected void EncryptConnStrings_Click(object sender, EventArgs e)
{
// Get configuration information about Web.config
Configuration config =
WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
// Let's work with the <connectionStrings> section
ConfigurationSection connectionStrings = config.GetSection("connectionStrings");
if (connectionStrings != null)
// Only encrypt the section if it is not already protected
if (!connectionStrings.SectionInformation.IsProtected)
{
// Encrypt the <connectionStrings> section using the
// DataProtectionConfigurationProvider provider
connectionStrings.SectionInformation.ProtectSection(
"DataProtectionConfigurationProvider");
config.Save();
// Refresh the Web.config display
DisplayWebConfig();
}
}
protected void DecryptConnStrings_Click(object sender, EventArgs e)
{
// Get configuration information about Web.config
Configuration config =
WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
// Let's work with the <connectionStrings> section
ConfigurationSection connectionStrings =
config.GetSection("connectionStrings");
if (connectionStrings != null)
// Only decrypt the section if it is protected
if (connectionStrings.SectionInformation.IsProtected)
{
// Decrypt the <connectionStrings> section
connectionStrings.SectionInformation.UnprotectSection();
config.Save();
// Refresh the Web.config display
DisplayWebConfig();
}
}
Код, используемый в двух обработчиках событий, почти идентичен. Они оба начинают с получения сведений о текущем файле приложения Web.config с помощью метода WebConfigurationManager класса OpenWebConfiguration. Этот метод возвращает файл веб-конфигурации для указанного виртуального пути. Затем доступ к разделу Web.config файлов <connectionStrings> осуществляется через Configuration метод классаGetSection(sectionName), который возвращает ConfigurationSection объект.
Объект ConfigurationSection содержит SectionInformation свойство , которое предоставляет дополнительные сведения и функциональные возможности в разделе конфигурации. Как показано в приведенном выше коде, можно определить, зашифрован ли раздел конфигурации, проверив свойство SectionInformation в свойстве IsProtected. Кроме того, раздел можно зашифровать или расшифровать с помощью SectionInformationProtectSection(provider) свойств и UnprotectSection методов.
Метод ProtectSection(provider) принимает в качестве входных данных строку, указывающую имя защищенного поставщика конфигурации, используемого при шифровании. В обработчике событий EncryptConnString кнопки мы передаем DataProtectionConfigurationProvider в метод ProtectSection(provider), чтобы задействовать поставщика DPAPI. Метод UnprotectSection может определить поставщика, который использовался для шифрования раздела конфигурации, поэтому не требует входных параметров.
После вызова метода ProtectSection(provider) или метода UnprotectSection необходимо вызвать метод объекта ConfigurationSave, чтобы сохранить изменения. После шифрования или расшифровки сведений о конфигурации и сохранения изменений мы вызываем DisplayWebConfig, чтобы загрузить обновленное содержимое Web.config в TextBox.
После ввода приведенного выше кода проверьте его, перейдя на EncryptingConfigSections.aspx страницу через браузер. Сначала должна появиться страница, которая содержит содержимое Web.config и <connectionStrings> раздела, отображаемого в виде обычного текста (см. рис. 3).
Рис. 3. Добавление текстового поля и двух кнопки веб-элементов управления на страницу (щелкните, чтобы просмотреть изображение полного размера)
Теперь нажмите кнопку "Зашифровать строки подключения". Если проверка запросов включена, разметка, возвращенная из WebConfigContents TextBox, создаст HttpRequestValidationException, отображающее сообщение: «Обнаружено потенциально опасное значение Request.Form от клиента». Проверка запроса, которая включена по умолчанию в ASP.NET 2.0, запрещает обратные передачи, которые включают некодированный HTML и предназначены для предотвращения атак внедрения скриптов. Эта проверка может быть отключена на уровне страницы или приложения. Чтобы отключить его для этой страницы, задайте ValidateRequest параметр false в директиве @Page . Директива @Page найдена в верхней части декларативной разметки страницы.
<%@ Page ValidateRequest="False" ... %>
Дополнительные сведения о проверке запросов, его цели, о том, как отключить его на уровне страницы и приложения, а также как кодировать разметку HTML, см. в статье "Проверка запросов — предотвращение атак скриптов".
После отключения проверки запроса на страницу попробуйте снова нажать кнопку "Зашифровать строки подключения". После обратной передачи будет получен доступ к файлу конфигурации, и его раздел <connectionStrings> будет зашифрован с помощью поставщика DPAPI. Затем текстовое поле обновляется, чтобы отобразить новое Web.config содержимое. Как показано на рисунке 4, <connectionStrings> данные теперь шифруются.
Рис. 4. Нажатие кнопки "Зашифровать строки подключения" шифрует <connectionString> раздел (щелкните, чтобы просмотреть изображение полного размера)
Зашифрованный <connectionStrings> раздел, созданный на моем компьютере, приведён ниже, хотя часть содержимого элемента <CipherData> была удалена для краткости.
<connectionStrings
configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue></CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>
Примечание.
Элемент <connectionStrings> указывает поставщика, используемого для выполнения шифрования (DataProtectionConfigurationProvider). Эти сведения используются методом UnprotectSection при нажатии кнопки "Расшифровка строк подключения".
Когда доступ к информации о строке подключения из Web.config осуществляется либо по коду, который мы пишем, из элемента управления SqlDataSource, или автоматически созданным кодом из TableAdapters в наших типизированных наборах данных, он автоматически расшифровывается. Короче говоря, нам не нужно добавлять дополнительный код или логику для расшифровки зашифрованного <connectionString> раздела. Чтобы продемонстрировать это, посетите одно из предыдущих руководств, например руководство по простому отображению из раздела "Основные отчеты" (~/BasicReporting/SimpleDisplay.aspx). Как показано на рисунке 5, руководство работает точно так, как и ожидалось, показывая, что зашифрованная информация строки подключения автоматически расшифровывается страницей ASP.NET.
Рис. 5. Уровень доступа к данным автоматически расшифровывает сведения о строке подключения (щелкните, чтобы просмотреть изображение полного размера)
Чтобы вернуть раздел <connectionStrings> к обычному тексту, нажмите кнопку "Расшифровать строки". При повторной отправке вы должны увидеть строки подключения в Web.config в виде простого текста. На этом этапе экран должен выглядеть так, как при первом посещении этой страницы (см. рис. 3).
Шаг 3. Шифрование разделов конфигурации с помощью aspnet_regiis.exe
Платформа .NET Framework включает различные средства командной строки в папке$WINDOWS$\Microsoft.NET\Framework\version\. Например, в руководстве по использованию зависимостей кэша SQL мы рассмотрели использование aspnet_regsql.exe средства командной строки для добавления инфраструктуры, необходимой для зависимостей кэша SQL. Другим полезным средством командной строки в этой папке является средство регистрации ASP.NET IIS (aspnet_regiis.exe). Как подразумевает его имя, средство регистрации IIS ASP.NET в основном используется для регистрации приложения ASP.NET 2.0 на веб-сервере профессионального уровня Майкрософт, IIS. Помимо функций, связанных с IIS, средство регистрации служб IIS ASP.NET также можно использовать для шифрования или расшифровки указанных разделов конфигурации.Web.config
В следующей инструкции показан общий синтаксис, используемый для шифрования раздела конфигурации с помощью средства командной aspnet_regiis.exe строки:
aspnet_regiis.exe -pef section physical_directory -prov provider
Раздел конфигурации для шифрования (например, connectionStrings), physical_directory — это полный физический путь к корневому каталогу веб-приложения, а поставщик — это название используемого защищенного поставщика конфигурации (например, DataProtectionConfigurationProvider). Кроме того, если веб-приложение зарегистрировано в IIS, можно ввести виртуальный путь вместо физического пути с помощью следующего синтаксиса:
aspnet_regiis.exe -pe section -app virtual_directory -prov provider
aspnet_regiis.exe Следующий пример шифрует <connectionStrings> раздел с помощью поставщика DPAPI и ключа уровня компьютера:
aspnet_regiis.exe -pef
"connectionStrings" "C:\Websites\ASPNET_Data_Tutorial_73_CS"
-prov "DataProtectionConfigurationProvider"
Аналогичным образом средство командной aspnet_regiis.exe строки можно использовать для расшифровки разделов конфигурации. Вместо использования коммутатора -pef используйте -pdf (или вместо -peэтого используйте -pd). Кроме того, обратите внимание, что имя поставщика не требуется при расшифровке.
aspnet_regiis.exe -pdf section physical_directory
-- or --
aspnet_regiis.exe -pd section -app virtual_directory
Примечание.
Так как мы используем поставщик DPAPI, который использует ключи, относящиеся к компьютеру, необходимо запустить aspnet_regiis.exe с того же компьютера, с которого обслуживаются веб-страницы. Например, если запустить эту программу командной строки с локального компьютера разработки, а затем передать зашифрованный файл web.config на рабочий сервер, рабочий сервер не сможет расшифровать сведения строка подключения, так как он был зашифрован с помощью ключей, относящихся к компьютеру разработки. У поставщика RSA нет этого ограничения, так как можно экспортировать ключи RSA на другой компьютер.
Общие сведения о параметрах проверки подлинности базы данных
Прежде чем любое приложение может выдавать SELECTзапросы INSERTUPDATEDELETE к базе данных Microsoft SQL Server, база данных сначала должна определить запрашивателя. Этот процесс называется проверкой подлинности и SQL Server предоставляет два метода проверки подлинности:
-
Проверка подлинности Windows — процесс, в котором выполняется приложение, используется для взаимодействия с базой данных. При запуске приложения ASP.NET через сервер разработки ASP.NET Visual Studio 2005, приложение использует удостоверение пользователя, вошедшего в систему. Для приложений ASP.NET в Microsoft Internet Information Server (IIS), приложения ASP.NET обычно действуют от имени
domainName``\MachineNameилиdomainName``\NETWORK SERVICE, хотя это можно настроить. - Проверка подлинности SQL — значения идентификатора пользователя и пароля предоставляются в качестве учетных данных для проверки подлинности. При проверке подлинности SQL идентификатор пользователя и пароль предоставляются в строке подключения.
проверка подлинности Windows предпочтительна по сравнению с проверкой подлинности SQL, так как она более безопасна. При использовании проверки подлинности Windows строка подключения не содержит имени пользователя и пароля, а если веб-сервер и сервер базы данных находятся на разных компьютерах, учетные данные не отправляются по сети в незашифрованном виде. Однако при проверке подлинности SQL учетные данные проверки подлинности жестко закодированы в строка подключения и передаются с веб-сервера на сервер базы данных в виде обычного текста.
Эти учебники использовали проверку подлинности Windows. Чтобы узнать, какой режим проверки подлинности используется, проверьте строку подключения. Строка подключения в Web.config для наших учебников была:
Data Source=.\SQLEXPRESS; AttachDbFilename=|DataDirectory|\NORTHWND.MDF; Integrated Security=True; User Instance=True
Встроенная безопасность=True и отсутствие имени пользователя и пароля указывают на то, что используется проверка подлинности Windows. В некоторых строках подключения используется термин "Доверенное соединение=Да" или "Интегрированная безопасность=SSPI" вместо "Интегрированная безопасность=True", но все три указывают на использование проверки подлинности Windows.
В следующем примере показана строка подключения, использующая SQL-аутентификацию.
$CREDENTIAL_PLACEHOLDER$ — это заполнитель для пары "ключ-значение пароля". Обратите внимание, что учетные данные внедрены в строку подключения:
Server=serverName; Database=Northwind; uid=userID; $CREDENTIAL_PLACEHOLDER$
Представьте, что злоумышленник может просмотреть файл приложения Web.config . При использовании проверки подлинности SQL для подключения к базе данных, доступной из сети Интернет, злоумышленник может использовать эту строку подключения для подключения к базе данных с помощью SQL Management Studio или с ASP.NET страниц на его собственном веб-сайте. Чтобы уменьшить эту угрозу, зашифруйте информацию о строке подключения с помощью защищенной системы конфигурации в Web.config.
Примечание.
Дополнительные сведения о различных типах проверки подлинности, доступных в SQL Server, см. в статье "Создание безопасных ASP.NET приложений: проверка подлинности, авторизация и безопасный обмен данными". Дополнительные примеры строки подключения, иллюстрирующие различия между синтаксисом проверки подлинности Windows и SQL, см. в ConnectionStrings.com.
Итоги
По умолчанию файлы с .config расширением в приложении ASP.NET не могут быть доступны через браузер. Эти типы файлов не возвращаются, так как они могут содержать конфиденциальную информацию, например строка подключения базы данных, имена пользователей и пароли и т. д. Система защищенной конфигурации в .NET 2.0 помогает защитить конфиденциальную информацию, позволяя шифровать указанные разделы конфигурации. Существует два встроенных защищенных поставщика конфигураций: один из которых использует алгоритм RSA и один из них, использующий API защиты данных Windows (DPAPI).
В этом руководстве мы рассмотрели, как шифровать и расшифровывать параметры конфигурации с помощью поставщика DPAPI. Это можно сделать как программным способом, как мы видели в шаге 2, так и с помощью инструмента командной aspnet_regiis.exe строки, который рассматривался в шаге 3. Дополнительные сведения об использовании ключей на уровне пользователя или использовании поставщика RSA см. в разделе "Дополнительное чтение".
Счастливое программирование!
Дополнительные материалы
Дополнительные сведения о разделах, описанных в этом руководстве, см. в следующих ресурсах:
- Создание безопасного приложения ASP.NET: проверка подлинности, авторизация и безопасный обмен данными
- Шифрование сведений о конфигурации в приложениях ASP.NET 2.0
-
Web.configШифрование значений в ASP.NET 2.0 - Практическое руководство. Шифрование разделов конфигурации в ASP.NET 2.0 с помощью DPAPI
- Практическое руководство. Шифрование разделов конфигурации в ASP.NET 2.0 с помощью RSA
- API конфигурации в .NET 2.0
- Защита данных Windows
Об авторе
Скотт Митчелл, автор семи книг ASP/ASP.NET и основатель 4GuysFromRolla.com, работает с технологиями Microsoft Web с 1998 года. Скотт работает независимым консультантом, тренером и писателем. Его последняя книга Sams: Изучите самостоятельно ASP.NET 2.0 за 24 часа. С ним можно связаться по адресу mitchell@4GuysFromRolla.com.
Особое спасибо кому
Эта серия учебников была проверена многими полезными рецензентами. Ведущими рецензентами этого руководства были Тэреза Мерфи и Рэнди Шмидт. Хотите просмотреть мои предстоящие статьи MSDN? Если да, напишите мне на mitchell@4GuysFromRolla.com.