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

A: Scott Mitchell

Pobieranie kodu lub pobieranie pliku PDF

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

Wprowadzenie

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

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

Odwiedzenie Web.config za pośrednictwem przeglądarki zwraca komunikat o tym typie strony nie jest obsługiwany

Rysunek 1. Odwiedzenie strony za pośrednictwem przeglądarki zwraca komunikat o tym typie strony nie jest obsługiwany Web.config (Kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Ale co zrobić, jeśli osoba atakująca będzie mogła znaleźć inne luki w zabezpieczeniach, które umożliwią jej wyświetlenie Web.config zawartości pliku? Co osoba atakująca może wykorzystać do tych informacji i jakie kroki można podjąć w celu dalszej ochrony poufnych informacji w programie Web.config ? Na szczęście większość sekcji w Web.config sekcji nie zawiera informacji poufnych. Jakie szkody może wywłaszcić osoba atakująca, jeśli zna nazwę domyślnego motywu używanego przez ASP.NET stron?

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

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

W tym samouczku przyjrzymy się technikom ochrony poufnych informacji o konfiguracji. Jak zobaczymy, wersja .NET Framework 2.0 zawiera system chronionych konfiguracji, który sprawia, że programowe szyfrowanie i odszyfrowywanie wybranych sekcji konfiguracji jest proste.

Note

Ten samouczek kończy się zaleceniami firmy Microsoft w zakresie nawiązywania połączenia z bazą danych z ASP.NET aplikacji. Oprócz szyfrowania ciągów połączeń możesz pomóc w wzmacnianiu systemu, zapewniając bezpieczne nawiązywanie połączenia z bazą danych.

Krok 1. Eksplorowanie ASP.NET chronionych opcji konfiguracji w programie 2.0

ASP.NET 2.0 obejmuje chroniony system konfiguracji do szyfrowania i odszyfrowywania informacji o konfiguracji. Obejmuje to metody w .NET Framework, których można używać do programowego szyfrowania lub odszyfrowywania informacji o konfiguracji. Chroniony system konfiguracji używa modelu dostawcy, który umożliwia deweloperom wybranie implementacji kryptograficznych.

Dostawca .NET Framework dostarczany z dwoma dostawcami chronionej konfiguracji:

Ponieważ chroniony system konfiguracji implementuje wzorzec projektowy 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 chronionego dostawcy konfiguracji.

Dostawcy RSA i DPAPI używają kluczy na potrzeby procedur szyfrowania i odszyfrowywania, a te klucze mogą być przechowywane na poziomie komputera lub użytkownika. Klucze na poziomie komputera są idealne w scenariuszach, w których aplikacja internetowa działa na własnym dedykowanym serwerze lub jeśli na serwerze istnieje wiele aplikacji, które muszą udostępniać zaszyfrowane informacje. Klucze na poziomie użytkownika są bezpieczniejszą opcją w współdzielonych środowiskach hostingu, w których inne aplikacje na tym samym serwerze nie powinny mieć możliwości odszyfrowania chronionych sekcji konfiguracji aplikacji.

W tym samouczku w naszych przykładach użyjemy dostawcy DPAPI i kluczy na poziomie komputera. W szczególności przyjrzymy się szyfrowaniu sekcji w pliku , chociaż chroniony system konfiguracji może służyć do szyfrowania <connectionStrings> Web.config większości Web.config sekcji. 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.

Note

Dostawcy i są zarejestrowani w pliku przy użyciu odpowiednio nazw RSAProtectedConfigurationProvider DPAPIProtectedConfigurationProvider dostawców i machine.config RsaProtectedConfigurationProvider DataProtectionConfigurationProvider . Podczas szyfrowania lub odszyfrowywania informacji o konfiguracji należy podać odpowiednią nazwę dostawcy ( lub ), a nie rzeczywistą RsaProtectedConfigurationProvider nazwę typu ( i DataProtectionConfigurationProvider RSAProtectedConfigurationProvider DPAPIProtectedConfigurationProvider ). Plik można machine.config znaleźć w $WINDOWS$\Microsoft.NET\Framework\version\CONFIG folderze .

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ływać się do odpowiedniej sekcji konfiguracji, wywołać metodę lub , a następnie wywołać metodę , aby utrwalić ProtectSection UnprotectSection Save zmiany. Ponadto program .NET Framework przydatne narzędzie wiersza polecenia, które może szyfrować i odszyfrowywać informacje o konfiguracji. To narzędzie wiersza polecenia zostanie zbadane w kroku 3.

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

Rozpocznij od otwarcia EncryptingConfigSections.aspx strony w AdvancedDAL folderze . Przeciągnij kontrolkę TextBox z przybornika do projektanta, ustawiając jej właściwość na , jej właściwość na , a właściwości i odpowiednio na ID WebConfigContents TextMode MultiLine Width Rows 95% i 15. Ta kontrolka TextBox wyświetli zawartość kontrolki , co pozwoli nam szybko sprawdzić, czy Web.config zawartość jest zaszyfrowana. Oczywiście w rzeczywistej aplikacji nigdy nie chcesz wyświetlać zawartości pliku Web.config .

Pod kontrolką TextBox dodaj dwie kontrolki Button o EncryptConnStrings nazwach i DecryptConnStrings . Ustaw ich właściwości tekstowe na wartość Encrypt Connection Strings (Szyfruj parametry połączeń) i Decrypt Connection Strings (Odszyfruj parametry połączenia).

W tym momencie ekran powinien wyglądać podobnie do rysunku 2.

Dodawanie kontrolki Internetowej TextBox i dwóch przycisków do strony

Rysunek 2. Dodawanie kontrolki internetowej TextBox i dwóch przycisków do strony (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

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

Metoda używa klasy do otwierania pliku s aplikacji, klasy , aby odczytać jej zawartość do ciągu, oraz klasy w celu wygenerowania ścieżki DisplayWebConfig File Web.config fizycznej do StreamReader Path Web.config pliku. Te trzy klasy znajdują się w przestrzeni System.IO nazw. W związku z tym należy dodać instrukcje na początku klasy kodu lub, alternatywnie, poprzeć te nazwy using System.IO klas prefiksem System.IO. .

Następnie musimy dodać procedury obsługi zdarzeń dla dwóch zdarzeń kontrolki Przycisk i dodać kod niezbędny do zaszyfrowania i odszyfrowania sekcji przy użyciu klucza na poziomie komputera z Click <connectionStrings> dostawcą DPAPI. W projektancie kliknij dwukrotnie każdy przycisk, aby dodać program obsługi zdarzeń w klasie code-behind, a następnie Click 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 procedurach obsługi zdarzeń jest niemal identyczny. Obaj zaczynają się od uzyskania informacji o bieżącym pliku s Web.config aplikacji za WebConfigurationManager pośrednictwem metody klasy OpenWebConfiguration s. Ta metoda zwraca plik konfiguracji sieci Web dla określonej ścieżki wirtualnej. Następnie do Web.config sekcji pliku jest <connectionStrings> uzyskiwany GetSection(sectionName) dostęp za Configuration pośrednictwem metody klasy s , która zwraca ConfigurationSection obiekt .

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

Metoda przyjmuje jako dane wejściowe ciąg określający nazwę chronionego dostawcy konfiguracji, który ProtectSection(provider) ma być używany podczas szyfrowania. W EncryptConnString programie obsługi zdarzeń Przycisk przekażemy do metody metodę DataProtectionConfigurationProvider, aby użyć dostawcy ProtectSection(provider) DPAPI. Metoda może określić dostawcę, który został użyty do zaszyfrowania sekcji konfiguracji i dlatego UnprotectSection nie wymaga żadnych parametrów wejściowych.

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

Po wprowadzeniu powyższego kodu przetestuj go, odwiedzając EncryptingConfigSections.aspx stronę w przeglądarce. Na początku powinna zostać wyświetlona strona z zawartością pliku z sekcją wyświetlaną w postaci zwykłego Web.config <connectionStrings> tekstu (zobacz Rysunek 3).

Dodawanie kontrolki Internetowej TextBox i dwóch przycisków do strony

Rysunek 3. Dodawanie kontrolki internetowej TextBox i dwóch przycisków do strony (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Teraz kliknij przycisk Szyfruj parametry połączenia. Jeśli weryfikacja żądania jest włączona, znacznik opublikowany z powrotem z pola TextBox spowoduje wyświetlenie komunikatu . Klient wykrył potencjalnie niebezpieczną WebConfigContents HttpRequestValidationException Request.Form wartość. Walidacja żądań, która jest domyślnie włączona w wersji ASP.NET 2.0, uniemożliwia wykonywanie wpisów zwrotnych, które zawierają niekodowany kod HTML, i ma na celu zapobieganie atakom iniekcji skryptów. To sprawdzenie można wyłączyć na poziomie strony lub aplikacji. Aby wyłączyć tę stronę, ustaw ValidateRequest ustawienie na w false @Page dyrektywie . Dyrektywa znajduje się w górnej części deklaratywnego @Page znacznika strony.

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

Aby uzyskać więcej informacji na temat weryfikacji żądania, jego przeznaczenia, sposobu wyłączania go na poziomie strony i aplikacji, a także sposobu kodowania znaczników HTML, zobacz Request Validation - Preventing Script Attacks(Weryfikacja żądań — zapobieganie atakom skryptowym).

Po wyłączeniu weryfikacji żądania dla strony spróbuj ponownie kliknąć przycisk Szyfruj parametry połączeń. Po przywróceniu zostanie uzyskany dostęp do pliku konfiguracji i jego <connectionStrings> sekcja zostanie zaszyfrowana przy użyciu dostawcy DPAPI. Następnie pole TextBox zostanie zaktualizowane w celu wyświetlenia nowej Web.config zawartości. Jak pokazano na rysunku 4, <connectionStrings> informacje są teraz szyfrowane.

Kliknięcie przycisku Szyfruj parametry połączenia powoduje < zaszyfrowanie sekcji connectionString >

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

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

<connectionStrings 
    configProtectionProvider="DataProtectionConfigurationProvider">
  <EncryptedData>
    <CipherData>
      <CipherValue>AQAAANCMnd8BFdERjHoAwE/...zChw==</CipherValue>
    </CipherData>
  </EncryptedData>
</connectionStrings>

Note

Element <connectionStrings> określa dostawcę używanego do wykonywania szyfrowania ( DataProtectionConfigurationProvider ). Te informacje są używane przez UnprotectSection metodę po kliknięciu przycisku Odszyfruj parametry połączenia.

Gdy uzyskuje się dostęp do informacji o parametrów połączenia — za pomocą kodu, który zapisujemy, z kontrolki SqlDataSource lub automatycznie wygenerowanego kodu z obiektu TableAdapers w typowanych zestawach danych — są automatycznie odszyfrowywały. Web.config Krótko mówiąc, nie musimy dodawać żadnego dodatkowego kodu ani logiki, aby odszyfrować zaszyfrowaną <connectionString> sekcję. Aby to zademonstrować, przejdź do jednego z wcześniejszych samouczków w tej chwili, na przykład samouczka prostego wyświetlania z sekcji Podstawowe raportowanie ( ~/BasicReporting/SimpleDisplay.aspx ). Jak pokazano na rysunku 5, samouczek działa dokładnie tak, jak można by było się tego spodziewać, co oznacza, że zaszyfrowane informacje o parametrów połączenia są automatycznie odszyfrowywowane przez ASP.NET sieci Web.

Warstwa dostępu do danych automatycznie odszyfrowuje informacje o parametrów połączenia

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

Aby przywrócić reprezentację sekcji w <connectionStrings> postaci zwykłego tekstu, kliknij przycisk Decrypt Connection Strings (Odszyfruj parametry połączenia). W przypadku postbacku parametry połączenia powinny być w Web.config formacie w postaci zwykłego tekstu. W tym momencie ekran powinien wyglądać tak, jak podczas pierwszego odwiedzania tej strony (zobacz rysunek 3).

Krok 3. Szyfrowanie sekcji konfiguracji przy użyciuaspnet_regiis.exe

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

Następująca instrukcja przedstawia ogólną składnię używaną do szyfrowania sekcji konfiguracji za pomocą aspnet_regiis.exe narzędzia wiersza polecenia:

aspnet_regiis.exe -pef section physical_directory -prov provider

sekcja to sekcja konfiguracji szyfrowania (na przykład connectionStrings), katalog fizyczny jest pełną, fizyczną ścieżką do katalogu głównego aplikacji internetowej, a dostawca to nazwa 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

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

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

Podobnie narzędzie wiersza polecenia może służyć do aspnet_regiis.exe odszyfrowywania sekcji konfiguracji. Zamiast używać -pef przełącznika, użyj -pdf (lub zamiast -pe , użyj . -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

Note

Ponieważ używamy dostawcy DPAPI, który używa kluczy specyficznych dla komputera, musisz uruchomić program z tego samego komputera, z którego są aspnet_regiis.exe obsługiwane strony internetowe. Jeśli na przykład uruchamiasz ten program wiersza polecenia z lokalnej maszyny dewelopernej, a następnie przekażemy zaszyfrowany plik Web.config na serwer produkcyjny, serwer produkcyjny nie będzie mógł odszyfrować informacji o parametrów połączenia, ponieważ zostały zaszyfrowane przy użyciu kluczy specyficznych dla maszyny dewelopera. Dostawca RSA nie ma tego ograniczenia, ponieważ możliwe jest wyeksportowanie kluczy RSA na inną maszynę.

Omówienie opcji uwierzytelniania bazy danych

Zanim dowolna aplikacja będzie w stanie wysyłać zapytania do bazy Microsoft SQL Server, baza danych musi najpierw SELECT INSERT zidentyfikować osobę UPDATE DELETE żądaną. Ten proces jest nazywany uwierzytelnianiem, SQL Server udostępnia dwie metody uwierzytelniania:

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

Uwierzytelnianie systemu Windows jest preferowane niż uwierzytelnianie SQL, ponieważ jest bezpieczniejsze. W przypadku uwierzytelniania systemu Windows ciągi połączenia są wolne od nazwy użytkownika i hasła, a jeśli serwer internetowy 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 ciągu połączenia i przesyłane z serwera internetowego do serwera bazy danych w postaci zwykłego tekstu.

W tych samouczkach wykorzystano uwierzytelnianie systemu Windows. Aby określić, jaki tryb uwierzytelniania jest używany, sprawdź ciąg połączenia. W naszych samouczkach Web.config zawarto ciąg połączenia:

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

Zintegrowane zabezpieczenia =True i brak nazwy użytkownika i hasła wskazują, ż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 zabezpieczeń = True, ale wszystkie trzy wskazują na użycie uwierzytelniania systemu Windows.

W poniższym przykładzie pokazano ciąg połączenia, który używa uwierzytelniania SQL. $CREDENTIAL_PLACEHOLDER$ jest symbolem zastępczym pary klucz-wartość hasła. Pamiętaj, że poświadczenia są osadzone w ramach parametrów połączenia:

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

Załóżmy, że osoba atakująca może wyświetlić plik Web.config aplikacji. Jeśli używasz uwierzytelniania SQL do nawiązywania połączenia z bazą danych dostępną przez Internet, osoba atakująca może użyć tych parametrów połączenia do nawiązania połączenia z bazą danych za pośrednictwem usługi SQL Management Studio lub stron ASP.NET we własnej witrynie internetowej. Aby uniknąć tego zagrożenia, zaszyfruj informacje o parametrów połączenia w Web.config programie przy użyciu chronionego systemu konfiguracji.

Note

Aby uzyskać więcej informacji na temat różnych typów uwierzytelniania dostępnych w programie SQL Server, zobacz Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication(Tworzenie bezpiecznych aplikacji ASP.NET: uwierzytelnianie, autoryzacja i bezpieczna komunikacja). Aby uzyskać więcej przykładów parametrów połączenia ilustrujących różnice między składnią uwierzytelniania systemu Windows i języka SQL, zobacz ConnectionStrings.com.

Podsumowanie

Domyślnie pliki z rozszerzeniem w aplikacji ASP.NET są dostępne .config 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 itp. Chroniony system konfiguracji w programie .NET 2.0 pomaga dodatkowo chronić poufne informacje, umożliwiając szyfrowanie określonych sekcji konfiguracji. Istnieją dwaj dostawcy wbudowanej chronionej konfiguracji: jeden, który używa algorytmu RSA, i jeden, który używa interfejsu API ochrony danych systemu Windows (DPAPI).

W tym samouczku przyjrzeliśmy się, jak szyfrować i odszyfrowywać ustawienia konfiguracji przy użyciu dostawcy DPAPI. Można to osiągnąć zarówno programowo, jak i za pomocą narzędzia wiersza polecenia, które zostało uwzględnione w aspnet_regiis.exe kroku 3. Aby uzyskać więcej informacji na temat używania kluczy na poziomie użytkownika lub używania dostawcy RSA, zobacz zasoby w sekcji Dalsze informacje.

Happy Programming!

Dalsze informacje

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

Informacje o autorze

Scott Mitchell,autor siedmiu książek ASP/ASP.NET i twórca 4GuysFromRolla.com,od 1998 roku pracuje z technologiami internetowymi firmy Microsoft. Scott pracuje jako niezależny konsultant, instruktor i autor. Jego najnowsza książka to Sams Teach Yourself ASP.NET 2.0 in 24 Hours.... Jest on osiągany na stronie mitchell@4GuysFromRolla.com . lub za pośrednictwem jego bloga, który można znaleźć na stronie http://ScottOnWriting.NET .

Specjalne podziękowania dla

Ta seria samouczków została przejrzysła wielu przydatnych recenzentów. W tym samouczku werytatorami potencjalnych kandydatów byli Jednak Murphy i Randy Schmidt. Chcesz przejrzeć nadchodzące artykuły w witrynie MSDN? Jeśli tak, porzuć mi wiersz mitchell@4GuysFromRolla.com pod .