Verbindingsreeksen en andere configuratiegegevens beveiligen (C#)

door Scott Mitchell

PDF downloaden

Een ASP.NET toepassing slaat doorgaans configuratiegegevens op in een Web.config bestand. Sommige van deze informatie zijn gevoelig en rechtvaardigen bescherming. Dit bestand wordt standaard niet aan een bezoeker van een website aangeboden, maar een beheerder of hacker kan toegang krijgen tot het bestandssysteem van de webserver en de inhoud van het bestand bekijken. In deze zelfstudie leren we dat ASP.NET 2.0 ons in staat stelt om gevoelige informatie te beveiligen door secties van het Web.config-bestand te versleutelen.

Introductie

Configuratie-informatie voor ASP.NET toepassingen wordt meestal opgeslagen in een XML-bestand met de naam Web.config. In de loop van deze zelfstudies hebben we de Web.config paar keer bijgewerkt. Bij het maken van de Northwind Typed DataSet in de eerste tutorial, bijvoorbeeld, is informatie over verbindingsreeksen automatisch toegevoegd aan Web.config de <connectionStrings> sectie. Verderop in de zelfstudie Basispagina's en Sitenavigatie hebben we handmatig een element toegevoegd Web.config<pages> dat aangeeft dat alle ASP.NET pagina's in ons project het DataWebControls thema moeten gebruiken.

Aangezien Web.config gevoelige gegevens, zoals verbindingsreeksen, kunnen bevatten, is het belangrijk dat de inhoud van Web.config veilig en verborgen blijft voor onbevoegde kijkers. Standaard wordt elke HTTP-aanvraag naar een bestand met de .config-extensie verwerkt door de ASP.NET-engine, die het bericht 'Dit type pagina wordt niet bediend' retourneert, zoals getoond in afbeelding 1. Dit betekent dat bezoekers de inhoud van uw Web.config bestand niet kunnen bekijken door simpelweg de adresbalk van hun browser in te voeren http://www.YourServer.com/Web.config .

Afbeelding 1: Bezoeken Web.config via een browser retourneert een bericht dat dit type pagina niet wordt weergegeven (Klik om de afbeelding op volledige grootte weer te geven)

Maar wat als een aanvaller een andere aanval kan vinden waarmee ze de inhoud van uw Web.config bestand kan bekijken? Wat kan een aanvaller doen met deze informatie en welke stappen kunnen worden ondernomen om gevoelige informatie verder te beveiligen?Web.config Gelukkig bevatten de meeste secties Web.config geen gevoelige informatie. Welke schade kan een aanvaller veroorzaken als hij de naam weet van het standaardthema dat door uw ASP.NET pagina's wordt gebruikt?

Bepaalde Web.config secties bevatten echter gevoelige informatie die verbindingsreeksen, gebruikersnamen, wachtwoorden, servernamen, versleutelingssleutels enzovoort kan bevatten. Deze informatie vindt u doorgaans in de volgende Web.config secties:

• <appSettings>
• <connectionStrings>
• <identity>
• <sessionState>

In deze zelfstudie bekijken we technieken voor het beveiligen van dergelijke gevoelige configuratiegegevens. Zoals we zien, bevat .NET Framework versie 2.0 een beveiligd configuratiesysteem waarmee geselecteerde configuratiesecties programmatisch worden versleuteld en ontsleuteld.

Opmerking

Deze zelfstudie eindigt met de aanbevelingen van Microsoft voor het maken van verbinding met een database vanuit een ASP.NET-toepassing. Naast het versleutelen van uw verbindingsreeksen kunt u uw systeem beveiligen door ervoor te zorgen dat u verbinding maakt met de database op een veilige manier.

Stap 1: ASP.NET 2.0 s Beveiligde configuratieopties verkennen

ASP.NET 2.0 bevat een beveiligd configuratiesysteem voor het versleutelen en ontsleutelen van configuratiegegevens. Dit omvat methoden in het .NET Framework die kunnen worden gebruikt voor het programmatisch versleutelen of ontsleutelen van configuratiegegevens. Het beveiligde configuratiesysteem maakt gebruik van het providermodel waarmee ontwikkelaars kunnen kiezen welke cryptografische implementatie wordt gebruikt.

Het .NET Framework wordt geleverd met twee beveiligde configuratieproviders:

• RSAProtectedConfigurationProvider - gebruikt het asymmetrische RSA-algoritme voor versleuteling en ontsleuteling.
• DPAPIProtectedConfigurationProvider - maakt gebruik van de Windows Data Protection API (DPAPI) voor versleuteling en ontsleuteling.

Omdat het beveiligde configuratiesysteem het ontwerppatroon van de provider implementeert, is het mogelijk om uw eigen beveiligde configuratieprovider te maken en deze in uw toepassing aan te sluiten. Zie Een beveiligde configuratieprovider implementeren voor meer informatie over dit proces.

De RSA- en DPAPI-providers gebruiken sleutels voor hun versleutelings- en ontsleutelingsroutines. Deze sleutels kunnen worden opgeslagen op computer- of gebruikersniveau. Sleutels op machineniveau zijn ideaal voor scenario's waarin de webtoepassing wordt uitgevoerd op een eigen toegewezen server of als er meerdere toepassingen zijn op een server die versleutelde gegevens moeten delen. Sleutels op gebruikersniveau zijn een veiligere optie in gedeelde hostingomgevingen waar andere toepassingen op dezelfde server de beveiligde configuratiesecties van uw toepassing niet mogen ontsleutelen.

In deze zelfstudie gebruiken onze voorbeelden de DPAPI-provider en sleutels op machineniveau. In het bijzonder kijken we naar het versleutelen van de <connectionStrings> sectie in Web.config, hoewel het beveiligde configuratiesysteem kan worden gebruikt om de meeste Web.config secties te versleutelen. Raadpleeg de bronnen in de sectie Meer lezen aan het einde van deze zelfstudie voor informatie over het gebruik van sleutels op gebruikersniveau of het gebruik van de RSA-provider.

Opmerking

De providers RSAProtectedConfigurationProvider en DPAPIProtectedConfigurationProvider worden geregistreerd in het machine.config bestand met de providernamen RsaProtectedConfigurationProvider en DataProtectionConfigurationProvider, respectievelijk. Bij het versleutelen of ontsleutelen van configuratiegegevens moeten we de juiste providernaam (RsaProtectedConfigurationProvider of DataProtectionConfigurationProvider) opgeven in plaats van de werkelijke typenaam (RSAProtectedConfigurationProvider en DPAPIProtectedConfigurationProvider). U vindt het machine.config bestand in de $WINDOWS$\Microsoft.NET\Framework\version\CONFIG map.

Stap 2: Configuratiesecties programmatisch versleutelen en ontsleutelen

Met een paar regels code kunnen we een bepaalde configuratiesectie versleutelen of ontsleutelen met behulp van een opgegeven provider. De code moet, zoals we binnenkort zullen zien, gewoon programmatisch verwijzen naar de juiste configuratiesectie, zijn ProtectSection of UnprotectSection methode aanroepen en vervolgens zijn Save methode aanroepen om de wijzigingen te bewaren. Bovendien bevat het .NET Framework een nuttig opdrachtregelprogramma waarmee configuratiegegevens kunnen worden versleuteld en ontsleuteld. We verkennen dit opdrachtregelprogramma in stap 3.

Ter illustratie van programmatisch beveiligen van configuratiegegevens, maken we een ASP.NET pagina met knoppen voor het versleutelen en ontsleutelen van de <connectionStrings> sectie in Web.config.

Open eerst de EncryptingConfigSections.aspx pagina in de AdvancedDAL map. Sleep een besturingselement Tekstvak van de Werkset naar de Ontwerper, stel de ID eigenschap in op WebConfigContents, de TextMode eigenschap ervan op MultiLine en stel de Width en Rows eigenschappen respectievelijk in op 95% en 15. Met dit besturingselement Tekstvak wordt de inhoud van Web.config weergegeven, zodat we snel kunnen zien of de inhoud is versleuteld of niet. Natuurlijk zou u in een echte toepassing nooit de inhoud van Web.config willen weergeven.

Voeg onder het tekstvak twee knopbesturingselementen toe met de naam EncryptConnStrings en DecryptConnStrings. Stel hun teksteigenschappen in op "Verbindingsreeksen Versleutelen" en "Verbindingsreeksen Ontsleutelen".

Op dit moment moet uw scherm er ongeveer uitzien als afbeelding 2.

Afbeelding 2: Een tekstvak en webbesturingselementen met twee knoppen toevoegen aan de pagina (klik om de afbeelding op volledige grootte weer te geven)

Vervolgens moeten we code schrijven waarmee de inhoud van Web.config in het WebConfigContents tekstvak wordt geladen en weergegeven wanneer de pagina voor het eerst geladen wordt. Voeg de volgende code toe aan de code-behind-klasse van de pagina. Met deze code wordt een methode met de naam DisplayWebConfig toegevoegd en aangeroepen vanuit de Page_Load eventhandler wanneer Page.IsPostBack: false

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;
}

