Schützen von Verbindungszeichenfolgen und anderen Konfigurationsinformationen (C#)
von Scott Mitchell
Eine ASP.NET Anwendung speichert in der Regel Konfigurationsinformationen in einer Web.config-Datei. Einige dieser Informationen sind vertraulich und garantieren Schutz. Standardmäßig wird diese Datei nicht einem Websitebesucher bereitgestellt, aber ein Administrator oder Hacker erhält möglicherweise Zugriff auf das Dateisystem des Webservers und anzeigen den Inhalt der Datei. In diesem Lernprogramm lernen wir, dass ASP.NET 2.0 es uns ermöglicht, vertrauliche Informationen durch Verschlüsseln von Abschnitten der Web.config-Datei zu schützen.
Einführung
Konfigurationsinformationen für ASP.NET Anwendungen werden häufig in einer XML-Datei mit dem Namen Web.config
gespeichert. Im Laufe dieser Lernprogramme haben wir die Web.config
wenigen Male aktualisiert. Beim Erstellen des Northwind
typierten DataSets im ersten Lernprogramm wurden z. B. Verbindungszeichenfolge Informationen automatisch im <connectionStrings>
Abschnitt hinzugefügtWeb.config
. Später haben wir im Lernprogramm "Gestaltungsvorlagen" und "Websitenavigation " manuell aktualisiert Web.config
und ein <pages>
Element hinzugefügt, das angibt, dass alle ASP.NET Seiten in unserem Projekt das DataWebControls
Design verwenden sollten.
Da Web.config
vertrauliche Daten wie Verbindungszeichenfolge enthalten können, ist es wichtig, dass die Inhalte Web.config
geschützt und vor nicht autorisierten Betrachtern verborgen bleiben. Standardmäßig wird jede HTTP-Anforderung an eine Datei mit der .config
Erweiterung vom modul ASP.NET behandelt, das die Meldung "Dieser Typ von Seite" wird in Abbildung 1 nicht bereitgestellt . Dies bedeutet, dass Besucher Ihre Web.config
Dateiinhalte nicht anzeigen können, indem sie einfach die Adressleiste ihres Browsers eingeben http://www.YourServer.com/Web.config .
Abbildung 1: Besuch Web.config
über einen Browser Gibt einen Typ der Seite zurück, der nicht bereitgestellt wird (Klicken Sie, um das Bild in voller Größe anzuzeigen)
Aber was geschieht, wenn ein Angreifer einen anderen Exploit finden kann, der es ihr ermöglicht, Ihre Web.config
Dateiinhalte anzuzeigen? Was könnte ein Angreifer mit diesen Informationen tun, und welche Schritte können unternommen werden, um die vertraulichen Informationen Web.config
weiter zu schützen? Glücklicherweise enthalten die meisten Abschnitte in Web.config
den meisten Abschnitten keine vertraulichen Informationen. Welchen Schaden kann ein Angreifer verrichten, wenn er den Namen des standarddesigns kennt, das von Ihren ASP.NET Seiten verwendet wird?
Bestimmte Web.config
Abschnitte enthalten jedoch vertrauliche Informationen, die Verbindungszeichenfolge, Benutzernamen, Kennwörter, Servernamen, Verschlüsselungsschlüssel usw. enthalten können. Diese Informationen finden Sie in der Regel in den folgenden Web.config
Abschnitten:
<appSettings>
<connectionStrings>
<identity>
<sessionState>
In diesem Lernprogramm befassen wir uns mit Techniken zum Schutz solcher vertraulicher Konfigurationsinformationen. Wie wir sehen, enthält .NET Framework, Version 2.0, ein geschütztes Konfigurationssystem, mit dem ausgewählte Konfigurationsabschnitte programmgesteuert verschlüsselt und entschlüsselt werden.
Hinweis
Dieses Lernprogramm endet mit einem Blick auf die Empfehlungen von Microsoft zum Herstellen einer Verbindung mit einer Datenbank aus einer ASP.NET Anwendung. Zusätzlich zur Verschlüsselung Ihrer Verbindungszeichenfolge können Sie Ihr System härten, indem Sie sicherstellen, dass Sie eine sichere Verbindung mit der Datenbank herstellen.
Schritt 1: Erkunden ASP.NET 2.0 s Protected Configuration Options
ASP.NET 2.0 enthält ein geschütztes Konfigurationssystem zum Verschlüsseln und Entschlüsseln von Konfigurationsinformationen. Dazu gehören Methoden im .NET Framework, die zum programmgesteuerten Verschlüsseln oder Entschlüsseln von Konfigurationsinformationen verwendet werden können. Das geschützte Konfigurationssystem verwendet das Anbietermodell, mit dem Entwickler auswählen können, welche kryptografische Implementierung verwendet wird.
Das .NET Framework wird mit zwei geschützten Konfigurationsanbietern ausgeliefert:
RSAProtectedConfigurationProvider
- verwendet den asymmetrischen RSA-Algorithmus zur Verschlüsselung und Entschlüsselung.DPAPIProtectedConfigurationProvider
– verwendet die Windows Data Protection-API (DPAPI) zur Verschlüsselung und Entschlüsselung.
Da das geschützte Konfigurationssystem das Anbieterentwurfsmuster implementiert, ist es möglich, Ihren eigenen geschützten Konfigurationsanbieter zu erstellen und in Ihre Anwendung einzufügen. Weitere Informationen zu diesem Prozess finden Sie unter Implementieren eines geschützten Konfigurationsanbieters .
Die RSA- und DPAPI-Anbieter verwenden Schlüssel für ihre Verschlüsselungs- und Entschlüsselungsroutinen, und diese Schlüssel können auf Computer- oder Benutzerebene gespeichert werden. Schlüssel auf Computerebene eignen sich ideal für Szenarien, in denen die Webanwendung auf einem eigenen dedizierten Server ausgeführt wird oder mehrere Anwendungen auf einem Server vorhanden sind, die verschlüsselte Informationen freigeben müssen. Schlüssel auf Benutzerebene sind eine sicherere Option in freigegebenen Hostingumgebungen, in denen andere Anwendungen auf demselben Server nicht in der Lage sein sollten, die geschützten Konfigurationsabschnitte Ihrer Anwendung zu entschlüsseln.
In diesem Lernprogramm verwenden unsere Beispiele den DPAPI-Anbieter und Schlüssel auf Computerebene. Genauer gesagt wird die Verschlüsselung des <connectionStrings>
Abschnitts in Web.config
, obwohl das geschützte Konfigurationssystem verwendet werden kann, um die meisten Web.config
Abschnitte zu verschlüsseln. Informationen zur Verwendung von Schlüsseln auf Benutzerebene oder zum Verwenden des RSA-Anbieters finden Sie in den Ressourcen im Abschnitt "Weitere Lesungen" am Ende dieses Lernprogramms.
Hinweis
Die Anbieter und DPAPIProtectedConfigurationProvider
Anbieter RSAProtectedConfigurationProvider
sind in der machine.config
Datei mit den Anbieternamen RsaProtectedConfigurationProvider
bzwDataProtectionConfigurationProvider
. in der Datei registriert. Beim Verschlüsseln oder Entschlüsseln von Konfigurationsinformationen müssen wir den entsprechenden Anbieternamen (RsaProtectedConfigurationProvider
oder DataProtectionConfigurationProvider
) anstelle des tatsächlichen Typnamens (RSAProtectedConfigurationProvider
und DPAPIProtectedConfigurationProvider
). Sie finden die machine.config
Datei im $WINDOWS$\Microsoft.NET\Framework\version\CONFIG
Ordner.
Schritt 2: Programmgesteuertes Verschlüsseln und Entschlüsseln von Konfigurationsabschnitten
Mit einigen Codezeilen können wir einen bestimmten Konfigurationsabschnitt mithilfe eines angegebenen Anbieters verschlüsseln oder entschlüsseln. Der Code muss, wie wir kurz sehen, einfach programmgesteuert auf den entsprechenden Konfigurationsabschnitt verweisen, seine ProtectSection
Methode aufrufen UnprotectSection
und dann die Save
Methode aufrufen, um die Änderungen beizubehalten. Darüber hinaus enthält .NET Framework ein hilfreiches Befehlszeilenprogramm, das Konfigurationsinformationen verschlüsseln und entschlüsseln kann. Wir werden dieses Befehlszeilenprogramm in Schritt 3 untersuchen.
Um den programmgesteuerten Schutz von Konfigurationsinformationen zu veranschaulichen, erstellen wir eine ASP.NET Seite, die Schaltflächen zum Verschlüsseln und Entschlüsseln des <connectionStrings>
Abschnitts Web.config
enthält.
Öffnen Sie zunächst die EncryptingConfigSections.aspx
Seite im AdvancedDAL
Ordner. Ziehen Sie ein TextBox-Steuerelement aus der Toolbox auf den Designer, und legen Sie dessen ID
Eigenschaft auf WebConfigContents
, seine TextMode
Eigenschaft auf MultiLine
, und Rows
seine Width
Eigenschaften auf 95 % bzw. 15. Dieses TextBox-Steuerelement zeigt den Inhalt an, damit Web.config
wir schnell sehen können, ob die Inhalte verschlüsselt sind oder nicht. Natürlich würden Sie in einer echten Anwendung niemals den Inhalt von Web.config
.
Fügen Sie unterhalb des TextBox-Steuerelements zwei Schaltflächensteuerelemente namens EncryptConnStrings
und DecryptConnStrings
. Legen Sie deren Texteigenschaften auf "Verbindungszeichenfolgen verschlüsseln" und "Entschlüsselung von Verbindungszeichenfolgen" fest.
An diesem Punkt sollte ihr Bildschirm ähnlich aussehen wie in Abbildung 2.
Abbildung 2: Hinzufügen von TextBox- und Zwei-Schaltflächen-Websteuerelementen zur Seite (Klicken, um das Bild in voller Größe anzuzeigen)
Als Nächstes müssen wir Code schreiben, der den Inhalt des Web.config
WebConfigContents
TextBox-Steuerelements lädt und anzeigt, wenn die Seite zum ersten Mal geladen wird. Fügen Sie der CodeBehind-Klasse der Seite den folgenden Code hinzu. Dieser Code fügt eine Benannte Methode hinzu DisplayWebConfig
und ruft sie in folgenden Page_Load
Fällen Page.IsPostBack
false
vom Ereignishandler auf:
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;
}
Die DisplayWebConfig
Methode verwendet die File
Klasse, um die Anwendungsdatei Web.config
zu öffnen, die Klasse, um derenStreamReader
Inhalt in eine Zeichenfolge zu lesen, und die Path
Klasse, um den physischen Pfad zur Datei zu Web.config
generieren. Diese drei Klassen befinden sich alle im System.IO
Namespace. Daher müssen Sie oben in der CodeBehind-Klasse eine using
System.IO
Anweisung hinzufügen oder diese Klassennamen System.IO.
alternativ mit präfixieren.
Als Nächstes müssen wir Ereignishandler für die beiden Button-Steuerelemente Click
hinzufügen und den erforderlichen Code zum Verschlüsseln und Entschlüsseln des <connectionStrings>
Abschnitts mithilfe eines Schlüssels auf Computerebene mit dem DPAPI-Anbieter hinzufügen. Doppelklicken Sie im Designer auf die einzelnen Schaltflächen, um einen Click
Ereignishandler in der CodeBehind-Klasse hinzuzufügen, und fügen Sie dann den folgenden Code hinzu:
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();
}
}
Der in den beiden Ereignishandlern verwendete Code ist nahezu identisch. Beide beginnen mit dem Abrufen von Informationen zur aktuellen Anwendungsdatei Web.config
über die WebConfigurationManager
Klasse s-MethodeOpenWebConfiguration
. Diese Methode gibt die Webkonfigurationsdatei für den angegebenen virtuellen Pfad zurück. Als Nächstes <connectionStrings>
wird über die Klasse s-Methode GetSection(sectionName)
auf denConfiguration
Web.config
Dateiabschnitt zugegriffen, der ein ConfigurationSection
Objekt zurückgibt.
Das ConfigurationSection
Objekt enthält eine SectionInformation
Eigenschaft , die zusätzliche Informationen und Funktionen zum Konfigurationsabschnitt bereitstellt. Wie der obige Code zeigt, können wir ermitteln, ob der Konfigurationsabschnitt verschlüsselt ist, indem die Eigenschaft der SectionInformation
IsProtected
Eigenschaft überprüft wird. Darüber hinaus kann der Abschnitt über die SectionInformation
Eigenschaften ProtectSection(provider)
und UnprotectSection
Methoden verschlüsselt oder entschlüsselt werden.
Die ProtectSection(provider)
Methode akzeptiert als Eingabe eine Zeichenfolge, die den Namen des geschützten Konfigurationsanbieters angibt, der beim Verschlüsseln verwendet werden soll. EncryptConnString
Im Button-Ereignishandler übergeben wir DataProtectionConfigurationProvider an die ProtectSection(provider)
Methode, sodass der DPAPI-Anbieter verwendet wird. Die UnprotectSection
Methode kann den Anbieter ermitteln, der zum Verschlüsseln des Konfigurationsabschnitts verwendet wurde und daher keine Eingabeparameter erfordert.
Nach dem Aufrufen der Methode oder der ProtectSection(provider)
Methode müssen Sie die Methode des Configuration
Objekts Save
aufrufen, um die Änderungen UnprotectSection
beizubehalten. Sobald die Konfigurationsinformationen verschlüsselt oder entschlüsselt wurden und die gespeicherten Änderungen gespeichert wurden, rufen DisplayWebConfig
wir auf, um den aktualisierten Web.config
Inhalt in das TextBox-Steuerelement zu laden.
Nachdem Sie den obigen Code eingegeben haben, testen Sie ihn, indem Sie die EncryptingConfigSections.aspx
Seite über einen Browser besuchen. Zunächst sollte eine Seite angezeigt werden, auf der der Inhalt Web.config
des <connectionStrings>
Abschnitts im Nur-Text-Format aufgelistet wird (siehe Abbildung 3).
Abbildung 3: Hinzufügen von TextBox- und Zwei-Schaltflächen-Websteuerelementen zur Seite (Klicken, um das Bild in voller Größe anzuzeigen)
Klicken Sie nun auf die Schaltfläche "Verbindungszeichenfolgen verschlüsseln". Wenn die Anforderungsüberprüfung aktiviert ist, erzeugt das aus dem WebConfigContents
TextBox zurückgepostete Markup einen HttpRequestValidationException
, der die Meldung anzeigt, ein potenziell gefährlicher Request.Form
Wert wurde vom Client erkannt. Die Anforderungsüberprüfung, die in ASP.NET 2.0 standardmäßig aktiviert ist, verbietet Postbacks, die nicht codiertes HTML enthalten, und wurde entwickelt, um Skripteinfügungsangriffe zu verhindern. Diese Überprüfung kann auf Seiten- oder Anwendungsebene deaktiviert werden. Um sie für diese Seite zu false
deaktivieren, legen Sie die ValidateRequest
Einstellung in der @Page
Direktive fest. Die @Page
Direktive befindet sich oben im deklarativen Markup der Seite.
<%@ Page ValidateRequest="False" ... %>
Weitere Informationen zur Anforderungsüberprüfung, zum Zweck, zum Deaktivieren auf Seiten- und Anwendungsebene sowie zum HTML-Codieren von Markup finden Sie unter Anforderungsüberprüfung – Verhindern von Skriptangriffen.
Nachdem Sie die Anforderungsüberprüfung für die Seite deaktiviert haben, klicken Sie erneut auf die Schaltfläche "Verbindungszeichenfolgen verschlüsseln". Bei postback wird auf die Konfigurationsdatei zugegriffen und ihr <connectionStrings>
Abschnitt mit dem DPAPI-Anbieter verschlüsselt. Das TextBox-Objekt wird dann aktualisiert, um den neuen Web.config
Inhalt anzuzeigen. Wie in Abbildung 4 dargestellt, werden die <connectionStrings>
Informationen jetzt verschlüsselt.
Abbildung 4: Klicken auf die Schaltfläche "Verbindungszeichenfolgen verschlüsseln" verschlüsselt den <connectionString>
Abschnitt (Klicken, um das Bild in voller Größe anzuzeigen)
Der auf meinem Computer generierte verschlüsselte <connectionStrings>
Abschnitt folgt, obwohl einige inhalte im <CipherData>
Element aus Platzgründen entfernt wurden:
<connectionStrings
configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>AQAAANCMnd8BFdERjHoAwE/...zChw==</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>
Hinweis
Das <connectionStrings>
Element gibt den Anbieter an, der zum Ausführen der Verschlüsselung (DataProtectionConfigurationProvider
) verwendet wird. Diese Informationen werden von der UnprotectSection
Methode verwendet, wenn auf die Schaltfläche "Verbindungszeichenfolgen entschlüsseln" geklickt wird.
Wenn auf die Verbindungszeichenfolge Informationen zugegriffen Web.config
wird – entweder anhand von Code, den wir schreiben, aus einem SqlDataSource-Steuerelement oder dem automatisch generierten Code aus den TableAdapters in unseren Typed DataSets – wird er automatisch entschlüsselt. Kurz gesagt, wir müssen keinen zusätzlichen Code oder eine zusätzliche Logik hinzufügen, um den verschlüsselten <connectionString>
Abschnitt zu entschlüsseln. Um dies zu veranschaulichen, besuchen Sie zu diesem Zeitpunkt eines der früheren Lernprogramme, z. B. das Lernprogramm zum einfachen Anzeigen aus dem Abschnitt "Einfache Berichterstellung" (~/BasicReporting/SimpleDisplay.aspx
). Wie in Abbildung 5 dargestellt, funktioniert das Lernprogramm genau wie erwartet, was darauf hinweist, dass die verschlüsselten Verbindungszeichenfolge Informationen von der ASP.NET Seite automatisch entschlüsselt werden.
Abbildung 5: Die Datenzugriffsschicht entschlüsselt automatisch die Verbindungszeichenfolgeninformationen (Klicken, um das Bild in voller Größe anzuzeigen)
Klicken Sie auf die Schaltfläche "Verbindungszeichenfolgen entschlüsseln", um den <connectionStrings>
Abschnitt wieder auf die Nur-Text-Darstellung zurückzuverwenden. Bei postback sollten die Verbindungszeichenfolge im Web.config
Nur-Text-Format angezeigt werden. An diesem Punkt sollte Ihr Bildschirm wie beim ersten Besuch dieser Seite aussehen (siehe Abbildung 3).
Schritt 3: Verschlüsseln von Konfigurationsabschnitten mithilfe von aspnet_regiis.exe
Das .NET Framework enthält eine Vielzahl von Befehlszeilentools im $WINDOWS$\Microsoft.NET\Framework\version\
Ordner. Im Lernprogramm zum Verwenden von SQL-Cacheabhängigkeiten haben wir beispielsweise die Verwendung des aspnet_regsql.exe
Befehlszeilentools untersucht, um die für SQL-Cacheabhängigkeiten erforderliche Infrastruktur hinzuzufügen. Ein weiteres nützliches Befehlszeilentool in diesem Ordner ist das ASP.NET IIS-Registrierungstool (aspnet_regiis.exe
). Wie der Name schon sagt, wird das ASP.NET IIS-Registrierungstool in erster Linie verwendet, um eine ASP.NET 2.0-Anwendung mit dem Webserver auf professioneller Ebene von Microsoft, IIS, zu registrieren. Zusätzlich zu den IIS-bezogenen Features kann das ASP.NET IIS-Registrierungstool auch verwendet werden, um die angegebenen Konfigurationsabschnitte zu verschlüsseln oder zu entschlüsseln.Web.config
Die folgende Anweisung zeigt die allgemeine Syntax zum Verschlüsseln eines Konfigurationsabschnitts mit dem aspnet_regiis.exe
Befehlszeilentool:
aspnet_regiis.exe -pef section physical_directory -prov provider
Abschnitt ist der Konfigurationsabschnitt zum Verschlüsseln (z. B. connectionStrings), die physical_directory ist der vollständige, physische Pfad zum Stammverzeichnis der Webanwendung, und der Anbieter ist der Name des zu verwendenden geschützten Konfigurationsanbieters (z. B. DataProtectionConfigurationProvider). Alternativ können Sie, wenn die Webanwendung in IIS registriert ist, den virtuellen Pfad anstelle des physischen Pfads mithilfe der folgenden Syntax eingeben:
aspnet_regiis.exe -pe section -app virtual_directory -prov provider
Im folgenden aspnet_regiis.exe
Beispiel wird der <connectionStrings>
Abschnitt mithilfe des DPAPI-Anbieters mit einem Schlüssel auf Computerebene verschlüsselt:
aspnet_regiis.exe -pef
"connectionStrings" "C:\Websites\ASPNET_Data_Tutorial_73_CS"
-prov "DataProtectionConfigurationProvider"
Ebenso kann das aspnet_regiis.exe
Befehlszeilentool zum Entschlüsseln von Konfigurationsabschnitten verwendet werden. Anstatt den -pef
Schalter zu verwenden, verwenden -pdf
Sie (oder anstelle von -pe
, verwenden -pd
). Beachten Sie außerdem, dass der Anbietername beim Entschlüsseln nicht erforderlich ist.
aspnet_regiis.exe -pdf section physical_directory
-- or --
aspnet_regiis.exe -pd section -app virtual_directory
Hinweis
Da wir den DPAPI-Anbieter verwenden, der Schlüssel verwendet, die für den Computer spezifisch sind, müssen Sie von demselben Computer ausgeführt aspnet_regiis.exe
werden, auf dem die Webseiten bereitgestellt werden. Wenn Sie z. B. dieses Befehlszeilenprogramm von Ihrem lokalen Entwicklungscomputer ausführen und dann die verschlüsselte Web.config-Datei auf den Produktionsserver hochladen, kann der Produktionsserver die Verbindungszeichenfolge Informationen nicht entschlüsseln, da sie mithilfe von Schlüsseln verschlüsselt wurde, die speziell für Ihren Entwicklungscomputer spezifisch sind. Der RSA-Anbieter hat diese Einschränkung nicht, da es möglich ist, die RSA-Schlüssel auf einen anderen Computer zu exportieren.
Grundlegendes zu Datenbankauthentifizierungsoptionen
Bevor eine Anwendung eine Microsoft SQL Server-Datenbank ausstellen SELECT
kann, INSERT
UPDATE
oder DELETE
abfragen kann, muss die Datenbank zuerst den Anforderer identifizieren. Dieser Prozess wird als Authentifizierung bezeichnet, und SQL Server bietet zwei Authentifizierungsmethoden:
- Windows-Authentifizierung – der Prozess, unter dem die Anwendung ausgeführt wird, wird für die Kommunikation mit der Datenbank verwendet. Beim Ausführen einer ASP.NET Anwendung über Visual Studio 2005 s ASP.NET Development Server setzt die ASP.NET Anwendung die Identität des aktuell angemeldeten Benutzers voraus. Bei ASP.NET Anwendungen auf Microsoft Internet Information Server (IIS) gehen ASP.NET Anwendungen in der Regel von der Identität
domainName``\MachineName
oderdomainName``\NETWORK SERVICE
, obwohl dies angepasst werden kann. - SQL-Authentifizierung – Eine Benutzer-ID und Kennwortwerte werden als Anmeldeinformationen für die Authentifizierung angegeben. Bei der SQL-Authentifizierung werden die Benutzer-ID und das Kennwort im Verbindungszeichenfolge bereitgestellt.
Windows-Authentifizierung wird gegenüber der SQL-Authentifizierung bevorzugt, da sie sicherer ist. Mit Windows-Authentifizierung ist die Verbindungszeichenfolge frei von einem Benutzernamen und Kennwort, und wenn sich der Webserver und Datenbankserver auf zwei verschiedenen Computern befinden, werden die Anmeldeinformationen nicht über das Netzwerk in Nur-Text gesendet. Bei der SQL-Authentifizierung werden die Authentifizierungsanmeldeinformationen jedoch im Verbindungszeichenfolge hartcodiert und vom Webserver in Nur-Text an den Datenbankserver übertragen.
Diese Lernprogramme haben Windows-Authentifizierung verwendet. Sie können feststellen, welcher Authentifizierungsmodus verwendet wird, indem Sie die Verbindungszeichenfolge überprüfen. Die Verbindungszeichenfolge Web.config
für unsere Lernprogramme war:
Data Source=.\SQLEXPRESS; AttachDbFilename=|DataDirectory|\NORTHWND.MDF; Integrated Security=True; User Instance=True
Die integrierte Sicherheit =True und das Fehlen eines Benutzernamens und Kennworts deuten darauf hin, dass Windows-Authentifizierung verwendet wird. In einigen Verbindungszeichenfolge wird der Begriff Trusted Connection=Yes or Integrated Security=SSPI anstelle von Integrated Security=True verwendet, aber alle drei geben die Verwendung von Windows-Authentifizierung an.
Das folgende Beispiel zeigt eine Verbindungszeichenfolge, die die SQL-Authentifizierung verwendet. $CREDENTIAL_PLACEHOLDER$
ist ein Platzhalter für das Kennwortschlüssel-Wert-Paar. Beachten Sie, dass die Anmeldeinformationen in die Verbindungszeichenfolge eingebettet sind:
Server=serverName; Database=Northwind; uid=userID; $CREDENTIAL_PLACEHOLDER$
Stellen Sie sich vor, dass ein Angreifer ihre Anwendungsdatei Web.config
anzeigen kann. Wenn Sie die SQL-Authentifizierung verwenden, um eine Verbindung mit einer Datenbank herzustellen, auf die über das Internet zugegriffen werden kann, kann der Angreifer diese Verbindungszeichenfolge verwenden, um eine Verbindung mit Ihrer Datenbank über SQL Management Studio oder von ASP.NET Seiten auf ihrer eigenen Website herzustellen. Um diese Bedrohung zu mindern, verschlüsseln Sie die Verbindungszeichenfolge Informationen mithilfe Web.config
des geschützten Konfigurationssystems.
Hinweis
Weitere Informationen zu den verschiedenen Typen der Authentifizierung, die in SQL Server verfügbar sind, finden Sie unter Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication. Weitere Verbindungszeichenfolge Beispiele zur Veranschaulichung der Unterschiede zwischen Windows- und SQL-Authentifizierungssyntax finden Sie unter ConnectionStrings.com.
Zusammenfassung
Standardmäßig können Dateien mit einer .config
Erweiterung in einer ASP.NET-Anwendung nicht über einen Browser aufgerufen werden. Diese Dateitypen werden nicht zurückgegeben, da sie möglicherweise vertrauliche Informationen enthalten, z. B. Datenbank-Verbindungszeichenfolge, Benutzernamen und Kennwörter usw. Das geschützte Konfigurationssystem in .NET 2.0 trägt dazu bei, vertrauliche Informationen weiter zu schützen, indem bestimmte Konfigurationsabschnitte verschlüsselt werden können. Es gibt zwei integrierte geschützte Konfigurationsanbieter: einen, der den RSA-Algorithmus verwendet und eine, die die Windows Data Protection API (DPAPI) verwendet.
In diesem Lernprogramm haben wir uns angesehen, wie Konfigurationseinstellungen mithilfe des DPAPI-Anbieters verschlüsselt und entschlüsselt werden. Dies kann sowohl programmgesteuert erfolgen, wie wir in Schritt 2 gesehen haben, als auch über das aspnet_regiis.exe
Befehlszeilentool, das in Schritt 3 behandelt wurde. Weitere Informationen zur Verwendung von Schlüsseln auf Benutzerebene oder zum Verwenden des RSA-Anbieters finden Sie in den Ressourcen im Abschnitt "Weiteres Lesen".
Glückliche Programmierung!
Weitere nützliche Informationen
Weitere Informationen zu den in diesem Lernprogramm erläuterten Themen finden Sie in den folgenden Ressourcen:
- Erstellen sicherer ASP.NET Anwendung: Authentifizierung, Autorisierung und sichere Kommunikation
- Verschlüsseln von Konfigurationsinformationen in ASP.NET 2.0-Anwendungen
- Verschlüsseln von
Web.config
Werten in ASP.NET 2,0 - Vorgehensweise: Verschlüsseln von Konfigurationsabschnitten in ASP.NET 2.0 mithilfe von DPAPI
- Gewusst wie: Verschlüsseln von Konfigurationsabschnitten in ASP.NET 2.0 mithilfe von RSA
- Die Konfigurations-API in .NET 2.0
- Windows Data Protection
Zum Autor
Scott Mitchell, Autor von sieben ASP/ASP.NET Büchern und Gründer von 4GuysFromRolla.com, arbeitet seit 1998 mit Microsoft Web Technologies zusammen. Scott arbeitet als unabhängiger Berater, Trainer und Schriftsteller. Sein neuestes Buch ist Sams Teach Yourself ASP.NET 2.0 in 24 Stunden. Er kann über mitchell@4GuysFromRolla.com seinen Blog erreicht werden, der unter .http://ScottOnWriting.NET
Besonderer Dank an
Diese Lernprogrammreihe wurde von vielen hilfreichen Prüfern überprüft. Leitende Prüfer für dieses Lernprogramm waren Teresa Murphy und Randy Schmidt. Möchten Sie meine bevorstehenden MSDN-Artikel überprüfen? Wenn dies der Fall ist, legen Sie mir eine Zeile bei mitchell@4GuysFromRolla.com.