Megosztás a következőn keresztül:


Kapcsolati sztringek és egyéb konfigurációs információk védelme (C#)

által Scott Mitchell

PDF letöltése

Egy ASP.NET alkalmazás általában egy Web.config fájlban tárolja a konfigurációs adatokat. Ezen információk némelyike bizalmas, és védelmet biztosít. Alapértelmezés szerint ez a fájl nem lesz kiszolgálva egy webhely látogatója számára, de egy rendszergazda vagy egy hacker hozzáférhet a webkiszolgáló fájlrendszeréhez, és megtekintheti a fájl tartalmát. Ebben az oktatóanyagban megtanuljuk, hogy ASP.NET 2.0 lehetővé teszi a bizalmas információk védelmét a Web.config fájl szakaszainak titkosításával.

Bevezetés

Az ASP.NET-alkalmazások konfigurációs információi általában egy xml-fájlban Web.configtalálhatók. Az oktatóanyagok során néhány alkalommal frissítettük azokat Web.config . Amikor az Northwind létrehozza a Typed DataSetet, például a kapcsolati sztring információkat a rendszer automatikusan hozzáadta a Web.config<connectionStrings> szakaszban. Később, a Mesterlapok és a Webhelynavigáció oktatóanyagban manuálisan frissítettük Web.config, és hozzáadtunk egy <pages> elemet, amely azt jelzi, hogy a projekt összes ASP.NET lapjának a DataWebControls Témát kell használnia.

Mivel Web.config bizalmas adatokat, például kapcsolati sztringeket tartalmazhat, fontos, hogy a tartalom Web.config biztonságban és elrejtve legyen a jogosulatlan megtekintők elől. Alapértelmezés szerint a .config bővítményt tartalmazó fájlra irányuló HTTP-kéréseket a ASP.NET motor kezeli, amely az ilyen típusú lapot adja vissza, az 1. ábrán látható üzenet nem jelenik meg. Ez azt jelenti, hogy a látogatók nem tekinthetik meg a Web.config fájl tartalmát úgy, hogy egyszerűen belépnek http://www.YourServer.com/Web.config a böngésző címsorába.

A Web.config böngészőn keresztüli felkeresése olyan üzenetet ad vissza, hogy ez a típusú oldal nem kiszolgálható

1. ábra: A böngészőben való látogatás Web.config az ilyen típusú lap nem kézbesített üzenetét adja vissza (Ide kattintva megtekintheti a teljes méretű képet)

De mi a teendő, ha egy támadó talál egy másik biztonsági rést, amely lehetővé teszi számára a Web.config fájl tartalmainak megtekintését? Mit tehet a támadó ezzel az információval, és milyen lépéseket tehet a bizalmas információk Web.configtovábbi védelme érdekében? Szerencsére a legtöbb szakasz Web.config nem tartalmaz bizalmas információkat. Milyen kárt okozhat a támadó, ha ismeri a ASP.NET lapok által használt alapértelmezett téma nevét?

Bizonyos Web.config szakaszok azonban bizalmas információkat tartalmaznak, amelyek tartalmazhatnak kapcsolati sztringeket, felhasználóneveket, jelszavakat, kiszolgálóneveket, titkosítási kulcsokat stb. Ezek az információk általában a következő Web.config szakaszokban találhatók:

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

Ebben az oktatóanyagban az ilyen bizalmas konfigurációs információk védelmére szolgáló technikákat tekintjük át. Amint látni fogjuk, a .NET-keretrendszer 2.0-s verziója tartalmaz egy védett konfigurációs rendszert, amely programozott módon titkosítja és visszafejti a kiválasztott konfigurációs szakaszokat.

Megjegyzés:

Ez az oktatóanyag egy ASP.NET-alkalmazásból származó adatbázishoz való csatlakozásra vonatkozó Microsoft-javaslatok áttekintésével fejeződik be. A kapcsolati sztringek titkosítása mellett segíthet a rendszer megerősítésében azáltal, hogy biztonságosan csatlakozik az adatbázishoz.

1. lépés: A ASP.NET 2.0 védett konfigurációs beállításainak felfedezése

ASP.NET 2.0 tartalmaz egy védett konfigurációs rendszert a konfigurációs információk titkosításához és visszafejtéséhez. Ide tartoznak a .NET-keretrendszer azon módszerei, amelyek a konfigurációs információk programozott titkosítására vagy visszafejtésére használhatók. A védett konfigurációs rendszer a szolgáltatói modellt használja, amellyel a fejlesztők kiválaszthatják, hogy milyen titkosítási implementációt használnak.

A .NET-keretrendszer két védett konfigurációs szolgáltatóval van ellátva:

Mivel a védett konfigurációs rendszer implementálja a szolgáltató tervezési mintáját, létrehozhatja saját védett konfigurációs szolgáltatóját, és csatlakoztathatja azt az alkalmazáshoz. Erről a folyamatról további információt a Védett konfigurációs szolgáltató implementálása című témakörben talál.

Az RSA- és DPAPI-szolgáltatók kulcsokat használnak a titkosítási és visszafejtési rutinjukhoz, és ezek a kulcsok gépi vagy felhasználói szinten tárolhatók. A gépi szintű kulcsok ideálisak olyan helyzetekben, amikor a webalkalmazás a saját dedikált kiszolgálón fut, vagy ha egy kiszolgálón több alkalmazásnak is meg kell osztania a titkosított információkat. A felhasználói szintű kulcsok biztonságosabbak a megosztott üzemeltetési környezetekben, ahol az ugyanazon a kiszolgálón lévő más alkalmazások nem tudják visszafejteni az alkalmazás védett konfigurációs szakaszait.

Ebben az oktatóanyagban a példáink a DPAPI-szolgáltatót és a gépszintű kulcsokat használják. Pontosabban a <connectionStrings> szakasz titkosítását fogjuk megvizsgálni Web.config-ban, bár a védett konfigurációs rendszer a legtöbb Web.config szakasz titkosítására használható. A felhasználói szintű kulcsok vagy az RSA-szolgáltató használatával kapcsolatos információkért tekintse meg az oktatóanyag végén található További olvasások szakaszban található forrásokat.

Megjegyzés:

A RSAProtectedConfigurationProvider és DPAPIProtectedConfigurationProvider szolgáltatók a machine.config fájlban vannak regisztrálva RsaProtectedConfigurationProvider és DataProtectionConfigurationProvider szolgáltatói nevekkel. A konfigurációs adatok titkosítása vagy visszafejtése során a tényleges típusnév (ésRsaProtectedConfigurationProvider) helyett a megfelelő szolgáltatónevet kellDataProtectionConfigurationProvider megadni (RSAProtectedConfigurationProvider vagy DPAPIProtectedConfigurationProvider) . A machine.config fájlt a $WINDOWS$\Microsoft.NET\Framework\version\CONFIG mappában találja.

2. lépés: Konfigurációs szakaszok programozott titkosítása és visszafejtése

Néhány sornyi kóddal titkosíthatunk vagy visszafejthetünk egy adott konfigurációs szakaszt egy megadott szolgáltató használatával. Ahogy hamarosan látni fogjuk, a kódnak programozott módon kell hivatkoznia a megfelelő konfigurációs szakaszra, meg kell hívnia a ProtectSection vagy UnprotectSection metódust, majd a Save metódust a változások mentéséhez. A .NET-keretrendszer emellett egy hasznos parancssori segédprogramot is tartalmaz, amely képes a konfigurációs információk titkosítására és visszafejtésére. Ezt a parancssori segédprogramot a 3. lépésben fogjuk megvizsgálni.

A konfigurációs adatok programozott védelmének szemléltetéséhez hozzunk létre egy ASP.NET lapot, amely a szakasz <connectionStrings>titkosítására és visszafejtésére Web.config szolgáló gombokat tartalmaz.

Először nyissa meg a EncryptingConfigSections.aspx lapot a AdvancedDAL mappában. Húzzon egy TextBox-vezérlőt az eszközkészletből a Tervezőre, és állítsa a ID tulajdonságát WebConfigContents-re, a TextMode tulajdonságát MultiLine-ra, valamint a Width és Rows tulajdonságokat rendre 95%-ra és 15-re. Ez a TextBox-vezérlő megjeleníti a tartalom tartalmát Web.config , így gyorsan megállapíthatjuk, hogy a tartalom titkosítva van-e vagy sem. Természetesen egy valódi alkalmazásban soha nem szeretné megjeleníteni a(z) Web.config tartalmát.

A Szövegdoboz alá adjon hozzá két gombvezérlőt az alábbi nevekkel: EncryptConnStrings és DecryptConnStrings. Állítsa be a "Encrypt Connection Strings" és "Decrypt Connection Strings" szövegtulajdonságokat a kapcsolati sztringek titkosítására és visszafejtésére.

Ekkor a képernyőnek a 2. ábrához hasonlóan kell kinéznie.

Képernyőkép a Visual Studio EncryptingConfigSections.aspx lapjáról, amely új Szövegdoboz és két gombvezérlővel rendelkezik.

2. ábra: Szövegdoboz és kétgombos webvezérlők hozzáadása a laphoz (ide kattintva megtekintheti a teljes méretű képet)

Ezután olyan kódot kell írnunk, amely betölti Web.config és megjeleníti a szövegdoboz tartalmát a WebConfigContents lap első betöltésekor. Adja hozzá a következő kódot a lap mögötti osztályhoz. Ez a kód hozzáad egy DisplayWebConfig nevű metódust, és meghívja azt az Page_Load eseménykezelőből, amikor Page.IsPostBack státuszban 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;
}