De DisplayWebConfig methode gebruikt de File klasse om het toepassingsbestand Web.config te openen, de klasse om de StreamReader inhoud ervan in een tekenreeks te lezen en de Path klasse om het fysieke pad naar het Web.config bestand te genereren. Deze drie klassen zijn allemaal te vinden in de System.IO naamruimte. Daarom moet u een usingSystem.IO instructie toevoegen aan het begin van de code-behind-klasse of, als alternatief, deze klassenamen vooraf laten gaan door System.IO. .

Vervolgens moeten we gebeurtenis-handlers toevoegen voor de twee knopbesturingselementgebeurtenissen Click en de benodigde code toevoegen om de <connectionStrings> sectie te versleutelen en ontsleutelen met behulp van een sleutel op machineniveau met de DPAPI-provider. Dubbelklik in de ontwerpfunctie op elk van de knoppen om een Click gebeurtenis-handler toe te voegen in de code-behind-klasse en voeg vervolgens de volgende code toe:

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();
        }
}

De code die in de twee gebeurtenis-handlers wordt gebruikt, is bijna identiek. Ze beginnen met het ophalen van informatie over het huidige toepassingsbestand Web.config via de WebConfigurationManager klassemethodeOpenWebConfiguration. Met deze methode wordt het webconfiguratiebestand voor het opgegeven virtuele pad geretourneerd. Vervolgens wordt de Web.config bestandssectie <connectionStrings> geopend via de Configuration klasseGetSection(sectionName) methode, die een ConfigurationSection object retourneert.

