Aspekty bezpieczeństwa aplikacji internetowych

Transkrypt

1 Aspekty bezpieczeństwa aplikacji internetowych Kamil Witecki Wojciech Wodo 21 kwietnia 2010

2 Kto, co, dlaczego? Popularne typy ataków Kim jesteśmy i dlaczego to robimy Niski poziom świadomości społeczeństwa Niejasne terminy Częste problemy

3 Kto, co, dlaczego? Popularne typy ataków Popularne typy ataków Session hijacking Cross site scripting () Cross site request forgery

4 W trakcie warsztatu omówimy podstawowe ataki i skuteczne metody obrony, prezentowane również będą przykładowe aplikacje i skutki wywołane niewłaściwą implementacją

5 Czym jest sesja? Wprowadzenie Bezstanowość HTTP Metody przekazywania danych Przechowywanie stanu w aplikacjach bazujących na protokole HTTP

6 I w czym tkwi problem? Wprowadzenie Bob, czyli persona non grata Bob jako wyrocznia odróżnialna od Alicji Bob może dokładnie to co Alicja. Nie może tylko być w tym samym miejscu Jak możemy pomóc Alicji?

7 Niestety nie żyjemy w krainie czarów Bob może jednak stać w tym samym miejscu co Alicja Czy rozkładać bezradnie ręce? NIE! Użyjmy SSL/TLS! Cookies przesyłane bezpiecznym kanałem Narzuty związane z SSL/TLS Na bezpiecznym gruncie Pomysł - bezpieczna sesja bez (nadmiarowych) narzutów SSL/TLS

8 Skąd pochodzą dane? Wprowadzenie Nie mamy wpływu na dane, które otrzymujemy od użytkownika A gdy ustalamy pewne konwencje? W jakim stopniu możemy ufać? Walidacja po stronie klienta - dlaczego nie

9 Nie bierz cukierków od obcych! Do czego używamy danych od użytkownika Bob kontratakuje czyli osadzanie niepożądanych skryptów - podziel się wiedzą - czy to aby problem?

10 JavaScript i jego możliwości Skryptowanie przeglądarki Przekierowania Dostęp do danych Zmiana budowy i elementów witryny

11 - cross site scripting Osadzanie niepożądanych skryptów Persistent and nonpersistent Nie tylko JavaScript i nie tylko poprawny kod mogą być złośliwe

12 I co dalej? Wprowadzenie Jak dużo z języka HTML pozwalać używać klientom? Osadzony HTML może zaszkodzić równie mocno jak Używając CSS można "przykryć"dowolny element i nadać mu nowe znaczenie

13 Użyteczność, a bezpieczeństwo Najlepsze rozwiązanie - własne języki opisu (np. BBCode) Usuwanie wszystkich tagów, łącznie z tymi, które nie są poprawne Użycie Tidy przed parsowaniem niebezpiecznych danych

14 - cross site request forgery Mechanizm działania Różnice między, a Związane z zastosowaniem problemy Referer = ślad

15 - właściwie po co? Jak zmusić uzytkownika do wykonania ataku na samego siebie? XMLHttpRequest nie wystarczy - Cross-Domain Protection Policy Osadzanie wywołań w obrazkach itp. Ukrywanie śladów - wywołania z poziomu CSS i tagów nierenderowalnych

16 Wstrzyknąć SQL, ale jak i gdzie? Example Po raz kolejny - walidacja danych wejściowych <?php $ s q l = "SELECT FROM [ u s e r s ] WHERE [ l o g i n ] = ". $_POST[ l o g i n ]. " AND [ password ] =. md5($_post[ password ] ) ; mysql_query ( $ s q l ) ;

17 Wstrzyknąć, ale co i gdzie II? Example A co jeśli użytkownik wyśle login = login --? <?php $ s q l = "SELECT FROM [ u s e r s ] WHERE [ l o g i n ] = ". $_POST[ l o g i n ]. " AND [ password ] =. md5($_post[ password ] ) ; mysql_query ( $ s q l ) ;

18 Wizyta w hurtowni Wprowadzenie Jakie możliwości stwarza tego typu atak? Zależy to od rodzaju zapytania (SELECT, INSERT, UPDATE etc.) Zależy też od pozycji w zapytaniu (klauzula WHERE, klauzula ORDER BY) INFORMATION SCHEMA - skąd zdobyć dane o schemacie operacja UNION - jak dołączyć wyniki klauzula ORDER BY - jak przewidzieć liczbę kolumn

19 Wnioski Dane pochodzące od użytkownika wymagają szczególnej uwagi SSL i TLS pozwalają na bezpieczne zarządzanie sesją wymagając narzutu tylko wtedy, gdy rzeczywiście wykonujemy istotnie poufne operacje Samo sprawdzenie zgodności ze standardami nie wystarczy - należy wiedzieć, jak zachowają narzędzia w przypadku błędnych danych Dostarczane nam przez języki programowania narzędzia nie zawsze są wystarczające

20 Podziękowania Dziękujemy za uwagę i zapraszamy na kolejny wykład.