A DisplayWebConfig metódus az File osztály használatával nyitja meg az alkalmazásfájlt Web.config , az StreamReader osztályt a tartalma sztringbe való beolvasásához, az Path osztály pedig a Web.config fájl fizikai elérési útját hozza létre. Ez a három osztály mind megtalálható a System.IO névtérben. Következésképpen egy usingSystem.IO utasítást kell hozzáadnia a kód mögötti osztály elejéhez, vagy pedig az osztálynevek elé írja be a System.IO. előtagot.

Ezután el kell látnunk eseménykezelőkkel a két gombvezérlő Click eseményeit, és hozzá kell adjuk a szükséges kódot a <connectionStrings> szakasz titkosításához és visszafejtéséhez, amely egy gépi szintű kulcsot használ a DPAPI szolgáltatóval. A Tervezőben kattintson duplán az egyes gombokra egy eseménykezelő hozzáadásához Click a kód mögötti osztályban, majd adja hozzá a következő kódot:

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

A két eseménykezelőben használt kód majdnem azonos. Mindkettő az aktuális alkalmazás Web.config fájljával kapcsolatos információk beolvasásával kezdődik az WebConfigurationManager osztálymetódusánOpenWebConfiguration keresztül. Ez a metódus a megadott virtuális elérési út webes konfigurációs fájlját adja vissza. Ezután a Web.config fájl s <connectionStrings> szakasza az Configuration s osztályGetSection(sectionName) metóduson keresztül érhető el, amely egy objektumot ConfigurationSection ad vissza.