Het ConfigurationSection object bevat een SectionInformation eigenschap die aanvullende informatie en functionaliteit biedt met betrekking tot de configuratiesectie. Zoals de code hierboven laat zien, kunnen we bepalen of de configuratiesectie is versleuteld door de eigenschap SectionInformation van de eigenschap IsProtected te controleren. Bovendien kan de sectie worden versleuteld of ontsleuteld via de SectionInformation eigenschap s ProtectSection(provider) en UnprotectSection methoden.

De ProtectSection(provider) methode accepteert als invoer een tekenreeks die de naam van de beveiligde configuratieprovider opgeeft die moet worden gebruikt bij het versleutelen. In de EncryptConnString eventhandler van de knop geven we DataProtectionConfigurationProvider door aan de ProtectSection(provider)-methode, zodat de DPAPI-provider wordt gebruikt. De UnprotectSection methode kan bepalen welke provider is gebruikt voor het versleutelen van de configuratiesectie en daarom geen invoerparameters vereist.

Nadat u de ProtectSection(provider) of UnprotectSection methode hebt aangeroepen, moet u de Configuration het Save object aanroepen om de wijzigingen vast te houden. Zodra de configuratiegegevens zijn versleuteld of ontsleuteld en de wijzigingen zijn opgeslagen, roepen DisplayWebConfig we aan om de bijgewerkte Web.config inhoud in het besturingselement Tekstvak te laden.

Nadat u de bovenstaande code hebt ingevoerd, test u deze door via een browser naar de EncryptingConfigSections.aspx pagina te gaan. In eerste instantie ziet u een pagina met de inhoud van Web.config de <connectionStrings> sectie die wordt weergegeven in tekst zonder opmaak (zie afbeelding 3).

Afbeelding 3: Een tekstvak en webbesturingselementen met twee knoppen toevoegen aan de pagina (klik om de afbeelding op volledige grootte weer te geven)

Klik nu op de knop Verbindingsreeksen versleutelen. Als aanvraagvalidatie is ingeschakeld, produceert de markup die is gepost vanuit het WebConfigContents tekstvak een HttpRequestValidationException, waardoor het bericht wordt weergegeven: Een potentieel gevaarlijke Request.Form waarde afkomstig van de client is gedetecteerd. Aanvraagvalidatie, die standaard is ingeschakeld in ASP.NET 2.0, verbiedt postbacks die niet-gecodeerde HTML bevatten en is ontworpen om aanvallen met scriptinjectie te voorkomen. Deze controle kan worden uitgeschakeld op pagina- of toepassingsniveau. Als u deze functie wilt uitschakelen voor deze pagina, stelt u de ValidateRequest instelling in op false binnen de @Page directive. De @Page instructie vindt u boven aan de declaratieve markeringen van de pagina.

