1. Einführung
Beim Erstellen von ASP.NET 2.0-Anwendungen speichern Entwickler normalerweise vertrauliche Konfigurationsinformationen in der Datei Web.config. Das typischste Beispiel ist die Datenbankverbindungszeichenfolge, aber auch andere vertrauliche Informationen, die in der Web.config-Datei enthalten sind, umfassen SMTP-Serververbindungsinformationen und Benutzeranmeldedaten usw. Obwohl ASP.NET standardmäßig so konfiguriert werden kann, dass alle HTTP-Anfragen für Dateiressourcen mit der Erweiterung .config abgelehnt werden, können vertrauliche Informationen dennoch gestohlen werden, wenn ein Hacker auf das Dateisystem Ihres Webservers zugreifen kann. Möglicherweise haben Sie beispielsweise versehentlich den anonymen FTP-Zugriff auf Ihre Website zugelassen und so einem Hacker ermöglicht, Ihre Web.config-Datei einfach über das FTP-Protokoll herunterzuladen.
Glücklicherweise hilft ASP.NET 2.0, dieses Problem zu lindern, indem es Ihnen ermöglicht, ausgewählte Teile der Web.config-Datei zu verschlüsseln, z. B. den Abschnitt <connectionStrings> oder einen benutzerdefinierten Konfigurationsabschnitt, der von Ihrer Anwendung verwendet wird. Konfigurationsabschnitte können einfach mithilfe der Kodierung oder aspnet_regiis.exe (einem Befehlszeilenprogramm) vorverschlüsselt werden. Nach der Verschlüsselung sind die Web.config-Einstellungen vor neugierigen Blicken geschützt. Darüber hinaus entschlüsselt ASP.NET beim programmgesteuerten Abrufen verschlüsselter Konfigurationseinstellungen von Ihrer ASP.NET-Seite automatisch den verschlüsselten Teil, den es liest. Kurz gesagt: Sobald die Konfigurationsinformationen verschlüsselt sind, müssen Sie keinen weiteren Code schreiben oder weitere Maßnahmen in Ihrer Anwendung ergreifen, um die verschlüsselten Daten zu verwenden.
In diesem Artikel besprechen wir, wie dieser Abschnitt mit den Konfigurationseinstellungen programmgesteuert ver- und entschlüsselt wird, und untersuchen die Verwendung des Befehlszeilenprogramms aspnet_regiis.exe. Anschließend evaluieren wir die Verschlüsselungsoptionen von ASP.NET 2.0. Darüber hinaus diskutieren wir kurz, wie Konfigurationsinformationen in ASP.NET Version 1.x verschlüsselt werden.
2. Prämisse
Bevor wir mit der Diskussion beginnen, wie ASP.NET 2.0-Konfigurationsinformationen verschlüsselt werden, bedenken Sie bitte die folgenden Punkte:
1. Alle Formen der Verschlüsselung enthalten eine Art Geheimnis, und dieses Geheimnis wird beim Ver- und Entschlüsseln von Daten verwendet. Symmetrische Verschlüsselungsalgorithmen verwenden beim Verschlüsseln und Entschlüsseln einer Nachricht denselben Schlüssel, während asymmetrische Verschlüsselungsalgorithmen unterschiedliche Schlüssel zum Verschlüsseln und Entschlüsseln verwenden. Egal welche Technologie zum Einsatz kommt, das Wichtigste ist, wie sicher der Entschlüsselungsschlüssel ist.
2. Die von ASP.NET 2.0 bereitgestellte Konfigurationsverschlüsselungstechnologie soll verhindern, dass Hacker Ihre Konfigurationsdateien auf irgendeine Weise abrufen können. Die Idee dahinter ist, dass der Hacker den verschlüsselten Teil nicht knacken kann, wenn sich Ihre Web.config-Datei auf dem Computer befindet. Wenn jedoch eine ASP.NET-Seite auf dem Webserver Informationen aus einer verschlüsselten Konfigurationsdatei anfordert, müssen die Daten entschlüsselt werden, bevor sie verwendet werden können (und dies geschieht, ohne dass Sie Code schreiben müssen). Wenn es einem Hacker daher gelingt, eine ASP.NET-Webseite auf Ihr System hochzuladen, die die Konfigurationsdatei abfragt und deren Ergebnisse anzeigt, kann er die verschlüsselten Einstellungen als Klartext anzeigen. (Einzelheiten finden Sie auf der in diesem Artikel bereitgestellten ASP.NET-Beispielseite, die zeigt, wie verschiedene Teile der Web.config-Datei ver- und entschlüsselt werden. Wie Sie sehen, kann eine ASP.NET-Seite darauf zugreifen (und diese anzeigen). die verschlüsselten Daten (normale Textform)
3. Das Verschlüsseln und Entschlüsseln von Konfigurationsinformationen erfordert einen gewissen Leistungsaufwand. Daher ist es üblich, nur die Teile der Konfiguration zu verschlüsseln, die vertrauliche Informationen enthalten. Beispielsweise besteht möglicherweise keine Notwendigkeit, die Konfigurationsabschnitte <compilation> oder <authorization> zu verschlüsseln.
3. Welche Art von Informationen können verschlüsselt werden?
Bevor wir analysieren, wie ASP.NET 2.0-Konfigurationsinformationen verschlüsselt werden, werfen wir zunächst einen Blick darauf, welche Konfigurationsinformationen verschlüsselt werden können. Mithilfe der von .NET Framework 2.0 bereitgestellten Bibliotheken können Entwickler die meisten Konfigurationsabschnitte in einer Web.config- oder machine.config-Datei verschlüsseln. Diese Konfigurationsteile sind XML-Elemente, die untergeordnete Knoten des Elements <configuration> oder <system.web> sind. Die folgende Beispieldatei Web.config enthält beispielsweise drei Konfigurationseinstellungen, die explizit definiert sind als:
<connectionStrings>, <compilation> und <authentication>.
＜?xml version="1.0"?＞
＜configuration xmlns=" http://schemas.microsoft.com/.NetConfiguration/v2.0 "＞
＜connectionStrings＞
＜add name="MembershipConnectionString" ConnectionString="connectionString"/＞
＜/connectionStrings＞
<system.web>
＜compilation debug="true"/＞
＜Authentifizierungsmodus="Formulare" /＞
</system.web>
Jeder dieser Abschnitte kann optional verschlüsselt werden, entweder programmgesteuert oder über aspnet_regiis.exe (ein Befehlszeilentool). Bei der Verschlüsselung wird der verschlüsselte Text direkt in der Konfigurationsdatei gespeichert. Wenn wir beispielsweise den Abschnitt <connectionStrings> oben verschlüsseln würden, könnte die resultierende Web.config-Datei so aussehen: (Hinweis: Aus Platzgründen haben wir einen großen Teil von <CipherValue> weggelassen)
<?xml version= „1,0“?＞
＜configuration xmlns=" http://schemas.microsoft.com/.NetConfiguration/v2.0 "＞
＜connectionStrings configProtectionProvider="DataProtectionConfigurationProvider"＞
<EncryptedData>
<CipherData>
＜CipherValue＞AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAed...GicAlQ==＜/CipherValue＞
＜/CipherData＞
＜/EncryptedData＞
＜/connectionStrings＞
<system.web>
＜compilation debug="true"/＞
＜Authentifizierungsmodus="Formulare" /＞
＜/system.web＞
Darüber hinaus gibt es einige Konfigurationsteile, die Sie mit dieser Technik nicht verschlüsseln können:
· ＜processModel＞
· ＜Laufzeit＞
· ＜mscorlib＞
·＜Startup＞
· ＜system.runtime.remoting＞
· ＜configProtectedData＞
· ＜Satellitenbaugruppen＞
· ＜cryptographySettings＞
· ＜cryptoNameMapping＞
· <cryptoClasses>
Um diese Konfigurationsteile zu verschlüsseln, müssen Sie diese Werte verschlüsseln und in der Registrierung speichern. Es gibt ein Befehlszeilentool aspnet_setreg.exe, das Ihnen bei diesem Vorgang helfen kann; wir werden dieses Tool später in diesem Artikel besprechen.
[Tipp] Der Unterschied zwischen Web.Config und Machine.Config:
Die Datei Web.config gibt die Konfigurationseinstellungen für eine bestimmte Webanwendung an und befindet sich im Stammverzeichnis der Anwendung, während die Datei machine.config alle gespeicherten Konfigurationseinstellungen angibt auf dem Webserver. Konfigurationseinstellungen für die Site im Verzeichnis $WINDOWSDIR$Microsoft.NetFrameworkVersionCONFIG.
4. Verschlüsselungsoptionen
Entwickler können das ASP.NET 2.0-Anbietermodell verwenden, um Konfigurationsabschnittsinformationen zu schützen, wodurch jede Implementierung nahtlos in die API eingebunden werden kann. Das .NET Framework 2.0 bietet zwei integrierte Anbieter zum Schutz von Konfigurationsabschnittsinformationen:
· Windows Data Protection API (DPAPI)-Anbieter (DataProtectionConfigurationProvider): Dieser Anbieter verwendet die integrierte Kryptografietechnologie von Windows, um Konfigurationsabschnitte zu verschlüsseln und zu entschlüsseln. Standardmäßig verwendet dieser Anbieter den nativen Schlüssel. Sie können auch Benutzerschlüssel verwenden, dies erfordert jedoch einige Anpassungen.
· RSA-geschützter Konfigurationsanbieter (RSAProtectedConfigurationProvider): Verwendet RSA-Verschlüsselung mit öffentlichem Schlüssel, um Konfigurationsabschnitte zu verschlüsseln und zu entschlüsseln. Mit diesem Anbieter müssen Sie einen Schlüsselcontainer erstellen, der die öffentlichen und privaten Schlüssel speichert, die zum Ver- und Entschlüsseln von Konfigurationsinformationen verwendet werden. Sie können RSA in einer Farm mit mehreren Servern verwenden, indem Sie exportierbare Schlüsselcontainer erstellen.
Natürlich können Sie bei Bedarf auch Ihren eigenen Anbieter für Schutzeinstellungen erstellen.
In diesem Artikel besprechen wir nur die Verwendung von Schlüsseln auf Maschinenebene mithilfe des DPAPI-Anbieters. Dies ist bei weitem die einfachste Methode, da keine Schlüssel oder Schlüsselcontainer erstellt werden müssen. Der Nachteil besteht natürlich darin, dass eine verschlüsselte Konfigurationsdatei nur auf dem Webserver verwendet werden kann, der die Verschlüsselung überhaupt implementiert hat. Darüber hinaus kann der verschlüsselte Text durch die Verwendung eines Maschinenschlüssels von jeder Site auf dem Webserver entschlüsselt werden.
5. Verschlüsseln Sie den Konfigurationsabschnitt programmgesteuert.
Die Klasse System.Configuration.SectionInformation abstrahiert die Beschreibung eines Konfigurationsabschnitts. Um einen Konfigurationsabschnitt zu verschlüsseln, verwenden Sie einfach die ProtectSection(provider)-Methode der SectionInformation-Klasse und übergeben dabei den Namen des Anbieters, den Sie für die Verschlüsselung verwenden möchten. Um auf einen bestimmten Konfigurationsabschnitt in der Web.config-Datei Ihrer Anwendung zuzugreifen, können Sie die WebConfigurationManager-Klasse (im System.Web.Configuration-Namespace) verwenden, um auf Ihre Web.config-Datei zu verweisen, und dann deren GetSection-Methode verwenden. Die (sectionName)-Methode gibt a zurück ConfigurationSection-Instanz. Schließlich können Sie ein SectionInformation-Objekt über die SectionInformation-Eigenschaft der ConfigurationSection-Instanz abrufen.
Nachfolgend veranschaulichen wir das Problem anhand eines einfachen Codebeispiels:
privatevoid ProtectSection(string sectionName, string Provider)
{
Konfigurationskonfiguration = WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.GetSection(sectionName);
if (section != null &&!section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection(provider);
config.Save();
}
}
private void UnProtectSection(string sectionName) {
Konfigurationskonfiguration =WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.GetSection n(sectionName);
if (section != null && section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
Sie können diese ProtectSection(sectionName, Provider)-Methode von einer ASP.NET-Seite aus aufrufen. Die entsprechenden Parameter sind ein Abschnittsname (z. B. „connectionStrings“) und ein Provider (z. B. „DataProtectionConfigurationProvider“). Außerdem wird die Datei „Web.config“ geöffnet, auf die verwiesen wird In diesem Abschnitt wird die ProtectSection(provider)-Methode des SectionInformation-Objekts aufgerufen und schließlich die Konfigurationsänderungen gespeichert.
Andererseits implementiert die UnProtectSection(Provider)-Methode die Entschlüsselung eines bestimmten Konfigurationsabschnitts. Hier muss nur der zu entschlüsselnde Abschnitt übergeben werden – wir müssen den Anbieter nicht belästigen, da diese Informationen bereits im Tag gespeichert sind, der den verschlüsselten Abschnitt begleitet (d. h. im Abschnitt <connectionStrings> im obigen Beispiel). welches verschlüsselt ist. Später enthält es den Anbieter: <connectionStringsconfigProtectionProvider="DataProtectionConfigurationProvider">).
Denken Sie daran, dass ASP.NET die Daten nach der Verschlüsselung automatisch von einer ASP.NET-Seite entschlüsselt (d. h. beim Lesen der Verbindungszeichenfolgeninformationen aus einem SqlDataSource-Steuerelement oder programmgesteuert über ConfigurationManager.ConnectionStrings[connStringName].ConnectionString). Verbindungszeichenfolge und gibt einen Klartextwert zurück. Mit anderen Worten: Sie müssen Ihren Code nach der Implementierung der Verschlüsselung überhaupt nicht ändern. Ziemlich cool, oder?
Auf der aus diesem Artikel heruntergeladenen ASP.NET 2.0-Beispielwebsite finden Sie eine Beispielseite, auf der die Web.config-Datei der Website angezeigt wird, die über ein mehrzeiliges Textfeld und entsprechende Websteuerungsschaltflächen für die Verschlüsselungskonfiguration verfügt Datei. In diesem Beispiel werden auch die oben besprochenen Methoden ProtectSection() und UnProtectSection() verwendet.
6. Verwenden Sie das Befehlszeilentool aspnet_regiis.exe.
Sie können auch das Befehlszeilentool aspnet_regiis.exe verwenden, um den Konfigurationsteil der Web.config-Datei zu verschlüsseln und zu entschlüsseln. Sie finden dies im Ordner „%WINDOWSDIR%Microsoft.Net“. Verzeichnis „Frameworkversion“. Um einen Abschnitt in der Web.config-Datei zu verschlüsseln, können Sie den DPAPI-Maschinenschlüssel in diesem Befehlszeilentool wie folgt verwenden:
Eine gängige Form der Verschlüsselung einer Web.config-Datei für eine bestimmte Website:
aspnet_regiis.exe -pef Abschnitt physisches_Verzeichnis – prov-Anbieter
oder:
aspnet_regiis.exe -pe section -app virtual_directory -prov
Eine bestimmte Instanz des Anbieters, die die Web.config-Datei einer bestimmten Website verschlüsselt:
aspnet_regiis.exe -pef „connectionStrings“ „C:InetpubwwwrootMySite“ -prov " DataProtectionConfigurationProvider"
oder:
aspnet_regiis.exe -pe "connectionStrings" -app "/MySite" -prov "DataProtectionConfigurationProvider"
Eine gängige Form zum Entschlüsseln der Web.config-Datei einer bestimmten Website:
aspnet_regiis.exe -pdf Abschnitt physisches_Verzeichnis
oder:
aspnet_regiis. exe -pd Abschnitt -app virtual_directory
Spezifisches Beispiel für die Entschlüsselung der Web.config-Datei einer bestimmten Website:
aspnet_regiis.exe -pdf "connectionStrings" "C:InetpubwwwrootMySite"
oder:
Sie können auch angeben, dass aspnet_regiis.exe ausgeführt wird machine.config Dateiverschlüsselung/-entschlüsselung.
[Tipp] Konfigurationseinstellungen in ASP.NET Version 1.x verschlüsseln
Um Konfigurationseinstellungen in ASP.NET Version 1.x zu schützen, müssen Entwickler vertrauliche Einstellungen in der Registrierung des Webservers verschlüsseln und speichern und einen „starken“ Schlüsselspeicher verwenden Verfahren. Anstatt verschlüsselte Inhalte zu speichern (wie in ASP.NET 2.0), enthält die Konfigurationsdatei lediglich einen Verweis auf den Registrierungsschlüssel, in dem der verschlüsselte Wert gespeichert ist. Zum Beispiel:
<identity impersonate="true"
userName="registry:HKLMSOFTWAREMY_SECURE_APPidentityASPNET_SETREG,userName"
password="registry:HKLMSOFTWAREMY_SECURE_APPidentityASPNET_SETREG,password" />
Microsoft stellt Entwicklern das Befehlszeilentool aspnet_setreg.exe zur Verfügung, um vertrauliche Konfigurationsinformationen zu verschlüsseln und in einen „sicheren“ Registrierungseintrag zu verschieben. Leider funktioniert dieses Tool nur bei bestimmten Konfigurationseinstellungen. Im Gegensatz dazu ermöglicht ASP.NET 2.0 die Verschlüsselung jedes Konfigurationsabschnitts.
Weitere Informationen zur Verwendung von aspnet_setreg.exe in einer ASP.NET 1.x-Anwendung finden Sie unter KB#32990 auf MSDN. Leider kann dieses Befehlszeilenprogramm nur vordefinierte Abschnitte in Konfigurationseinstellungen verschlüsseln und erlaubt Ihnen nicht, Datenbankverbindungszeichenfolgen und andere vertrauliche Informationen, die Sie selbst hinzufügen, zu verschlüsseln.
7. Fazit
In diesem Artikel haben wir gelernt, wie man die verschiedenen Verschlüsselungsoptionen von ASP.NET 2.0 verwendet, um Konfigurationsabschnittsinformationen zu schützen. Außerdem haben wir besprochen, wie man Programmiertechniken und aspnet_regiis.exe verwendet, um den Konfigurationsabschnitt in Web.config zu verschlüsseln . Der Schutz Ihrer sensiblen Konfigurationseinstellungen trägt dazu bei, dass Ihre Website schwieriger zu hacken ist, da es schwieriger wird, sensible Konfigurationseinstellungen zu entdecken. ASP.NET 2.0 bietet bereits heute eine relativ einfache Ver- und Entschlüsselungstechnologie, und es gibt keinen Grund für Entwickler, diese Methode nicht zum Schutz Ihrer sensiblen Konfigurationseinstellungen zu verwenden.