Az ConfigurationSection objektum tartalmaz egy tulajdonságotSectionInformation, amely további információkat és funkciókat biztosít a konfigurációs szakaszról. Ahogy a fenti kód is mutatja, megállapíthatjuk, hogy a konfigurációs szakasz titkosítva van-e a SectionInformation tulajdonság IsProtected ellenőrzésével. Ezenkívül a szakasz titkosítható vagy visszafejthető az SectionInformation s ProtectSection(provider) tulajdonságon és UnprotectSection metóduson keresztül.

A ProtectSection(provider) metódus bemenetként fogad el egy sztringet, amely megadja a titkosításkor használni kívánt védett konfigurációs szolgáltató nevét. A Button eseménykezelőjében átadjuk a EncryptConnString DataProtectionConfigurationProvidert a ProtectSection(provider) metódusnak, hogy a DPAPI-szolgáltatót használjuk. A UnprotectSection metódus meghatározhatja a konfigurációs szakasz titkosításához használt szolgáltatót, ezért nincs szükség bemeneti paraméterekre.

A ProtectSection(provider) vagy a UnprotectSection metódus meghívása után meg kell hívnia az Configuration objektum Save metódusát a módosítások megőrzéséhez. A konfigurációs adatok titkosítása vagy visszafejtése és a módosítások mentése után meghívjuk DisplayWebConfig , hogy töltse be a frissített Web.config tartalmat a TextBox vezérlőbe.

Miután megadta a fenti kódot, tesztelje az EncryptingConfigSections.aspx oldalt egy böngészőben. Először egy olyan oldalnak kell megjelennie, amely felsorolja a Web.config tartalmát, és a <connectionStrings> szakaszt egyszerű szövegként jeleníti meg (lásd a 3. ábrát).