<%@ Page ValidateRequest="False" ... %>

Voor meer informatie over aanvraagvalidatie, het doel ervan, het uitschakelen op pagina- en toepassingsniveau, evenals het coderen van HTML-codering, zie Aanvraagvalidatie - Scriptaanvallen voorkomen.

Nadat u aanvraagvalidatie voor de pagina hebt uitgeschakeld, klikt u opnieuw op de knop Verbindingsreeksen versleutelen. Bij postback wordt het configuratiebestand geopend en de <connectionStrings> sectie wordt versleuteld met behulp van de DPAPI-provider. Het tekstvak wordt vervolgens bijgewerkt om de nieuwe Web.config inhoud weer te geven. Zoals in afbeelding 4 wordt weergegeven, worden de <connectionStrings> gegevens nu versleuteld.

Afbeelding 4: Als u op de knop Verbindingsreeksen versleutelen klikt, wordt de <connectionString> sectie versleuteld (klik om de afbeelding op volledige grootte weer te geven)

De versleutelde <connectionStrings> sectie die op mijn computer wordt gegenereerd, volgt, hoewel een deel van de inhoud in het <CipherData> element is verwijderd ter beknoptheid:

<connectionStrings 
    configProtectionProvider="DataProtectionConfigurationProvider">
  <EncryptedData>
    <CipherData>
      <CipherValue></CipherValue>
    </CipherData>
  </EncryptedData>
</connectionStrings>

Opmerking

Het <connectionStrings> element geeft de provider op die wordt gebruikt voor het uitvoeren van de versleuteling (DataProtectionConfigurationProvider). Deze informatie wordt door de UnprotectSection methode gebruikt wanneer op de knop Verbindingsreeksen ontsleutelen wordt geklikt.

Wanneer verbindingsreeksinformatie wordt benaderd via Web.config, of het nu door code is die we zelf schrijven, vanuit een SqlDataSource-besturingselement, of automatisch gegenereerde code van de TableAdapters in onze getypte gegevenssets, wordt deze automatisch ontsleuteld. Kortom, we hoeven geen extra code of logica toe te voegen om de versleutelde <connectionString> sectie te ontsleutelen. Als u dit wilt demonstreren, gaat u op dit moment naar een van de eerdere zelfstudies, zoals de zelfstudie Eenvoudige weergave in de sectie Basisrapportage (~/BasicReporting/SimpleDisplay.aspx). Zoals afbeelding 5 laat zien, werkt de zelfstudie precies zoals verwacht, wat aangeeft dat de gecodeerde verbindingstekstgegevens automatisch worden ontsleuteld door de ASP.NET-pagina.

Afbeelding 5: De Gegevenstoegangslaag ontsleutelt automatisch de verbindingstekenreeksgegevens (klik om de afbeelding op volledige grootte weer te geven)

Als u de <connectionStrings> sectie wilt terugzetten naar de weergave zonder opmaak, klikt u op de knop Verbindingsreeksen ontsleutelen. Bij een postback zou u de verbindingsreeksen in Web.config als platte tekst moeten zien. Op dit moment moet uw scherm er als volgt uitzien wanneer u deze pagina voor het eerst bezoekt (zie afbeelding 3).

Stap 3: Configuratiesecties versleutelen met behulp van aspnet_regiis.exe

Het .NET Framework bevat diverse opdrachtregelprogramma's in de $WINDOWS$\Microsoft.NET\Framework\version\ map. In de zelfstudie Sql Cache-afhankelijkheden gebruiken hebben we bijvoorbeeld gekeken naar het aspnet_regsql.exe opdrachtregelprogramma om de infrastructuur toe te voegen die nodig is voor SQL-cacheafhankelijkheden. Een ander nuttig opdrachtregelprogramma in deze map is het ASP.NET IIS-registratieprogramma (aspnet_regiis.exe). Zoals de naam al aangeeft, wordt het hulpprogramma ASP.NET IIS-registratie voornamelijk gebruikt om een ASP.NET 2.0-toepassing te registreren bij de professionele webserver van Microsoft, IIS. Naast de iis-gerelateerde functies kan het hulpprogramma ASP.NET IIS-registratie ook worden gebruikt voor het versleutelen of ontsleutelen van opgegeven configuratiesecties in Web.config.

