Ochrona parametrów połączeń i innych informacji o konfiguracji (VB)
Autor : Scott Mitchell
Aplikacja ASP.NET zwykle przechowuje informacje o konfiguracji w pliku Web.config. Niektóre z tych informacji są poufne i gwarantują 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. W tym samouczku 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 parametry połączenia informacje zostały automatycznie dodane do Web.config
sekcji <connectionStrings>
. W dalszej części samouczka Strony wzorcowe i Nawigacja w witrynie ręcznie zaktualizowaliśmy Web.config
element , dodając <pages>
element 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 osobami przeglądającym. 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 jest wyświetlany na rysunku 1. Oznacza to, że osoby odwiedzające nie mogą wyświetlić Web.config
zawartości pliku, wprowadzając po prostu http://www.YourServer.com/Web.config na pasku adresu przeglądarki.
Rysunek 1. Odwiedzanie Web.config
za pośrednictwem przeglądarki zwraca komunikat tego typu nie jest obsługiwany (kliknij, aby wyświetlić obraz w pełnym rozmiarze)
Ale co zrobić, jeśli osoba atakująca może znaleźć inny program wykorzystujący, który pozwala jej wyświetlić Web.config
zawartość pliku? Co osoba atakująca może zrobić z takimi informacjami i jakie kroki można podjąć w celu dalszej ochrony poufnych informacji w programie 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 ASP.NET stron?
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 poufnych informacji o konfiguracji. Jak zobaczymy, .NET Framework wersja 2.0 zawiera chroniony system konfiguracji, który sprawia, że programowe szyfrowanie i odszyfrowywanie wybranych sekcji konfiguracji jest proste.
Uwaga
Ten samouczek zawiera omówienie zaleceń firmy Microsoft dotyczących nawiązywania połączenia z bazą danych z aplikacji ASP.NET. Oprócz szyfrowania parametrów połączenia, możesz pomóc w wzmacnianiu zabezpieczeń systemu, upewniając się, że łączysz się z bazą danych w bezpieczny sposób.
Krok 1. Eksplorowanie opcji konfiguracji chronionych ASP.NET 2.0 s
ASP.NET 2.0 zawiera chroniony system konfiguracji do szyfrowania i odszyfrowywania informacji o konfiguracji. Obejmuje to metody w .NET Framework, których można użyć do programowego szyfrowania lub odszyfrowywania informacji o konfiguracji. System konfiguracji chronionej korzysta z modelu dostawcy, który umożliwia deweloperom wybór implementacji kryptograficznych.
.NET Framework dostarczane 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 chronionego dostawcy konfiguracji .
Dostawcy RSA i DPAPI używają kluczy dla 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 na serwerze jest wiele aplikacji, które muszą udostępniać zaszyfrowane informacje. Klucze na poziomie użytkownika to bezpieczniejsza opcja w udostępnionych środowiskach hostingu, 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 <connectionStrings>
sekcji w Web.config
programie , chociaż chroniony system konfiguracji może służyć do szyfrowania większości sekcji Web.config
. Aby uzyskać informacje na temat korzystania z kluczy na poziomie użytkownika lub korzystania z dostawcy RSA, zapoznaj się z zasobami w sekcji Dalsze informacje na końcu tego samouczka.
Uwaga
Dostawcy RSAProtectedConfigurationProvider
i DPAPIProtectedConfigurationProvider
są zarejestrowani w machine.config
pliku z nazwami RsaProtectedConfigurationProvider
dostawców i DataProtectionConfigurationProvider
, odpowiednio. Podczas szyfrowania lub odszyfrowywania informacji o konfiguracji należy podać odpowiednią nazwę dostawcy (RsaProtectedConfigurationProvider
lub DataProtectionConfigurationProvider
), a nie rzeczywistą nazwę typu (RSAProtectedConfigurationProvider
i DPAPIProtectedConfigurationProvider
). Plik można znaleźć machine.config
w folderze $WINDOWS$\Microsoft.NET\Framework\version\CONFIG
.
Krok 2. Programowe szyfrowanie i odszyfrowywanie sekcji konfiguracji
Za pomocą kilku wierszy kodu można 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ę w celu utrwałości zmian. Ponadto .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 EncryptingConfigSections.aspx
strony w folderze AdvancedDAL
. Przeciągnij kontrolkę TextBox z przybornika na Projektant, ustawiając jej ID
właściwość na WebConfigContents
, TextMode
jej właściwość na MultiLine
, oraz Width
Rows
jej właściwości odpowiednio na 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 właściwości Text na wartość Szyfruj parametry połączenia i Odszyfruj parametry połączenia.
Na tym etapie ekran powinien wyglądać podobnie do rysunku 2.
Rysunek 2. Dodawanie kontrolki TextBox i Dwie kontrolki sieci Web przycisku do strony (kliknij, aby wyświetlić obraz pełnowymiarowy)
Następnie musimy napisać kod, który ładuje i wyświetla zawartość Web.config
elementu WebConfigContents
w polu TextBox po pierwszym załadowaniu strony. Dodaj następujący kod do klasy s code-behind strony. Ten kod dodaje metodę o nazwie DisplayWebConfig
i wywołuje ją z Page_Load
programu obsługi zdarzeń, gdy Page.IsPostBack
ma wartość False
:
Protected Sub Page_Load(sender As Object, e As EventArgs) Handles Me.Load
'On the first page visit, call DisplayWebConfig method
If Not Page.IsPostBack Then
DisplayWebConfig()
End If
End Sub
Private Sub DisplayWebConfig()
'Reads in the contents of Web.config and displays them in the TextBox
Dim webConfigStream As StreamReader = _
File.OpenText(Path.Combine(Request.PhysicalApplicationPath, "Web.config"))
Dim configContents As String = webConfigStream.ReadToEnd()
webConfigStream.Close()
WebConfigContents.Text = configContents
End Sub
Metoda DisplayWebConfig
używa File
klasy , aby otworzyć plik aplikacji Web.config
, StreamReader
klasę , aby odczytać jego zawartość do ciągu, a Path
klasę 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ę Imports``System.IO
na początku klasy za kodem lub, alternatywnie, prefiks tych nazw klas za pomocą polecenia System.IO.
Następnie musimy dodać programy obsługi zdarzeń dla dwóch zdarzeń przycisków Click
i dodać niezbędny kod do szyfrowania i odszyfrowywania <connectionStrings>
sekcji przy użyciu klucza na poziomie maszyny u dostawcy DPAPI. W Projektant 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 Sub EncryptConnStrings_Click(sender As Object, e As EventArgs) _
Handles EncryptConnStrings.Click
'Get configuration information about Web.config
Dim config As Configuration = _
WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath)
' Let's work with the <connectionStrings> section
Dim connectionStrings As ConfigurationSection = _
config.GetSection("connectionStrings")
If connectionStrings IsNot Nothing Then
' Only encrypt the section if it is not already protected
If Not connectionStrings.SectionInformation.IsProtected Then
' Encrypt the <connectionStrings> section using the
' DataProtectionConfigurationProvider provider
connectionStrings.SectionInformation.ProtectSection( _
"DataProtectionConfigurationProvider")
config.Save()
' Refresh the Web.config display
DisplayWebConfig()
End If
End If
End Sub
Protected Sub DecryptConnStrings_Click(sender As Object, e As EventArgs) _
Handles DecryptConnStrings.Click
' Get configuration information about Web.config
Dim config As Configuration = _
WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath)
' Let's work with the <connectionStrings> section
Dim connectionStrings As ConfigurationSection = _
config.GetSection("connectionStrings")
If connectionStrings IsNot Nothing Then
' Only decrypt the section if it is protected
If connectionStrings.SectionInformation.IsProtected Then
' Decrypt the <connectionStrings> section
connectionStrings.SectionInformation.UnprotectSection()
config.Save()
' Refresh the Web.config display
DisplayWebConfig()
End If
End If
End Sub
Kod używany w dwóch programach obsługi zdarzeń jest prawie identyczny. Oba te elementy zaczynają się od uzyskania informacji o bieżącym pliku aplikacji Web.config
za pośrednictwem WebConfigurationManager
metody klasy sOpenWebConfiguration
. Ta metoda zwraca plik konfiguracji sieci Web dla określonej ścieżki wirtualnej. Następnie dostęp do sekcji pliku <connectionStrings>
jest uzyskiwany za pośrednictwem Configuration
metody klasy sGetSection(sectionName)
, która zwraca ConfigurationSection
obiekt.Web.config
Obiekt ConfigurationSection
zawiera SectionInformation
właściwość , która zawiera dodatkowe informacje i funkcje dotyczące sekcji konfiguracji. Jak pokazano w powyższym kodzie, możemy określić, czy sekcja konfiguracji jest szyfrowana, sprawdzając SectionInformation
właściwość s IsProtected
właściwości. 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 procedurze EncryptConnString
obsługi zdarzeń przycisku przekazujemy element DataProtectionConfigurationProvider do ProtectSection(provider)
metody , aby dostawca DPAPI był używany. Metoda UnprotectSection
może określić dostawcę, który został użyty do szyfrowania sekcji konfiguracji i dlatego nie wymaga żadnych parametrów wejściowych.
Po wywołaniu ProtectSection(provider)
metody or UnprotectSection
należy wywołać metodę Configuration
object sSave
, aby utrwała zmiany. Po zaszyfrowaniu lub odszyfrowaniu informacji o konfiguracji i zapisaniu zmian wywołujemy metodę DisplayWebConfig
ładowania zaktualizowanej Web.config
zawartości do kontrolki TextBox.
Po wprowadzeniu powyższego kodu przetestuj EncryptingConfigSections.aspx
go, odwiedzając stronę za pośrednictwem przeglądarki. Początkowo powinna zostać wyświetlona strona zawierająca zawartość Web.config
sekcji wyświetlanej w postaci zwykłego <connectionStrings>
tekstu (zobacz Rysunek 3).
Rysunek 3. Dodawanie kontrolki TextBox i Dwie kontrolki sieci Web przycisku do strony (kliknij, aby wyświetlić obraz pełnowymiarowy)
Teraz kliknij przycisk Szyfruj parametry połączenia. Jeśli walidacja żądania jest włączona, znaczniki opublikowane z poziomu kontrolki WebConfigContents
TextBox spowodują HttpRequestValidationException
wygenerowanie komunikatu , co spowoduje wykrycie potencjalnie niebezpiecznej Request.Form
wartości od klienta. Walidacja żądań, która jest domyślnie włączona w ASP.NET 2.0, uniemożliwia ogłaszanie zwrotne zawierające kod HTML bez kodowania i ma na celu zapobieganie atakom polegającym na wstrzyknięciu skryptu. To sprawdzenie można wyłączyć na poziomie strony lub aplikacji. Aby wyłączyć tę stronę, ustaw ValidateRequest
ustawienie na False
w @Page
dyrektywie . Dyrektywa @Page
znajduje się w górnej części strony narzutu deklaratywnego.
<%@ Page ValidateRequest="False" ... %>
Aby uzyskać więcej informacji na temat weryfikacji żą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 wycofaniu plik konfiguracji będzie dostępny, a jego <connectionStrings>
sekcja zostanie zaszyfrowana przy użyciu dostawcy DPAPI. Pole TextBox jest następnie aktualizowane, aby wyświetlić nową Web.config
zawartość. 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 pełnowymiarowy)
Sekcja zaszyfrowana <connectionStrings>
wygenerowana na moim komputerze jest następująca, chociaż część zawartości w <CipherData>
elemecie została usunięta w celu zwięzłości:
<connectionStrings
configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>AQAAANCMnd8BFdERjHoAwE/...zChw==</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>
Uwaga
Element <connectionStrings>
określa dostawcę używanego do szyfrowania (DataProtectionConfigurationProvider
). Te informacje są używane przez metodę po kliknięciu UnprotectSection
przycisku Odszyfruj parametry połączenia.
Gdy dostęp do informacji o parametry połączenia jest uzyskiwany za Web.config
pomocą kodu, który piszemy, z kontrolki SqlDataSource lub kod wygenerowany automatycznie z tabeli TableAdapters w naszych typowych zestawach danych — jest automatycznie odszyfrowywane. 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, na przykład samouczek dotyczący prostego wyświetlania w sekcji Podstawowa raportowanie (~/BasicReporting/SimpleDisplay.aspx
). Jak pokazano na rysunku 5, samouczek działa dokładnie tak, jak się spodziewamy, wskazując, że zaszyfrowane informacje parametry 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 pełnowymiarowy)
Aby przywrócić sekcję <connectionStrings>
z powrotem do jej reprezentacji zwykłego tekstu, kliknij przycisk Odszyfruj parametry połączenia. Po powrocie zwrotne powinny zostać wyświetlone parametry połączenia w Web.config
postaci zwykłego tekstu. Na tym etapie ekran powinien wyglądać tak, jak podczas pierwszej wizyty na tej stronie (zobacz na rysunku 3).
Krok 3. Szyfrowanie sekcji konfiguracji przy użyciu aspnet_regiis.exe
.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) przyjrzeliśmy się używaniu 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 ASP.NET narzędzie rejestracji usług IIS (aspnet_regiis.exe
). Jak wskazuje nazwa, narzędzie rejestracji usług IIS ASP.NET jest używane głównie do rejestrowania aplikacji ASP.NET 2.0 z serwerem sieci Web klasy profesjonalnej firmy Microsoft, usługami IIS. Oprócz funkcji związanych z usługami IIS narzędzie rejestracji usług IIS ASP.NET może być również używane do szyfrowania lub odszyfrowywania określonych sekcji konfiguracji w programie Web.config
.
Poniższa 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 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_VB"
-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
Uwaga
Ponieważ używamy dostawcy DPAPI, który używa kluczy specyficznych dla komputera, należy uruchomić aspnet_regiis.exe
z tej samej maszyny, z której są obsługiwane strony internetowe. Jeśli na przykład uruchomisz ten program wiersza polecenia z lokalnej maszyny programistycznej, a następnie przekażesz zaszyfrowany plik Web.config do serwera produkcyjnego, serwer produkcyjny nie będzie mógł odszyfrować parametry połączenia informacji, ponieważ został zaszyfrowany przy użyciu kluczy specyficznych dla maszyny dewelopera. Dostawca RSA nie ma tego ograniczenia, ponieważ można wyeksportować klucze RSA do innej maszyny.
Opis opcji uwierzytelniania bazy danych
Zanim każda aplikacja będzie mogła wystawiać SELECT
zapytania do bazy danych microsoft SQL Server, INSERT
UPDATE
DELETE
baza danych musi najpierw zidentyfikować żądającego. Ten proces jest znany jako uwierzytelnianie i SQL Server zapewnia dwie metody uwierzytelniania:
- Uwierzytelnianie systemu Windows — proces, w którym działa aplikacja, służy do komunikowania się z bazą danych. W przypadku uruchamiania aplikacji ASP.NET za pośrednictwem 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
lubdomainName``\NETWORK SERVICE
, chociaż można to dostosować. - Uwierzytelnianie SQL — identyfikator użytkownika i wartości hasła są dostarczane jako poświadczenia do uwierzytelniania. W przypadku uwierzytelniania SQL identyfikator użytkownika i hasło są udostępniane w parametry połączenia.
Uwierzytelnianie systemu Windows jest preferowane w przypadku uwierzytelniania SQL, ponieważ jest bezpieczniejsze. W przypadku uwierzytelniania systemu Windows parametry połączenia jest wolny 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 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. Parametry połączenia dla Web.config
naszych samouczków:
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 parametrach połączenia używany jest termin Trusted Connection=Yes lub Integrated Security=SSPI zamiast Integrated Security=True, ale wszystkie trzy wskazują użycie uwierzytelniania systemu Windows.
W poniższym przykładzie przedstawiono parametry połączenia korzystającą z uwierzytelniania SQL. Zanotuj poświadczenia osadzone w parametry połączenia:
Server=serverName; Database=Northwind; uid=userID; pwd=password
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 dostępną za pośrednictwem Internetu, osoba atakująca może użyć tej parametry połączenia do nawiązania połączenia z bazą danych za pośrednictwem programu SQL Management Studio lub z ASP.NET stron w własnej witrynie internetowej. Aby pomóc w ograniczeniu tego zagrożenia, zaszyfruj informacje o parametry połączenia przy Web.config
użyciu chronionego systemu konfiguracji.
Uwaga
Aby uzyskać więcej informacji na temat różnych typów uwierzytelniania dostępnych w SQL Server, zobacz Tworzenie bezpiecznych aplikacji ASP.NET: uwierzytelnianie, autoryzacja i bezpieczna komunikacja. Aby uzyskać więcej parametry połączenia przykładach ilustrujących różnice między składnią uwierzytelniania systemu Windows i języka SQL, zapoznaj się z ConnectionStrings.com.
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żytkownika i hasła itd. System konfiguracji chronionej na platformie .NET 2.0 pomaga dodatkowo chronić poufne informacje, umożliwiając szyfrowanie określonych sekcji konfiguracji. Istnieją dwa wbudowane chronione dostawcy konfiguracji: jeden, który używa algorytmu RSA i jeden, który używa interfejsu API ochrony danych systemu Windows (DPAPI).
W tym samouczku przedstawiono sposób szyfrowania i odszyfrowywania 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 za pomocą 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
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 ciągu 24 godzin. Można do niego dotrzeć pod adresem mitchell@4GuysFromRolla.com. Lub za pośrednictwem swojego bloga, który można znaleźć na stronie http://ScottOnWriting.NET.
Specjalne podziękowania
Ta seria samouczków została sprawdzona przez wielu pomocnych recenzentów. Recenzenci z tego samouczka to Teresa Murphy i Randy Schmidt. Chcesz przejrzeć nadchodzące artykuły MSDN? Jeśli tak, upuść mi wiersz pod adresem mitchell@4GuysFromRolla.com.