Képernyőkép a webböngészőben betöltött EncryptingConfigSections.aspx lapról.

3. ábra: Szövegdoboz és két gombos webvezérlők hozzáadása a laphoz (ide kattintva megtekintheti a teljes méretű képet)

Kattintson a Kapcsolati karakterláncok titkosítása gombra. Ha a kérés érvényesítése engedélyezve van, a TextBoxból WebConfigContents visszaküldött jelölés létrehoz egy HttpRequestValidationException, amely megjeleníti az üzenetet: potenciálisan veszélyes Request.Form értéket észlelt az ügyféltől. A 2.0-s ASP.NET alapértelmezés szerint engedélyezett kérésérvényesítés tiltja a kódolatlan HTML-t tartalmazó, szkriptinjektálási támadások megelőzésére szolgáló utólagos visszaállításokat. Ez az ellenőrzés le van tiltva az oldalon vagy az alkalmazás szintjén. A lap kikapcsolásához állítsa be a ValidateRequest beállítást false az @Page irányelvben. Az @Page irányelv az oldal deklaratív korrektúrája tetején található.

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

A kérések érvényesítéséről, céljáról, az oldal- és alkalmazásszintű letiltásról, valamint a HTML-kódoló korrektúra használatáról további információt a Kérésérvényesítés – Szkripttámadások megakadályozása című témakörben talál.

A lap kérésérvényesítésének letiltása után próbálkozzon újra a Kapcsolati sztringek titkosítása gombra kattintva. Postbackkor a konfigurációs fájl elérhetővé válik, és annak <connectionStrings> szakasza A DPAPI szolgáltatóval kerül titkosításra. A Szövegdoboz ekkor frissül az új Web.config tartalom megjelenítéséhez. Ahogy a 4. ábrán látható, az <connectionStrings> adatok titkosítva lesznek.

A Kapcsolati sztringek titkosítása gombra kattintva titkosítja a <connectionString szakaszt>

4. ábra: A Kapcsolati sztringek titkosítása gombra kattintva titkosítja a <connectionString> szakaszt (ide kattintva megtekintheti a teljes méretű képet)

A számítógépen létrehozott titkosított <connectionStrings> szakasz a következő, bár az <CipherData> elem bizonyos tartalma el lett távolítva a rövidség kedvéért:

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

Megjegyzés:

Az <connectionStrings> elem megadja a titkosításDataProtectionConfigurationProvider () végrehajtásához használt szolgáltatót. Ezt az információt a UnprotectSection metódus használja, amikor a Kapcsolati sztringek visszafejtése gomb megnyomása történik.

Ha a kapcsolati sztring információk Web.config-ból érhetők el—akár az általunk írt kódból, egy SqlDataSource-vezérlőből, vagy a gépelt adatkészleteink TableAdapters-éből automatikusan létrehozott kódból—azokat automatikusan visszafejtésre kerülnek. Röviden, nem kell további kódot vagy logikát hozzáadni a titkosított <connectionString> szakasz visszafejtéséhez. Ennek bemutatásához látogasson el az egyik korábbi oktatóanyagra, például az Egyszerű megjelenítés oktatóanyagra az Alapszintű jelentéskészítés szakaszból (~/BasicReporting/SimpleDisplay.aspx). Ahogy az 5. ábrán látható, az oktatóanyag pontosan úgy működik, ahogy azt elvárnánk, ami azt jelzi, hogy a titkosított kapcsolati sztring adatait a ASP.NET oldal automatikusan visszafejti.

Az adatelérési réteg automatikusan visszafejti a kapcsolati sztring adatait

5. ábra: Az adatelérési réteg automatikusan visszafejti a kapcsolati sztring adatait (ide kattintva megtekintheti a teljes méretű képet)

Ha vissza szeretné állítani a <connectionStrings> szakaszt egyszerű szöveges formájára, kattintson a Kapcsolati karakterláncok visszafejtése gombra. A visszaküldés során a kapcsolati sztringeket egyszerű szövegként kell látnia a Web.config elemben. Ezen a ponton a képernyőnek úgy kell kinéznie, mint a lap első megnyitásakor (lásd a 3. ábrát).

3. lépés: Konfigurációs szakaszok titkosítása aspnet_regiis.exe használatával

