Ochrona parametrów połączeń i innych informacji o konfiguracji (C#)

Autor: Scott Mitchell

Pobierz plik PDF

Aplikacja ASP.NET zazwyczaj przechowuje informacje o konfiguracji w pliku Web.config. Niektóre z tych informacji są poufne i gwarantuje ochronę. Domyślnie ten plik nie będzie obsługiwany dla odwiedzających witrynę sieci Web, ale administrator lub haker może uzyskać dostęp do systemu plików serwera sieci Web i wyświetlić zawartość pliku. Z tego samouczka dowiesz się, że ASP.NET 2.0 umożliwia ochronę poufnych informacji przez szyfrowanie sekcji pliku Web.config.

Wprowadzenie

Informacje o konfiguracji aplikacji ASP.NET są często przechowywane w pliku XML o nazwie Web.config. W trakcie tych samouczków zaktualizowaliśmy Web.config kilka razy. Podczas tworzenia Northwind Typed DataSet w pierwszym samouczku, na przykład informacje o parametrach połączenia zostały automatycznie dodane do Web.config w sekcji <connectionStrings>. W dalszej części samouczka Strony wzorcowe i nawigacja po witrynie, zaktualizowaliśmy ręcznie Web.config, dodając element <pages>, wskazujący, że wszystkie strony ASP.NET w naszym projekcie powinny używać motywu DataWebControls.

Ponieważ Web.config mogą zawierać poufne dane, takie jak parametry połączenia, ważne jest, aby zawartość Web.config była bezpieczna i ukryta przed nieautoryzowanymi widzami. Domyślnie każde żądanie HTTP do pliku z .config rozszerzeniem jest obsługiwane przez aparat ASP.NET, który zwraca komunikat Tego typu strony nie są obsługiwane, jak pokazano na rysunku 1. Oznacza to, że osoby odwiedzające nie mogą wyświetlać Web.config zawartości pliku, wprowadzając po prostu http://www.YourServer.com/Web.config na pasku adresu przeglądarki.

Rysunek 1: Przeglądanie Web.config za pośrednictwem przeglądarki zwraca komunikat: tego rodzaju strona nie jest obsługiwana (kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Ale co zrobić, jeśli osoba atakująca może znaleźć inne luki, które pozwalają jej wyświetlić Web.config zawartość pliku? Co może zrobić osoba atakująca, korzystając z tych informacji, i jakie kroki można podjąć w celu dalszej ochrony poufnych informacji w ramach Web.config? Na szczęście większość sekcji w programie Web.config nie zawiera informacji poufnych. Jakie szkody może wyrządzić atakujący, jeśli zna nazwę domyślnego motywu używanego przez strony ASP.NET?

Niektóre Web.config sekcje zawierają jednak poufne informacje, które mogą obejmować parametry połączenia, nazwy użytkowników, hasła, nazwy serwerów, klucze szyfrowania itd. Te informacje znajdują się zwykle w następujących Web.config sekcjach:

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

W tym samouczku przyjrzymy się technikom ochrony takich poufnych informacji konfiguracyjnych. Jak zobaczymy, program .NET Framework w wersji 2.0 zawiera chroniony system konfiguracji, który sprawia, że programowe szyfrowanie i odszyfrowywanie wybranych sekcji konfiguracji jest proste.

Krok 1: Badanie opcji chronionej konfiguracji ASP.NET 2.0

ASP.NET 2.0 zawiera chroniony system konfiguracji do szyfrowania i odszyfrowywania informacji o konfiguracji. Obejmuje to metody w programie .NET Framework, które mogą służyć do programowego szyfrowania lub odszyfrowywania informacji o konfiguracji. Chroniony system konfiguracji korzysta z modelu dostawcy, który umożliwia deweloperom wybór używanej implementacji kryptograficznych.

Program .NET Framework jest dostarczany z dwoma chronionymi dostawcami konfiguracji:

• RSAProtectedConfigurationProvider — używa asymetrycznego algorytmu RSA do szyfrowania i odszyfrowywania.
• DPAPIProtectedConfigurationProvider — używa interfejsu API ochrony danych systemu Windows (DPAPI) do szyfrowania i odszyfrowywania.

Ponieważ chroniony system konfiguracji implementuje wzorzec projektowania dostawcy, można utworzyć własnego chronionego dostawcę konfiguracji i podłączyć go do aplikacji. Aby uzyskać więcej informacji na temat tego procesu, zobacz Implementowanie dostawcy chronionej konfiguracji.

Dostawcy RSA i DPAPI używają kluczy do wykonywania procedur szyfrowania i odszyfrowywania, a te klucze mogą być przechowywane na poziomie komputera lub użytkownika. Klucze na poziomie maszyny są idealne w scenariuszach, w których aplikacja internetowa działa na własnym dedykowanym serwerze lub jeśli istnieje wiele aplikacji na serwerze, które muszą udostępniać zaszyfrowane informacje. Klucze na poziomie użytkownika to bezpieczniejsza opcja w środowiskach hostingu współużytkowanego, w których inne aplikacje na tym samym serwerze nie powinny być w stanie odszyfrować sekcji konfiguracji chronionej aplikacji.

W tym samouczku nasze przykłady będą używać dostawcy DPAPI i kluczy na poziomie maszyny. W szczególności przyjrzymy się szyfrowaniu sekcji <connectionStrings> w Web.config, chociaż chroniony system konfiguracji może być użyty do szyfrowania prawie każdej sekcji Web.config. Aby uzyskać informacje na temat używania kluczy na poziomie użytkownika lub korzystania z dostawcy RSA, zapoznaj się z zasobami w sekcji Dalsze informacje na końcu tego samouczka.

Krok 2. Programowe szyfrowanie i odszyfrowywanie sekcji konfiguracji

Za pomocą kilku wierszy kodu możemy zaszyfrować lub odszyfrować określoną sekcję konfiguracji przy użyciu określonego dostawcy. Kod, jak zobaczymy wkrótce, po prostu musi programowo odwołać się do odpowiedniej sekcji konfiguracji, wywołać jej ProtectSection metodę lub UnprotectSection , a następnie wywołać Save metodę, aby utrwała zmiany. Ponadto program .NET Framework zawiera przydatne narzędzie wiersza polecenia, które może szyfrować i odszyfrowywać informacje o konfiguracji. Zapoznamy się z tym narzędziem wiersza polecenia w kroku 3.

Aby zilustrować programową ochronę informacji o konfiguracji, utwórzmy stronę ASP.NET zawierającą przyciski do szyfrowania i odszyfrowywania <connectionStrings> sekcji w programie Web.config.

Zacznij od otwarcia strony EncryptingConfigSections.aspx w folderze AdvancedDAL. Przeciągnij kontrolkę TextBox z Przybornika do Projektanta, ustawiając jej właściwość ID na WebConfigContents, właściwość TextMode na MultiLine, oraz właściwości Width i Rows na odpowiednio 95% i 15. Ta kontrolka TextBox wyświetli zawartość Web.config umożliwiającą szybkie sprawdzenie, czy zawartość jest zaszyfrowana, czy nie. Oczywiście w rzeczywistej aplikacji nigdy nie chcesz wyświetlać zawartości elementu Web.config.

Pod kontrolką TextBox dodaj dwie kontrolki Przycisk o nazwie EncryptConnStrings i DecryptConnStrings. Ustaw ich właściwości Text na wartość Szyfruj ciągi połączeń i Odszyfruj ciągi połączeń.

Na tym etapie ekran powinien wyglądać podobnie do rysunku 2.

Rysunek 2: Dodaj kontrolkę TextBox i dwie kontrolki przycisków sieci Web do strony (kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Następnie musimy napisać kod, który ładuje i wyświetla zawartość Web.config pola TextBox po pierwszym załadowaniu WebConfigContents strony. Dodaj następujący kod do klasy code-behind strony. Ten kod dodaje metodę o nazwie DisplayWebConfig i wywołuje ją z programu obsługi zdarzeń Page_Load, gdy Page.IsPostBack jest 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;
}

Metoda DisplayWebConfig używa File klasy do otwierania Web.config pliku aplikacji,StreamReaderklasy w celu odczytania jej zawartości w ciągu orazPathklasy w celu wygenerowania ścieżki fizycznej do Web.config pliku. Wszystkie te trzy klasy znajdują się w System.IO przestrzeni nazw. W związku z tym należy dodać instrukcję usingSystem.IO na początku klasy code-behind lub, alternatywnie, dodać prefiks System.IO. do tych nazw klas.

Następnie musimy dodać programy obsługi zdarzeń dla dwóch kontrolerów Przycisk Click oraz dodać niezbędny kod do zaszyfrowania i odszyfrowania sekcji <connectionStrings> przy użyciu klucza na poziomie maszyny z wykorzystaniem dostawcy DPAPI. W projektancie kliknij dwukrotnie każdy z przycisków, aby dodać procedurę Click obsługi zdarzeń w klasie code-behind, a następnie dodaj następujący kod:

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

Kod używany w dwóch programach obsługi zdarzeń jest prawie identyczny. Obie zaczynają od uzyskania informacji o bieżącym pliku aplikacji Web.config za pośrednictwem klasy WebConfigurationManager oraz metody OpenWebConfiguration. Ta metoda zwraca plik konfiguracji sieci Web dla określonej ścieżki wirtualnej. Następnie sekcja pliku Web.config<connectionStrings> jest uzyskiwana za pośrednictwem klasy Configuration, a metoda GetSection(sectionName) zwraca ConfigurationSection obiekt.

Obiekt ConfigurationSection zawiera SectionInformation właściwość , która zawiera dodatkowe informacje i funkcje dotyczące sekcji konfiguracji. Jak pokazuje powyższy kod, możemy określić, czy sekcja konfiguracji jest szyfrowana, sprawdzając właściwości SectionInformation i IsProtected. Ponadto sekcję można zaszyfrować lub odszyfrować za pomocą SectionInformation właściwości s ProtectSection(provider) i UnprotectSection metod.

Metoda ProtectSection(provider) przyjmuje jako dane wejściowe ciąg określający nazwę chronionego dostawcy konfiguracji do użycia podczas szyfrowania. W obsługiwaniu zdarzenia przycisku EncryptConnString przekazujemy element DataProtectionConfigurationProvider do metody ProtectSection(provider), aby używany był dostawca DPAPI. Metoda UnprotectSection może określić dostawcę, który został użyty do zaszyfrowania sekcji konfiguracji i dlatego nie wymaga żadnych parametrów wejściowych.

Po wywołaniu metody ProtectSection(provider) lub UnprotectSection należy wywołać metodę ConfigurationSave, aby utrwalić zmiany. Po zaszyfrowaniu lub odszyfrowaniu informacji o konfiguracji i zapisaniu zmian wywołujemy DisplayWebConfig w celu załadowania zaktualizowanej zawartości Web.config do kontrolki TextBox.

Po wprowadzeniu powyższego kodu przetestuj go, odwiedzając stronę EncryptingConfigSections.aspx za pośrednictwem przeglądarki. Początkowo powinna zostać wyświetlona strona, która zawiera zawartość Web.config, z sekcją <connectionStrings> wyświetlaną w postaci zwykłego tekstu (zobacz Rysunek 3).

Rysunek 3: Dodaj kontrolkę TextBox i dwie kontrolki przycisku do strony (kliknij, aby wyświetlić pełnowymiarowy obraz)

Teraz kliknij przycisk Szyfruj parametry połączenia. Jeśli walidacja żądania jest włączona, znaczniki zwrócone z WebConfigContents TextBox wygenerują HttpRequestValidationException, który wyświetla komunikat: Wykryto potencjalnie niebezpieczną wartość Request.Form od klienta. Walidacja żądań, która jest domyślnie włączona w ASP.NET 2.0, zabrania postbacków, które zawierają niekodowany HTML, i ma na celu zapobieganie atakom typu script-injection. To sprawdzenie można wyłączyć na poziomie strony lub aplikacji. Aby wyłączyć tę funkcję na tej stronie, ustaw ValidateRequest na false w dyrektywie @Page. Dyrektywa @Page znajduje się w górnej części strony deklaratywnego kodu.

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

Aby uzyskać więcej informacji na temat sprawdzania poprawności żądania, jego przeznaczenia, sposobu jego wyłączania na poziomie strony i aplikacji, a także sposobu kodowania kodu HTML, zobacz Request Validation - Preventing Script Attacks (Sprawdzanie poprawności żądań — zapobieganie atakom skryptowym).

Po wyłączeniu weryfikacji żądania dla strony spróbuj ponownie kliknąć przycisk Szyfruj parametry połączenia. Po ponownym przesłaniu plik konfiguracyjny zostanie otwarty, a jego <connectionStrings> sekcja zostanie zaszyfrowana z użyciem dostawcy DPAPI. Pole tekstowe jest następnie aktualizowane w celu wyświetlenia nowej Web.config zawartości. Jak pokazano na rysunku 4, <connectionStrings> informacje są teraz szyfrowane.

Rysunek 4. Kliknięcie przycisku Szyfruj parametry połączenia szyfruje sekcję <connectionString> (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Sekcja zaszyfrowana <connectionStrings> wygenerowana na moim komputerze jest następująca, chociaż część zawartości elementu <CipherData> została usunięta w celu zwięzłości:

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

Gdy dostęp do informacji o parametrze połączenia jest uzyskiwany Web.config za pomocą kodu pisanego przez nas, z kontrolki SqlDataSource lub z automatycznie generowanego kodu z elementów TableAdapters w naszych typowych zestawach danych, jest on automatycznie odszyfrowywany. Krótko mówiąc, nie musimy dodawać żadnego dodatkowego kodu ani logiki, aby odszyfrować zaszyfrowaną <connectionString> sekcję. Aby to zademonstrować, odwiedź jedną z wcześniejszych samouczków w tej chwili, na przykład samouczek Simple Display w sekcji Podstawowe raportowanie (~/BasicReporting/SimpleDisplay.aspx). Jak pokazano na rysunku 5, samouczek działa dokładnie tak, jak się spodziewamy, wskazując, że zaszyfrowane informacje dotyczące parametru połączenia są automatycznie odszyfrowywane przez stronę ASP.NET.

Rysunek 5. Warstwa dostępu do danych automatycznie odszyfrowuje informacje o parametrach połączenia (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Aby przywrócić sekcję <connectionStrings> do jej reprezentacji zwykłego tekstu, kliknij przycisk Odszyfruj parametry połączenia. Po postbacku powinny być widoczne parametry połączenia w Web.config w formie zwykłego tekstu. Na tym etapie ekran powinien wyglądać tak, jak podczas pierwszej wizyty na tej stronie (zobacz rysunek 3).

Krok 3. Szyfrowanie sekcji konfiguracji przy użyciu aspnet_regiis.exe

Program .NET Framework zawiera różne narzędzia wiersza polecenia w folderze $WINDOWS$\Microsoft.NET\Framework\version\ . Na przykład w samouczku Using SQL Cache Dependencies (Korzystanie z zależności pamięci podręcznej SQL) omówiliśmy użycie aspnet_regsql.exe narzędzia wiersza polecenia w celu dodania infrastruktury niezbędnej dla zależności pamięci podręcznej SQL. Innym przydatnym narzędziem wiersza polecenia w tym folderze jest narzędzie rejestracji ASP.NET IIS (aspnet_regiis.exe). Jak sama nazwa wskazuje, narzędzie rejestracji usług IIS ASP.NET jest używane głównie do rejestrowania aplikacji ASP.NET 2.0 za pomocą serwera sieci Web klasy profesjonalnej firmy Microsoft, usług IIS. Oprócz funkcji związanych z usługami IIS narzędzie rejestracji usług IIS ASP.NET można również użyć do szyfrowania lub odszyfrowania określonych sekcji konfiguracji w programie Web.config.

Poniższa instrukcja pokazuje ogólną składnię używaną do szyfrowania sekcji konfiguracji za pomocą narzędzia wiersza polecenia aspnet_regiis.exe.

aspnet_regiis.exe -pef section physical_directory -prov provider

sekcja to sekcja konfiguracji do szyfrowania (na przykład connectionStrings ), physical_directory jest pełną, fizyczną ścieżką do katalogu głównego aplikacji internetowej, a dostawca jest nazwą chronionego dostawcy konfiguracji do użycia (na przykład DataProtectionConfigurationProvider). Alternatywnie, jeśli aplikacja internetowa jest zarejestrowana w usługach IIS, możesz wprowadzić ścieżkę wirtualną zamiast ścieżki fizycznej przy użyciu następującej składni:

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

aspnet_regiis.exe Poniższy przykład szyfruje sekcję <connectionStrings> przy użyciu dostawcy DPAPI z kluczem na poziomie komputera:

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

aspnet_regiis.exe Podobnie narzędzie wiersza polecenia może służyć do odszyfrowywania sekcji konfiguracji. Zamiast używać przełącznika -pef , użyj polecenia -pdf (lub zamiast -pe, użyj polecenia -pd). Należy również pamiętać, że nazwa dostawcy nie jest konieczna podczas odszyfrowywania.

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

Omówienie opcji uwierzytelniania bazy danych

Zanim jakakolwiek aplikacja będzie mogła przesyłać zapytania SELECT, INSERT, UPDATE lub DELETE do bazy danych Microsoft SQL Server, baza danych musi najpierw zidentyfikować żądającego. Ten proces jest znany jako uwierzytelnianie , a program SQL Server udostępnia dwie metody uwierzytelniania:

• Uwierzytelnianie systemu Windows — proces, w którym działa aplikacja, jest używany do komunikowania się z bazą danych. W przypadku uruchamiania aplikacji ASP.NET za pomocą programu Visual Studio 2005 s ASP.NET Development Server aplikacja ASP.NET zakłada tożsamość aktualnie zalogowanego użytkownika. W przypadku aplikacji ASP.NET w programie Microsoft Internet Information Server (IIS) aplikacje ASP.NET zwykle zakładają tożsamość domainName``\MachineName lub domainName``\NETWORK SERVICE, chociaż można to dostosować.
• Uwierzytelnianie SQL — identyfikator użytkownika i wartości hasła są dostarczane jako poświadczenia w celu uwierzytelniania. W przypadku uwierzytelniania SQL identyfikator użytkownika i hasło są podane w parametry połączenia.

Uwierzytelnianie systemu Windows jest preferowane za pośrednictwem uwierzytelniania SQL, ponieważ jest bezpieczniejsze. W przypadku uwierzytelniania systemu Windows ciąg połączenia jest pozbawiony nazwy użytkownika i hasła, a jeśli serwer sieciowy i serwer bazy danych znajdują się na dwóch różnych maszynach, poświadczenia nie są wysyłane przez sieć w postaci zwykłego tekstu. Jednak w przypadku uwierzytelniania SQL poświadczenia uwierzytelniania są zakodowane w parametry połączenia i są przesyłane z serwera internetowego do serwera bazy danych w postaci zwykłego tekstu.

W tych samouczkach użyto uwierzytelniania systemu Windows. Możesz określić, jaki tryb uwierzytelniania jest używany, sprawdzając parametry połączenia. W naszych samouczkach ciąg połączenia w Web.config był:

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

Zintegrowane zabezpieczenia = True i brak nazwy użytkownika oraz hasła oznaczają, że jest używane uwierzytelnianie systemu Windows. W niektórych parametry połączenia termin Zaufane połączenie=Tak lub Zintegrowane zabezpieczenia=SSPI jest używany zamiast Zintegrowane zabezpieczenia=True, ale wszystkie trzy wskazują użycie uwierzytelniania systemu Windows.

W poniższym przykładzie przedstawiono ciąg połączenia używający uwierzytelniania SQL. $CREDENTIAL_PLACEHOLDER$ jest zastępczą wartością dla pary klucz-wartość hasła. Zanotuj, że poświadczenia są osadzone w parametry połączenia:

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

Załóżmy, że osoba atakująca może wyświetlić plik aplikacji Web.config . Jeśli używasz uwierzytelniania SQL do nawiązywania połączenia z bazą danych, która jest dostępna za pośrednictwem Internetu, osoba atakująca może użyć tego ciągu połączenia do nawiązania połączenia z Twoją bazą danych za pośrednictwem programu SQL Management Studio lub z własnych stron ASP.NET na własnej witrynie internetowej. Aby pomóc w ograniczeniu tego zagrożenia, zaszyfruj informacje o ciągu połączenia w Web.config za pomocą chronionego systemu konfiguracji.

Podsumowanie

Domyślnie pliki z .config rozszerzeniem w aplikacji ASP.NET nie mogą być dostępne za pośrednictwem przeglądarki. Te typy plików nie są zwracane, ponieważ mogą zawierać poufne informacje, takie jak parametry połączenia bazy danych, nazwy użytkowników i hasła itd. Chroniony system konfiguracji na platformie .NET 2.0 pomaga dodatkowo chronić poufne informacje, umożliwiając szyfrowanie określonych sekcji konfiguracji. Istnieją dwa wbudowane dostawcy konfiguracji chronionej: jeden, który używa algorytmu RSA i jeden, który korzysta z interfejsu API ochrony danych systemu Windows (DPAPI).

W tym samouczku zajęliśmy się szyfrowaniem i odszyfrowywaniem ustawień konfiguracji przy użyciu dostawcy DPAPI. Można to osiągnąć zarówno programowo, jak pokazano w kroku 2, jak i za pomocą aspnet_regiis.exe narzędzia wiersza polecenia, które zostało omówione w kroku 3. Aby uzyskać więcej informacji na temat używania kluczy na poziomie użytkownika lub zamiast tego przy użyciu dostawcy RSA, zobacz zasoby w sekcji Dalsze informacje.

Szczęśliwe programowanie!

Dalsze informacje

Aby uzyskać więcej informacji na temat tematów omówionych w tym samouczku, zapoznaj się z następującymi zasobami:

• Tworzenie bezpiecznej aplikacji ASP.NET: uwierzytelnianie, autoryzacja i bezpieczna komunikacja
• Szyfrowanie informacji o konfiguracji w aplikacjach ASP.NET 2.0
• Web.config Szyfrowanie wartości w ASP.NET 2.0
• Instrukcje: szyfrowanie sekcji konfiguracji w programie ASP.NET 2.0 przy użyciu interfejsu DPAPI
• Instrukcje: szyfrowanie sekcji konfiguracji w ASP.NET 2.0 przy użyciu rsa
• Interfejs API konfiguracji na platformie .NET 2.0
• Ochrona danych systemu Windows

Informacje o autorze

Scott Mitchell, autor siedmiu książek ASP/ASP.NET i założyciel 4GuysFromRolla.com, współpracuje z technologiami internetowymi firmy Microsoft od 1998 roku. Scott pracuje jako niezależny konsultant, trener i pisarz. Jego najnowsza książka to Sams Teach Yourself ASP.NET 2.0 w 24 godzinach. Można go uzyskać pod adresem mitchell@4GuysFromRolla.com.

Specjalne podziękowania

Ta seria samouczków została omówiona przez wielu przydatnych recenzentów. Wiodący recenzenci tego samouczka to Teresa Murphy i Randy Schmidt. Chcesz przejrzeć nadchodzące artykuły MSDN? Jeśli tak, napisz do mnie na adres mitchell@4GuysFromRolla.com.