Aspekty bezpieczeństwa aplikacji internetowych Kamil Witecki (kamil@witecki.net.pl) Wojciech Wodo (wojciech.wodo@gmail.com) 21 kwietnia 2010
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
Kto, co, dlaczego? Popularne typy ataków Popularne typy ataków Session hijacking Cross site scripting () Cross site request forgery
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ą
Czym jest sesja? Wprowadzenie Bezstanowość HTTP Metody przekazywania danych Przechowywanie stanu w aplikacjach bazujących na protokole HTTP
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?
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
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
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?
JavaScript i jego możliwości Skryptowanie przeglądarki Przekierowania Dostęp do danych Zmiana budowy i elementów witryny
- cross site scripting Osadzanie niepożądanych skryptów Persistent and nonpersistent Nie tylko JavaScript i nie tylko poprawny kod mogą być złośliwe
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
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
- cross site request forgery Mechanizm działania Różnice między, a Związane z zastosowaniem problemy Referer = ślad
- 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
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 ) ;
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 ) ;
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
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
Podziękowania Dziękujemy za uwagę i zapraszamy na kolejny wykład.