A .NET-keretrendszer számos parancssori eszközt tartalmaz a $WINDOWS$\Microsoft.NET\Framework\version\ mappában. Az SQL Cache-függőségek használata oktatóanyagban például a aspnet_regsql.exe parancssori eszközzel néztem meg az SQL Cache-függőségekhez szükséges infrastruktúra hozzáadását. Egy másik hasznos parancssori eszköz ebben a mappában az ASP.NET IIS regisztrációs eszköz (aspnet_regiis.exe). Ahogy a neve is mutatja, az ASP.NET IIS regisztrációs eszköz elsősorban egy ASP.NET 2.0-s alkalmazás regisztrálására szolgál a Microsoft professzionális szintű webkiszolgálóján, az IIS-ben. Az IIS-hez kapcsolódó funkciók mellett az ASP.NET IIS-regisztrációs eszköz a megadott konfigurációs szakaszok titkosítására vagy visszafejtésére is használható.Web.config

Az alábbi utasítás a konfigurációs szakasz parancssori eszközzel történő titkosításához használt általános szintaxist aspnet_regiis.exe mutatja be:

aspnet_regiis.exe -pef section physical_directory -prov provider

szakasz a titkosítandó konfigurációs szakasz (például connectionStrings), a physical_directory a webalkalmazás gyökérkönyvtárának teljes fizikai elérési útja, a szolgáltató pedig a használni kívánt védett konfigurációs szolgáltató neve (például DataProtectionConfigurationProvider). Ha a webalkalmazás regisztrálva van az IIS-ben, a fizikai elérési út helyett a következő szintaxist használhatja:

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

Az alábbi aspnet_regiis.exe példa egy gépszintű kulccsal titkosítja a <connectionStrings> szakaszt a DPAPI-szolgáltatóval:

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

Hasonlóképpen a parancssori aspnet_regiis.exe eszköz is használható a konfigurációs szakaszok visszafejtéséhez. -pef helyett használja a -pdf kapcsolót (vagy -pe helyett használja a -pd kapcsolót). Azt is vegye figyelembe, hogy a visszafejtéshez nincs szükség a szolgáltató nevére.

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

Megjegyzés:

Mivel a DPAPI-szolgáltatót használjuk, amely a számítógéphez tartozó kulcsokat használja, a aspnet_regiis.exe -t ugyanazon a gépen kell futtatni, amelyről a weblapok ki vannak szolgálva. Ha például ezt a parancssori programot a helyi fejlesztőgépről futtatja, majd feltölti a titkosított Web.config fájlt az éles kiszolgálóra, az éles kiszolgáló nem tudja visszafejteni a kapcsolati sztring adatait, mivel az a fejlesztői géphez tartozó kulcsokkal lett titkosítva. Az RSA-szolgáltató nem rendelkezik ezzel a korlátozásokkal, mivel az RSA-kulcsokat exportálhatja egy másik gépre.

Az adatbázis-hitelesítési beállítások ismertetése

Mielőtt bármely alkalmazás kiadhat SELECT, INSERTvagy UPDATEDELETE lekérdezéseket adhat ki egy Microsoft SQL Server-adatbázishoz, az adatbázisnak először azonosítania kell a kérelmezőt. Ezt a folyamatot hitelesítésnek nevezzük, és az SQL Server két hitelesítési módszert biztosít:

  • Windows-hitelesítés – Az alkalmazás futtatásának folyamata az adatbázissal való kommunikációra szolgál. Ha ASP.NET alkalmazást futtat a Visual Studio 2005 ASP.NET Fejlesztői kiszolgálón keresztül, a ASP.NET alkalmazás feltételezi az aktuálisan bejelentkezett felhasználó identitását. A Microsoft Internet Information Serveren (IIS) futó ASP.NET alkalmazások általában domainName``\MachineName vagy domainName``\NETWORK SERVICE identitást feltételeznek, bár ez testre szabható.
  • SQL-hitelesítés – a rendszer hitelesítő adatokként adja meg a felhasználóazonosítót és a jelszóértékeket a hitelesítéshez. Az SQL-hitelesítéssel a felhasználói azonosítót és a jelszót a kapcsolati sztring tartalmazza.