De volgende instructie toont de algemene syntaxis die wordt gebruikt voor het versleutelen van een configuratiesectie met het aspnet_regiis.exe opdrachtregelprogramma:

aspnet_regiis.exe -pef section physical_directory -prov provider

sectie is de configuratiesectie die moet worden versleuteld (zoals connectionStrings), de physical_directory het volledige, fysieke pad naar de hoofdmap van de webtoepassing is en de provider de naam is van de beveiligde configuratieprovider die moet worden gebruikt (zoals DataProtectionConfigurationProvider). Als de webtoepassing is geregistreerd in IIS, kunt u ook het virtuele pad invoeren in plaats van het fysieke pad met behulp van de volgende syntaxis:

aspnet_regiis.exe -pe section -app virtual_directory -prov provider

In het volgende aspnet_regiis.exe voorbeeld wordt de <connectionStrings> sectie versleuteld met behulp van de DPAPI-provider met een sleutel op computerniveau:

aspnet_regiis.exe -pef
"connectionStrings" "C:\Websites\ASPNET_Data_Tutorial_73_CS"
-prov "DataProtectionConfigurationProvider"

Op dezelfde manier kan het aspnet_regiis.exe opdrachtregelprogramma worden gebruikt om configuratiesecties te ontsleutelen. Gebruik in plaats van de -pef schakeloptie -pdf (of in plaats van -pe, gebruik -pd). Houd er ook rekening mee dat de providernaam niet nodig is bij het ontsleutelen.

aspnet_regiis.exe -pdf section physical_directory
  -- or --
aspnet_regiis.exe -pd section -app virtual_directory

Opmerking

Omdat we de DPAPI-provider gebruiken, die sleutels gebruikt die specifiek zijn voor de computer, moet u aspnet_regiis.exe uitvoeren vanaf dezelfde computer waarop de webpagina's gehost worden. Als u dit opdrachtregelprogramma bijvoorbeeld uitvoert vanaf uw lokale ontwikkelcomputer en vervolgens het versleutelde Web.config-bestand uploadt naar de productieserver, kan de productieserver de verbindingstekenreeksgegevens niet ontsleutelen omdat deze is versleuteld met behulp van sleutels die specifiek zijn voor uw ontwikkelcomputer. De RSA-provider heeft deze beperking niet omdat het mogelijk is om de RSA-sleutels naar een andere computer te exporteren.

Informatie over opties voor databaseverificatie

Voordat een toepassing SELECT, INSERT, UPDATE, of DELETE query's naar een Microsoft SQL Server-database kan uitvoeren, moet de database eerst de aanvrager identificeren. Dit proces wordt verificatie genoemd en SQL Server biedt twee verificatiemethoden:

• Windows-verificatie : het proces waaronder de toepassing wordt uitgevoerd, wordt gebruikt om te communiceren met de database. Bij het uitvoeren van een ASP.NET-toepassing via Visual Studio 2005 ASP.NET Development Server, gaat de ASP.NET toepassing uit van de identiteit van de momenteel aangemelde gebruiker. Voor ASP.NET-toepassingen op Microsoft Internet Information Server (IIS) nemen ASP.NET-toepassingen meestal de identiteit van domainName``\MachineName of domainName``\NETWORK SERVICE aan, hoewel dit kan worden aangepast.
• SQL-verificatie : een gebruikers-id en wachtwoordwaarden worden opgegeven als referenties voor verificatie. Met SQL-verificatie worden de gebruikers-id en het wachtwoord opgegeven in de verbindingsreeks.

Windows-verificatie heeft de voorkeur boven SQL-verificatie, omdat deze veiliger is. Met Windows-verificatie bevat de verbindingsreeks geen gebruikersnaam of wachtwoord, en als de webserver en databaseserver zich op twee verschillende computers bevinden, worden de authenticatiegegevens niet in platte tekst via het netwerk verzonden. Met SQL-verificatie zijn de verificatiereferenties echter vastgelegd in de verbindingsreeks en worden ze verzonden van de webserver naar de databaseserver in tekst zonder opmaak.

In deze zelfstudies is Windows-verificatie gebruikt. U kunt zien welke verificatiemodus wordt gebruikt door de verbindingsreeks te inspecteren. De verbindingsstring in Web.config voor onze handleidingen is:

Data Source=.\SQLEXPRESS; AttachDbFilename=|DataDirectory|\NORTHWND.MDF; Integrated Security=True; User Instance=True