A Windows-hitelesítés előnyben részesítve az SQL-hitelesítést, mert biztonságosabb. Windows-hitelesítés esetén a kapcsolati sztring nem tartalmaz felhasználónevet és jelszót, és ha a webkiszolgáló és az adatbázis-kiszolgáló két különböző gépen található, a rendszer nem küldi el a hitelesítő adatokat a hálózaton egyszerű szöveges formátumban. Az SQL-hitelesítéssel azonban a hitelesítési adatok közvetlenül be vannak ágyazva a kapcsolati sztringbe, és a webkiszolgálóról egyszerű szövegként továbbítódnak az adatbázis-kiszolgálónak.

Ezek az oktatóanyagok Windows-hitelesítést használtak. A kapcsolati sztring vizsgálatával megállapíthatja, hogy milyen hitelesítési módot használ. Az oktatóanyagokban található kapcsolat karakterlánca a következő volt:

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

Az "Integrated Security=True" és a felhasználónév és jelszó hiánya azt jelzi, hogy a Windows hitelesítés van használatban. Egyes kapcsolati sztringekben a Megbízható kapcsolat=Igen vagy az Integrált biztonság=SSPI kifejezés használatos az Integrált biztonság=Igaz helyett, de mindhárom a Windows-hitelesítés használatát jelzi.

Az alábbi példa egy SQL-hitelesítést használó kapcsolati sztringet mutat be. $CREDENTIAL_PLACEHOLDER$ a jelszókulcs-érték pár helyettesítője. Vegye figyelembe, hogy a hitelesítő adatok a kapcsolati sztringbe vannak ágyazva:

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

Tegyük fel, hogy egy támadó meg tudja tekinteni az alkalmazás fájlját Web.config . Ha SQL-hitelesítéssel csatlakozik egy interneten keresztül elérhető adatbázishoz, a támadó ezzel a kapcsolati sztringgel csatlakozhat az adatbázishoz az SQL Management Studióban vagy a saját webhelyén található ASP.NET oldalakról. A fenyegetés elhárításához titkosítsa a kapcsolati sztring adatait Web.config a védett konfigurációs rendszer használatával.

Megjegyzés:

Az SQL Server különböző hitelesítési típusaival kapcsolatos további információkért lásd : Biztonságos ASP.NET-alkalmazások létrehozása: Hitelesítés, Engedélyezés és Biztonságos kommunikáció. A Windows és az SQL-hitelesítési szintaxis közötti különbségeket szemléltető további kapcsolati sztring-példákért tekintse meg ConnectionStrings.com.

Összefoglalás

Alapértelmezés szerint egy ASP.NET-alkalmazásban bővítményt tartalmazó .config fájlok nem érhetők el böngészőn keresztül. Az ilyen típusú fájlok nem jelennek meg, mert bizalmas információkat tartalmazhatnak, például adatbázis-kapcsolati sztringeket, felhasználóneveket és jelszavakat stb. A .NET 2.0 védett konfigurációs rendszere a megadott konfigurációs szakaszok titkosításának engedélyezésével segít a bizalmas információk további védelmében. Két beépített, védett konfigurációs szolgáltató létezik: az egyik az RSA algoritmust, a másik pedig a Windows Data Protection API-t (DPAPI) használja.

Ebben az oktatóanyagban áttekintettük, hogyan titkosíthatja és fejthet vissza konfigurációs beállításokat a DPAPI-szolgáltatóval. Ez programozott módon is elvégezhető, ahogy a 2. lépésben láttuk, valamint a aspnet_regiis.exe 3. lépésben tárgyalt parancssori eszközzel is. A felhasználói szintű kulcsok használatáról vagy az RSA-szolgáltató helyett való használatáról további információt a További olvasás szakaszban talál.

Boldog programozást!

További olvasás

Az oktatóanyagban tárgyalt témakörökről az alábbi forrásokban talál további információt:

Tudnivalók a szerzőről

Scott Mitchell, hét ASP/ASP.NET-könyv szerzője és a 4GuysFromRolla.com alapítója, 1998 óta dolgozik a Microsoft webtechnológiáival. Scott független tanácsadóként, edzőként és íróként dolgozik. Legújabb könyve Sams Teach Yourself ASP.NET 2.0 24 óra alatt. Ő itt elérhető mitchell@4GuysFromRolla.com.

Külön köszönet

Ezt az oktatóanyag-sorozatot sok hasznos véleményező áttekintette. Az oktatóanyag vezető véleményezői Teresa Murphy és Randy Schmidt voltak. Szeretné áttekinteni a közelgő MSDN-cikkeimet? Ha igen, írj egy sort a mitchell@4GuysFromRolla.com-ra.