De geïntegreerde beveiliging=True en het ontbreken van een gebruikersnaam en wachtwoord geven aan dat Windows-authenticatie wordt gebruikt. In sommige verbindingsreeksen wordt de term Trusted Connection=Yes of Integrated Security=SSPI gebruikt in plaats van Integrated Security=True, maar alle drie geven het gebruik van Windows-verificatie aan.

In het volgende voorbeeld ziet u een verbindingsreeks die gebruikmaakt van SQL-verificatie. $CREDENTIAL_PLACEHOLDER$ is een tijdelijke aanduiding voor het wachtwoordsleutel-waardepaar. Houd er rekening mee dat de inloggegevens zijn ingesloten in de verbindingstekenreeks.

Server=serverName; Database=Northwind; uid=userID; $CREDENTIAL_PLACEHOLDER$

Stel dat een aanvaller het bestand van Web.config uw toepassing kan bekijken. Als u SQL-verificatie gebruikt om verbinding te maken met een database die toegankelijk is via internet, kan de aanvaller deze verbindingsreeks gebruiken om verbinding te maken met uw database via SQL Management Studio of via ASP.NET pagina's op hun eigen website. Versleutel de verbindingsreeksinformatie in Web.config met behulp van het beveiligde configuratiesysteem om deze bedreiging te mitigeren.

Opmerking

Zie Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication (Verificatie, autorisatie en beveiligde communicatie) voor meer informatie over de verschillende typen verificatie die beschikbaar zijn in SQL Server. Raadpleeg ConnectionStrings.com voor meer voorbeelden van verbindingsreeksen die de verschillen tussen de syntaxis van Windows- en SQL-verificatie illustreren.

Samenvatting

Bestanden met een .config extensie in een ASP.NET toepassing kunnen standaard niet worden geopend via een browser. Deze typen bestanden worden niet geretourneerd omdat ze mogelijk gevoelige informatie bevatten, zoals databaseverbindingsreeksen, gebruikersnamen en wachtwoorden, enzovoort. Het beveiligde configuratiesysteem in .NET 2.0 helpt gevoelige informatie verder te beveiligen door opgegeven configuratiesecties te laten versleutelen. Er zijn twee ingebouwde beveiligde configuratieproviders: één die gebruikmaakt van het RSA-algoritme en een die gebruikmaakt van de Windows Data Protection-API (DPAPI).

In deze zelfstudie hebben we gekeken naar het versleutelen en ontsleutelen van configuratie-instellingen met behulp van de DPAPI-provider. Dit kan zowel programmatisch worden bereikt, zoals we in stap 2 hebben gezien, als via het aspnet_regiis.exe opdrachtregelprogramma, dat in stap 3 is besproken. Zie de resources in de sectie Meer lezen voor meer informatie over het gebruik van sleutels op gebruikersniveau of het gebruik van de RSA-provider.

Veel plezier met programmeren!

Meer lezen

Raadpleeg de volgende bronnen voor meer informatie over de onderwerpen die in deze zelfstudie worden besproken:

• Beveiligde ASP.NET-toepassing bouwen: verificatie, autorisatie en beveiligde communicatie
• Configuratiegegevens versleutelen in ASP.NET 2.0-toepassingen
• Waarden versleutelen Web.config in ASP.NET 2.0
• Procedure: Configuratiesecties versleutelen in ASP.NET 2.0 met behulp van DPAPI
• Procedure: Configuratiesecties versleutelen in ASP.NET 2.0 met behulp van RSA
• De configuratie-API in .NET 2.0
• Windows-gegevensbescherming

Over de auteur

Scott Mitchell, auteur van zeven ASP/ASP.NET-boeken en oprichter van 4GuysFromRolla.com, werkt sinds 1998 met Microsoft-webtechnologieën. Scott werkt als onafhankelijk consultant, trainer en schrijver. Zijn laatste boek is Sams Teach Yourself ASP.NET 2.0 in 24 uur. Hij kan worden bereikt op mitchell@4GuysFromRolla.com.

Speciale dank aan

Deze tutorialreeks is beoordeeld door veel behulpzame beoordelers. Hoofdrecensenten voor deze zelfstudie waren Teresa Murphy en Randy Schmidt. Bent u geïnteresseerd in het bekijken van mijn aanstaande MSDN-artikelen? Zo ja, laat iets van je horen via mitchell@4GuysFromRolla.com.

VorigeVolgende