Asvs Webapp Release 2009 PL

wwwused everywhere
Wersja polska
Polish Version
ASVS 2009
Standard Aplikacji Web
Przedmowa
Niniejszy dokument opisuje cztery poziomy weryfikacji bezpieczestwa aplikacji Web. Bezpieczestwo na poziomie aplikacji skupia si na analizie komponentw skadajcych si na warstw aplikacji modelu OSI nie skupiajc si np. na systemie operacyjnym poniej lub podczonych sieciach. Kady z poziomw opisanych w niniejszym dokumencie zawiera szereg wymaga dotyczcych weryfikacji efektywnoci mechanizmw bezpieczestwa chronicych aplikacje Web. Wymagania te zostay stworzone z myl o nastpujcych celach: Uycie jako miara dostarczenie twrcom i wacicielom aplikacji miary do oceny stopnia zaufania do ich aplikacji Web, Uycie jako wytyczne dostarczenie twrcom mechanizmw bezpieczestwa wytycznych, w jaki sposb budowa mechanizmy bezpieczestwa, by speni wymagania bezpieczestwa aplikacji, 1 Uycie podczas pozyskiwania dostarczenie podstaw do okrelenia wymaga weryfikacji bezpieczestwa aplikacji w umowach. 2
Wymagania zostay opracowane by osign powysze cele poprzez zapewnienie kontroli, w jaki sposb mechanizmy bezpieczestwa s projektowane, wdraane i uywane przez aplikacj. Wymagania te zapewniaj, e uywane w aplikacji mechanizmy bezpieczestwa funkcjonuj zgodnie ze strategi domylnego zabronienia (deny-by-default), s scentralizowane, zlokalizowane po stronie serwera i uywane wszdzie tam, gdzie s potrzebne.
Prawa Autorskie I Licencja

Copyright 2008 2009 The OWASP Foundation. Niniejszy dokument jest wydany zgodnie z licencj Creative Commons Attribution ShareAlike 3.0.W przypadku ponownego uycia lub dystrybucji niniejszego dokumentu lub jego fragmentw musisz jasno poinformowa innych o warunkach licencji.
Wicej informacji o tworzeniu i uyciu mechanizmw bezpieczestwa speniajcych wymagania ASVS mona znale w Enterprise Security API (ESAPI) (OWASP, 2009). 2 Wicej informacji o uyciu ASVS w umowach mona znale w Contract Annex (OWASP, 2009).
Strona ii
ASVS 2009
Spis treci
Wstp ...................................................................................................................... 1 Podejcie .................................................................................................................. 1 Podzikowania ........................................................................................................... 4 Poziomy weryfikacji bezpieczestwa aplikacji ..................................................................... 5 Poziom 1 Weryfikacja automatyczna ......................................................................... 5 Poziom 1A Skanowanie dynamiczne (czciowa weryfikacja automatyczna) .......................... 7 Poziom 1B Skanowanie kodu rdowego (czciowa weryfikacja automatyczna) .................... 8 Poziom 2 Weryfikacja rczna ................................................................................... 8 Poziom 2A Test bezpieczestwa (czciowa weryfikacja rczna) ...................................... 11 Poziom 2B Przegld kodu (czciowa weryfikacja rczna) ............................................... 11 Poziom 3 Weryfikacja projektu ............................................................................... 11 Poziom 4 Weryfikacja wewntrzna ........................................................................... 15 Interpretacje wymaga i precedensy .......................................................................... 17 Szczegowe wymagania weryfikacyjne ............................................................................ 18 V1 Wymagania dotyczce dokumentacji architektury bezpieczestwa ................................ 19 V2 Wymagania weryfikacyjne dotyczce uwierzytelniania............................................... 21 V3 Wymagania weryfikacyjne dotyczce zarzdzania sesj ............................................. 22 V4 Wymagania weryfikacyjne dotyczce kontroli dostpu ............................................... 24 V5 Wymagania weryfikacyjne dotyczce walidacji wejcia .............................................. 26 V6 Wymagania weryfikacyjne dotyczce enkodowania/escapowania wyjcia ........................ 27 V7 Wymagania weryfikacyjne dotyczce kryptografii ..................................................... 28 V8 Wymagania weryfikacyjne dotyczce obsugi bdw i logowania .................................. 30 V9 Wymagania weryfikacyjne dotyczce ochrony danych ................................................ 32 V10 Wymagania weryfikacyjne dotyczce bezpieczestwa komunikacji .............................. 33 V11 Wymagania weryfikacyjne dotyczce bezpieczestwa HTTP....................................... 34 V12 Wymagania weryfikacyjne dotyczce konfiguracji zabezpiecze ................................. 35 V13 Wymagania weryfikacyjne dotyczce wyszukiwania zoliwego kodu ............................ 36 V14 Wymagania weryfikacyjne dotyczce bezpieczestwa wewntrznego ........................... 37 Wymagania dotyczce raportowania weryfikacji ................................................................. 38 R1 Wstp do raportu ............................................................................................ 38 R2 Opis apiikacji ................................................................................................. 38 R3 Architektura bezpieczestwa aplikacji .................................................................. 38 R4 Wyniki weryfikacji ........................................................................................... 39 Sowniczek ............................................................................................................... 40 Gdzie jeszcze moesz si uda? ...................................................................................... 42
Strona iii
ASVS 2009
Rysunki
Rysunek Rysunek Rysunek Rysunek Rysunek Rysunek Rysunek Rysunek Rysunek Rysunek Rysunek 1 Poziomy OWASP ASVS ................................................................................. 2 2 Jeden ze sposobw wprowadzenia weryfikacji, jako czynnoci w Twoim SDLC ............ 3 3 Poziomy 1, 1A i 1B OWASP ASVS .................................................................... 6 4 Przykad architektury bezpieczestwa dla poziomu 1 OWASP ASVS .......................... 7 5 Poziomy 2, 2A i 2B OWASP ASVS .................................................................... 9 6 Przykad architektury bezpieczestwa dla poziomu 2 OWASP ASVS .........................11 7 Poziom 3 OWASP ASVS ...............................................................................13 8 Przykad architektury bezpieczestwa dla poziomu 3 OWASP ASVS .........................14 9 Poziom 4 OWASP ASVS ...............................................................................15 10 Przykad niezbadanego kodu na poziomie 4 OWASP ASVS ....................................17 11 Zawarto raportu ..................................................................................38
Tabele
Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela 1 Wymagania dotyczce dokumentacji architektury bezpieczestwa w OWASP ASVS (V1) ..19 2 Wymagania dotyczce uwierzytelniania w OWASP ASVS (V2)...................................21 3 Wymagania dotyczce zarzdzania sesj w OWASP ASVS (V3) .................................22 4 Wymagania dotyczce kontroli dostpu w OWASP ASVS (V4) ...................................25 5 Wymagania dotyczce walidacji wejcia w OWASP ASVS (V5) ..................................26 6 Wymagania dotyczce enkodowania/escapowania wyjcia w OWASP ASVS (V6) ............27 7 Wymagania dotyczce kryptografii w OWASP ASVS (V7).........................................29 8 Wymagania dotyczce obsugi bdw i logowania w OWASP ASVS (V8) ......................30 9 Wymagania dotyczce ochrony danych w OWASP ASVS (V9) ....................................32 10 Wymagania dotyczce bezpieczestwa komunikacji w OWASP ASVS (V10) .................33 11 Wymagania dotyczce bezpieczestwa HTTP w OWASP ASVS (V11) .........................34 12 Wymagania dotyczce konfiguracji zabezpiecze w OWASP ASVS (V12) ....................35 13 Wymagania dotyczce wyszukiwania zoliwego kodu w OWASP ASVS (V13) ...............36 14 Wymagania dotyczce bezpieczestwa wewntrznego w OWASP ASVS (V14) ..............37 15 Zawarto wynikw weryfikacji w raporcie OWASP ASVS ......................................39
Strona iv
ASVS 2009
Wstp
Open Web Application Security Project (OWASP) jest otwart spoecznoci, ktrej celem jest umoliwienie organizacjom tworzenia, nabywania oraz utrzymywania aplikacji, ktrym mona zaufa. Wszystkie narzdzia, dokumenty, fora i lokalne oddziay OWASP s dostpne za darmo i otwarte dla wszystkich zainteresowanych popraw bezpieczestwa aplikacji. Zalecamy podejcie do bezpieczestwa aplikacji, jako problemu obejmujcego ludzi, procesy i technologi, poniewa najbardziej efektywne podejcia do bezpieczestwa aplikacji zawieraj usprawnienia we wszystkich tych obszarach. Moesz nas znale na www.owasp.org OWASP jest nowym rodzajem organizacji. Nasza niezaleno od naciskw komercyjnych pozwala nam dostarcza pozbawione tendencyjnoci, praktyczne i efektywne kosztowo informacje na temat bezpieczestwa aplikacji. OWASP nie jest powizany z adn firm technologiczn, wspiera jednak wiadome uycie komercyjnych rozwiza bezpieczestwa. Podobnie do innych projektw opensource OWASP tworzy wiele materiaw rnego typu w drodze otwartej wsppracy. OWASP Foundation jest jednostk typu non-profit, co zapewnia dugoterminowy sukces projektu. Gwnym celem projektu OWASP Application Security Verification Standard (ASVS) jest normalizacja zasigu weryfikacji bezpieczestwa aplikacji Web w odniesieniu do pokrycia i rygorystycznoci moliwej do osignicia w warunkach rynkowych poprzez stworzenie otwartego standardu przystosowanego do zastosowa komercyjnych. Niniejszy standard dostarcza podstaw do testowania technicznych mechanizmw bezpieczestwa aplikacji, jak rwnie innych technicznych mechanizmw bezpieczestwa rodowiska, od ktrych zaley ochrona przed podatnociami takimi jak Cross-Site Scripting (XSS) i SQL injection. 3 Standard moe by uywany w celu uzyskania poziomu pewnoci, co do bezpieczestwa aplikacji Web.
Podejcie
OWASP ASVS okrela wymagania wzgldem weryfikacji i dokumentowania pogrupowane na podstawie pokrycia i rygorystycznoci weryfikacji. Standard definiuje cztery poziomy uoone w hierarchii (np. poziom 2 wymaga wikszego pokrycia i rygorystycznoci ni poziom 1) jak pokazano na diagramie poniej.
Wicej informacji na temat czstych podatnoci w aplikacjach Web mona znale w OWASP Top Ten (OWASP, 2007). Dostpna jest ju nowa wersja OWASP Top Ten 2010 [przyp. tumacza]
Strona 1
ASVS 2009
Rysunek 1 Poziomy OWASP ASVS Weryfikacja bezpieczestwa aplikacji Web z logicznego punktu widzenia jest wykonywana poprzez podanie (lub prb podania) ciekami wej i wyj z danej aplikacji (nazywanej celem weryfikacji lub TOV (skrt od Target of Verification)) i przeprowadzanie analizy zgodnie z tymi ciekami. Aplikacje o wikszym stopniu zoonoci zwykle wymagaj wikszej iloci czasu na analiz, co sprawia, e weryfikacja jest dusza i bardziej kosztowna. Liczba linii kodu nie jest jedynym czynnikiem okrelajcym zoono aplikacji rne technologie zwykle wymagaj rnej wielkoci analiz. Proste aplikacje mog na przykad zawiera biblioteki i frameworki. Aplikacje o rednim stopniu zoonoci mog zawiera proste aplikacje Web 1.0. Aplikacje zoone mog zawiera aplikacje Web 2.0 i nowe/unikalne technologie Web. ASVS definiuje skadowe komponenty dla poziomw 1 i 2 (np. weryfikacja na poziomie 1 wymaga spenienia wymaga poziomw 1A i 1B). Dla przykadu, aplikacje mog wymaga zgodnoci do poziomu 1A lub 1B zamiast poziomu 1, ale poprzez to stawiane wymagania s mniejsze od wymaga poziomu 1. Wymagania wzgldem weryfikacji i dokumentowania zdefiniowane w tym standardzie dziel si na trzy typy wymaga: wymagania wysoko-poziomowe, wymagania szczegowe i wymagania raportowe. Wymagania wysoko-poziomowe okrelaj caociowe wymagania wzgldem implementacji i weryfikacji aplikacji. Wymagania szczegowe okrelaj niskopoziomowe wymagania wzgldem implementacji i weryfikacji aplikacji (tj. konkretne elementy, ktre naley zweryfikowa). Wymagania raportowe okrelaj sposb dokumentacji wynikw weryfikacji aplikacji przeprowadzonej zgodnie z OWASP ASVS. OWASP dostarcza wiele materiaw, wczajc w to ASVS, by pomc organizacjom tworzy i utrzymywa bezpieczne aplikacje. OWASP ASVS, OWASP Contract Annex4 oraz OWASP ESAPI5 mog by uywane do wsparcia cyklu ycia rozwoju oprogramowania SDLC (skrt od Software Development Life Cycle) w sposb przedstawiony na rysunku poniej.
Wicej informacji na temat wyboru poziomu ASVS przy tworzeniu umw mona znale w OWASP Contract Annex. 5 Wicej informacji na temat jak wdroy ESAPI w Twojej aplikacji mona znale w projekcie OWASP ESAPI (OWASP 2009).
Strona 2
ASVS 2009
Rysunek 2 Jeden ze sposobw wprowadzenia weryfikacji, jako czynnoci w Twoim SDLC6
Wicej informacji na temat wprowadzania czynnoci zwizanych z bezpieczestwem do Twojego istniejcego SDLC mona znale w projektach OWASP CLASP (OWASP 2008) lub OWASP SAMM (OWASP 2009).
Strona 3
ASVS 2009
Podzikowania
Dzikujemy OWASP Foundation za sponsorowanie projektu OWASP ASVS w ramach OWASP Summer of Code 2008. Lider projektu: 7 Mike Boberski (Booz Allen Hamilton) Autorzy: 8 Mike Boberski (Booz Allen Hamilton), Jeff Williams (Aspect Security), Dave Wichers (Aspect Security)
Sponsorzy projektu:
Tumaczenie: Tomasz Polaski (jmsblond@gmail.com) Przegld i korekta: dr in. Mariusz Stawowski
Dzikujemy rwnie za wkad:Pierre Parrend, ktry by recenzentem OWASP Summer of Code 2008; Andrew van der Stock (Aspect Security); Nam Nguyen (Blue Moon Consulting); John Martin (Boeing); Gaurang Shah (Booz Allen Hamilton); Theodore Winograd (Booz Allen Hamilton); Stan Wisseman (Booz Allen Hamilton); Barry Boyd (CGI Federal); Steve Coyle (CGI Federal); Paul Douthit (CGI Federal); Ken Huang (CGI Federal); Dave Hausladen (CGI Federal); Mandeep Khera (Cenzic); Scott Matsumoto (Cigital); John Steven (Cigital); Stephen de Vries (Corsaire); Dan Cornell (Denim Group); Shouvik Bardhan (Electrosoft), Dr. Sarbari Gupta (Electrosoft); Eoin Keary (Ernst & Young); Richard Campbell (Federal Deposit Insurance Corporation); Matt Presson (FedEx); Jeff LoSapio (Fortify Software); Liz Fong (National Institute of Standards and Technology); George Lawless (Noblis); Dave van Stein (ps_testware); Terrie Diaz (SAIC); Ketan Dilipkumar Vyas (Tata Consultancy Services); Bedirhan Urgun (TURKCELL); Dr. Thomas Braun (United Nations); Colin Watson (Watson Hall); Jeremiah Grossman (WhiteHat Security); oraz na koniec skadamy podzikowania spoecznoci zwizanej z weryfikacj bezpieczestwa aplikacji i innym zainteresowanym zaufanym przetwarzaniem Web (trusted Web computing) za ich entuzjastyczne porady i wsparcie w trakcie realizacji tego projektu.
7 8
Email: mike.boberski@owasp.org Email: jeff.williams@owasp.org, dave.wichers@owasp.org
Strona 4
ASVS 2009
Poziomy weryfikacji acji bezpieczestwa a aplikacji

ASVS definiuje cztery poziomy weryfikacji, gdzie przechodzc na wysze poziomy ronie szeroko i gboko weryfikacji. Szeroko dla kadego poziomu jest definiowana przez zestaw wymaga bezpieczestwa, ktre musz by spenione. spen Gboko weryfikacji jest zdefiniowana przez podejcie oraz wymagan rygorystyczno weryfikacji kadego z wymaga bezpieczestwa. Narzdzia s istotn czci ka kadego poziomu ASVS. Na wyszych poziomach ASVS zalecane jest uywanie narzdzi, jednak aby byo to efektywne narzdzia te musz by w odpowiedni sposb dopasowane i skonfigurowane dla danej aplikacji i uywanego frameworka. Na kadym poziomie wyniki uzyskane przy pomocy narzdzi musz by zweryfikowane rcznie. Weryfikujcy jest odpowiedzialny odpowiedzia za stwierdzenie czy TOV spenia wszystkie wymagania na wskazanym poziomie przegldu. przegldu Aplikacja speniajca wszystkie wymagania danego poziomu jest aplikacj ASVS poziomu N, , gdzie N jest poziomem, z ktrym dana aplikacja jest zgodna. Jeli aplikacja nie spenia wszystkich wymaga dla danego poziomu, lecz spenia wszystkie wymagania dla poziomu niszego uznaje si, e przesza weryfikacj na poziomie niszym. W standardzie uywany jest termin weryfikujcy oznaczajcy osob lub zesp dokonujcy dokon przegldu u aplikacji pod ktem kt niniejszych wymaga. Specyfikacja aplikacji moe wymaga zgodnoci z OWASP ASVS na poziomie N, jednak moe take zawiera dodatkowe szczegowe wymagania z wyszych poziomw ASVS. Na przykad firma z sektora finansowego moe dla aplikacji ikacji niskiego ryzyka wymaga weryfikacji na poziomie 2 OWASP ASVS oraz dodatkowo weryfikacji pod ktem zoliwego kodu (patrz V13, wycznie dla poziomu 4). Mog mie rwnie zastosowanie inne wymagania organizacyjne lub biznesowe takie jak zgodno z okrelonymi relonymi politykami bezpieczestwa lub regulacjami.
Nie istnieje poziom 0 weryfikacji. Do przyznania konkretnego poziomu konieczne jest usunicie (lub minimalizacja) inimalizacja) podatnoci i ponowna weryfikacja aplikacji.
Poziom 1 Weryfikacja automatyczna a

Poziom 1 (Weryfikacja automatyczna) jest zwykle odpowiedni dla aplikacji, dla ktrych wymagany jest pewien poziom zaufania, co do poprawnego uycia mechanizmw bezpieczestwa. eczestwa. Typowymi zagroeniami ami dla bezpieczestwa9 bd w tym przypadku wirusy i robaki (cele s wybierane przypadkowo w trakcie skanowania o szerokim zakresie, a atakowane s te najbardziej podatne). Zakres weryfikacji kacji obejmuje kod stworzony lub zmodyfikowany kowany przy tworzeniu aplikacji. Na poziomie 1 weryfikacja jest est przeprowadzana z uyciem automatycznych narzdzi i rozszerzona o rczn weryfikacj. Ten poziom weryfikacji obejmuje tylko czciowe pokrycie bezpieczestwa aplikacji. Wykonywana na tym poziom poziomie weryfikacja eryfikacja rczna nie ma na celu zapewnienia kompletnej kompletn weryfikacji i bezpieczestwa aplikacji, tylko upewnienie si, e wyniki uzyskane w sposb automatyczny s poprawne i nie stanowi faszywych wskaza. Wystpuj dwa elementy skadowe poziomu 1. Poziom 1A gdzie wykorzystuje si narzdzia automatycznego skanowania podatnoci aplikacji (analiza (analiz dynamiczna) ) oraz poziom 1B, 1B na ktrym wykorzystuje si narzdzia automatycznego automatyczne skanowania kodu rdowego (analiza (analiz statyczna). Weryfikacja moe wykorzystywa poszczeglne elementy skadowe oddzielnie lub ich kombinacj w celu osignicia penego poziomu 1. Struktura tych poziomw jest przedstawiona na rysunku poniej.
Wicej informacji na temat identyfikacji i szacowania ryzyka zwizanego z podatnociami mona znale w OWASP Testing Guide (OWASP, 2008).
Strona 5
ASVS 2009
Moliwe jest stwierdzenie czy aplikacja spenia wymagania poziomu 1A lub 1B, jednak aden z tych poziomw osobno nie zapewnia takiego poziomu rygorystycznoci oceny ani pokrycia, jak aplikacja, ktra spenia wymagania poziomu 1. Aplikacja poziomu 1 musi spenia wymagania poziomu 1A i1B.
Rysunek 3 Poziomy 1, 1A i 1B OWASP ASVS
Wystpuj nastpujce minimalne wysoko-poziomowe wymagania dla aplikacji poziomw 1, 1A lub 1B: Zakres weryfikacji L1.1 Zakres weryfikacji obejmuje cao kodu napisanego lub zmodyfikowanego w celu stworzenia aplikacji.
Wymagania dotyczce zachowania mechanizmw bezpieczestwa Brak Na poziomie 1 nie ma wymaga dotyczcych sposobu podejmowania decyzji przez mechanizmy bezpieczestwa aplikacji.
Wymagania dotyczce uycia mechanizmw bezpieczestwa Brak Na poziomie 1 nie ma wymaga okrelajcych gdzie w aplikacji musz by uywane mechanizmy bezpieczestwa.
Wymagania dotyczce implementacji mechanizmw bezpieczestwa Brak Na poziomie 1 nie ma wymaga mwicych o sposobie budowy mechanizmw bezpieczestwa aplikacji.
Wymagania dotyczce weryfikacji mechanizmw bezpieczestwa L1.2 L1.3 Wykonaj dynamiczne skanowanie aplikacji zgodnie z wymaganiami dla poziomu 1A opisanymi w sekcji Dokadne wymagania weryfikacyjne. Wykonaj skanowanie kodu rdowego aplikacji zgodnie z wymaganiami dla poziomu 1B opisanymi w sekcji Dokadne wymagania weryfikacyjne.
Wymagania na poziomie 1 pozwalajce na uycie dowolnej techniki weryfikacji musz by zweryfikowane przy uyciu tylko jednej z technik. Dodatkowo, jeli zestaw narzdzi wybrany przez
Strona 6
ASVS 2009
weryfikujcego nie posiada moliwoci sprawdzenia danego wymagania, weryfikujcy moe wypeni t luk przez wykonanie weryfikacji rcznej.10 11 Wymagania raportowe L1.4 Stwrz raport z weryfikacji opisujcy architektur bezpieczestwa aplikacji poprzez wymienienie jej komponentw, zawierajcy wyniki weryfikacji zgodnie z wymaganiami opisanymi w sekcji Wymagania raportowe z weryfikacji.
Na poziomie 1 komponenty aplikacji mog by okrelone jako pojedyncze lub grupy plikw rdowych, bibliotek i/lub plikw wykonywalnych, jak pokazano to na rysunku poniej. Na poziomie 1 ta lista nie musi by posortowana ani zorganizowana w inny sposb, jak przez okrelenie, ktre komponenty s czci aplikacji, a ktre s czci rodowiska IT. Aplikacja moe by wic traktowana jako grupy komponentw wewntrz pojedynczego monolitycznego obiektu. Nie jest konieczna identyfikacja i dokumentacja cieek, jakimi w aplikacji moe przechodzi dane zapytanie uytkownika kocowego.
Rysunek 4 Przykad architektury bezpieczestwa dla poziomu 1 OWASP ASVS
10 Wicej informacji na temat przeprowadzania weryfikacji rcznej mona znale w OWASP Testing Guide (OWASP, 2008). 11 Wicej informacji na temat przeprowadzania weryfikacji rcznej poprzez rczny przegld kodu mona znale w OWASP Code Review Guide (OWASP, 2008).
Strona 7
ASVS 2009
Poziom 1A automatyczna)
Skanowanie
dynamiczne
(czciowa
weryfikacja
Wymagania dla weryfikacji mechanizmw bezpieczestwa przy pomocy skanowania dynamicznego Skanowanie dynamiczne (znane rwnie jako skanowanie podatnoci aplikacji) polega na uyciu automatycznych narzdzi uzyskujcych dostp do interfejsw aplikacji podczas jej pracy w celu wykrycia podatnoci w mechanizmach bezpieczestwa aplikacji. Naley zauway, e nie jest to wystarczajce do weryfikacji poprawnoci projektu, implementacji i zastosowania mechanizmw bezpieczestwa, jednak takie sprawdzenie jest akceptowalne dla poziomu 1. Zakres weryfikacji jest okrelony przez wymagania dotyczce architektury bezpieczestwa dla tego poziomu. L1A.1 L1A.2 Wykonaj dynamiczne skanowanie aplikacji zgodnie z wymaganiami dla poziomu 1A opisanymi w sekcji Dokadne wymagania weryfikacyjne Zweryfikuj wszystkie wyniki skanowania dynamicznego poprzez manualne testy penetracyjne aplikacji lub przegld kodu. Niezweryfikowane wyniki skanowania automatycznego nie daj adnej pewnoci i nie s wystarczajce do osignicia poziomu 1.
Wiele wystpie danego typu podatnoci, ktre mog by sprowadzone do jednej gwnej przyczyny ich wystpowania powinno by zgrupowane w pojedynczy wynik, jeli narzdzie skanujce ju tego nie zrobio.
Poziom 1B Skanowanie kodu rdowego (czciowa weryfikacja automatyczna)

Wymagania dla weryfikacji mechanizmw bezpieczestwa przy pomocy skanowania kodu rdowego Skanowanie kodu rdowego (znane rwnie jako analiza statyczna) polega na uyciu automatycznych narzdzi do wyszukiwania w kodzie rdowym aplikacji wzorcw wskazujcych na podatnoci. Naley zauway, e nie jest to wystarczajce do weryfikacji poprawnoci projektu, implementacji i zastosowania mechanizmw bezpieczestwa, jednak takie sprawdzenie jest akceptowalne dla poziomu 1. Zakres weryfikacji jest okrelony przez wymagania dotyczce architektury bezpieczestwa dla tego poziomu. L1B.1 L1B.2 Wykonaj skanowanie kodu rdowego aplikacji zgodnie z wymaganiami dla poziomu 1B opisanymi w sekcji Dokadne wymagania weryfikacyjne. Zweryfikuj wszystkie wyniki skanowania kodu rdowego poprzez manualne testy penetracyjne aplikacji lub przegld kodu. Niezweryfikowane wyniki skanowania automatycznego nie daj adnej pewnoci i nie s wystarczajce do osignicia poziomu 1.
Wiele wystpie danego typu podatnoci, ktre mog by sprowadzone do jednej gwnej przyczyny ich wystpowania powinno by zgrupowane w pojedynczy wynik, jeli narzdzie do analizy kodu ju tego nie zrobio.
Poziom 2 Weryfikacja rczna

Poziom 2 (Weryfikacja rczna) jest zwykle odpowiedni dla aplikacji, ktre obsuguj transakcje ludzi, wykonuj transakcje biznesowe midzy firmami, przetwarzaj dane kartowe lub dane osobowe. Poziom 2 daje pewien poziom zaufania, co do prawidowego uycia mechanizmw bezpieczestwa i ich prawidowego dziaania. Typowymi zagroeniami dla bezpieczestwa bd w
Strona 8
ASVS 2009
tym przypadku wirusy, robaki i mao wymylni, liczcy na okazj napastnicy, uywajcy profesjonalnych narzdzi ataku lub narzdzi open-source. Zakres weryfikacji obejmuje cao kodu napisanego lub zmodyfikowanego w celu stworzenia aplikacji oraz ocen bezpieczestwa wszystkich komponentw firm trzecich, dostarczajcych funkcjonalnoci bezpieczestwa dla aplikacji. Wystpuj dwa skadowe komponenty poziomu 2, jak przedstawiono na rysunku poniej.
Rysunek 5 Poziomy 2, 2A i 2B OWASP ASVS Moliwe jest stwierdzenie czy aplikacja spenia wymagania poziomu 2A lub 2B, jednak aden z tych poziomw osobno nie zapewnia takiego poziomu rygorystycznoci oceny ani pokrycia jak poziom 2. Poniewa poziom 2 zawiera wymagania poziomu 1, do spenienia wymaga poziomu 2 nie jest wymagane uruchamianie narzdzi automatycznych. Zamiast tego weryfikujcy posiada wybr uycia wycznie technik rcznych dla wszystkich wymaga. Jeli s dostpne wyniki narzdzi automatycznych mog by uyte przez weryfikujcego do wsparcia analizy. Jednake nawet spenienie danego wymagania na poziomie 1 nie oznacza automatycznie spenienia tego samego wymagania na poziomie 2. Jest tak, poniewa narzdzia automatyczne nie dostarczaj wystarczajcego dowodu na spenienie wymaga pozytywnych. Techniki rczne wci zakadaj uycie narzdzi. Mog to by dowolnego rodzaju narzdzia do analizy lub testw bezpieczestwa, wczajc w to narzdzia automatyczne uywane do weryfikacji w ramach poziomu 1. Jednake takie narzdzia s jedynie pomoc dla analityka w wyszukiwaniu i ocenie poddawanych weryfikacji mechanizmw bezpieczestwa. Takie narzdzia mog zawiera (lub nie) logik pozwalajc na automatyczne wykrywanie podatnoci w aplikacji. Wystpuj nastpujce minimalne wysoko-poziomowe wymagania dla aplikacji poziomu 2, 2A lub 2B: Zakres weryfikacji L2.1 L2.2 Zakres weryfikacji obejmuje cao kodu napisanego lub zmodyfikowanego w celu stworzenia aplikacji. To wymaganie zostao wprowadzone na poziomie 1. Zakres weryfikacji obejmuje kod wszystkich pochodzcych z firm trzecich Framework-w, bibliotek i funkcjonalnoci bezpieczestwa usug, realizujcych lub wspomagajcych bezpieczestwo aplikacji. Jest to nowe wymaganie na poziomie 2.
Wymagania dotyczce zachowania mechanizmw bezpieczestwa L2.3 Zweryfikuj czy wszystkie techniczne mechanizmy bezpieczestwa dokonujce kontroli bezpieczestwa podejmuj decyzj w oparciu o list dozwolonych wynikw (whitelist). Jest to nowe wymaganie na poziomie 2. Zweryfikuj czy wszystkie mechanizmy bezpieczestwa dokonujce kontroli bezpieczestwa oraz mechanizmy bezpieczestwa, ktrych dziaanie ma wpyw na bezpieczestwo nie mog by ominite zgodnie z wymaganiami dla poziomw 2A i 2B opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to nowe wymaganie na poziomie 2.
L2.4
Strona 9
ASVS 2009
Wymagania dotyczce uycia mechanizmw bezpieczestwa L2.5 Zweryfikuj czy wszystkie mechanizmy bezpieczestwa s uywane w aplikacji wszdzie tam, gdzie s potrzebne, ich implementacje s scentralizowane i umieszczone po stronie serwera zgodnie z wymaganiami dla poziomu 2 opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to nowe wymaganie na poziomie 2.
Wymagania dotyczce implementacji mechanizmw bezpieczestwa Brak Na poziomie 2 nie ma wymaga okrelajcych, w jaki sposb maj by zbudowane mechanizmy bezpieczestwa aplikacji.
Wymagania dotyczce weryfikacji mechanizmw bezpieczestwa L2.6 Wykonaj rczny test penetracyjny aplikacji zgodnie z wymaganiami dla poziomu 2A opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to nowe wymaganie na poziomie 2. Wykonaj rczny przegld kodu rdowego aplikacji zgodnie z wymaganiami dla poziomu 2B opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to nowe wymaganie na poziomie 2.
L2.7
Wymagania na poziomie 2 pozwalajce na uycie dowolnej techniki weryfikacji musz by zweryfikowane przy uyciu tylko jednej z technik. Weryfikujcy moe wykorzysta w swoich pracach automatyczne skanowanie lub analiz kodu, jednak automatyczna weryfikacja nie moe zastpi przegldu rcznego wymaganego dla kadego wymagania na poziomie 2. Jeli wyniki skanowania pomagaj weryfikujcemu wykonywa prac szybciej lub rozszerzaj wyniki przegldu rcznego to oczywicie mog by uyte do wspomagania weryfikacji na poziomie 2. Wymagania Raportowe L2.8 Stwrz raport z weryfikacji opisujcy architektur bezpieczestwa aplikacji poprzez pogrupowanie jej komponentw w wysoko-poziomow architektur oraz zawierajcy wyniki weryfikacji zgodnie z wymaganiami wymienionymi w sekcji Wymagania raportowe z weryfikacji. Jest to rozszerzenie wymaga raportowych wprowadzonych na poziomie 1.
Na poziomie 2 komponenty aplikacji mog by okrelone jako pojedyncze lub grupy plikw rdowych, bibliotek i/lub plikw wykonywalnych, zorganizowane w wysoko-poziomow architektur (np. komponenty Model-Widok-Kontroler (Model-View-Controller, MVC), komponenty funkcji biznesowych, komponenty warstwy danych). Na przykad diagram poniej przedstawia aplikacj skadajc si z aplikacji serwera, aplikacji serwera aplikacyjnego, wasnego kodu, bibliotek i aplikacji bazy danych zgrupowanych zgodnie z architektur MVC. Na poziomie 2 cieka lub cieki, jakimi w aplikacji moe przechodzi dane zapytanie uytkownika kocowego musz by udokumentowane, jak przedstawiono to na rysunku poniej. Jednake, nie wszystkie cieki musz by przeanalizowane.
Strona 10
ASVS 2009
Aplikacja Web bdca celem weryfikacji
Kontroler Funkcje biznesowe Warstwa prezentacji Warstwa danych
wywoania Frameworki Biblioteki Serwer aplikacyjny Serwer WWW Baza Danych
Uytkownik
Aplikacja Web
Backend
Rysunek 6 Przykad architektury bezpieczestwa dla poziomu 2 OWASP ASVS
Strona 11
ASVS 2009
Poziom 2A Test bezpieczestwa (czciowa weryfikacja rczna)

Wymagania dotyczce weryfikacji mechanizmw bezpieczestwa przy pomocy rcznych testw penetracyjnych aplikacji Rczne testy bezpieczestwa aplikacji skadaj si z tworzonych dynamicznie testw w celu weryfikacji poprawnoci projektu, implementacji i uycia mechanizmw bezpieczestwa. Zakres weryfikacji jest zdefiniowany przez wymagania dotyczce architektury bezpieczestwa dla tego poziomu. L2A.1 Wykonaj rczne testowanie bezpieczestwa aplikacji zgodnie z wymaganiami dla poziomu 2A opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to nowe wymaganie na poziomie 2.
W miejscach, gdzie jest to uzasadnione, weryfikujcy moe uy prbkowania do ustalenia, w jaki sposb uywany jest okrelony mechanizm bezpieczestwa. Weryfikujcy moe postanowi udokumentowa wzorzec podatnoci, ktry pozwoli developerom na sprawne znalezienie i poprawienie wszystkich wystpie tego wzorca w wersji bazowej oprogramowania. Wiele wystpie wzorca podatnoci, ktre mog by sprowadzone do jednej gwnej przyczyny ich wystpowania powinno by zgrupowane w pojedynczy wynik.
Poziom 2B Przegld kodu (czciowa weryfikacja rczna)

Wymagania dotyczce weryfikacji mechanizmw bezpieczestwa przy pomocy rcznego przegldu kodu Rczny przegld kodu polega na wyszukiwaniu i analizie (wykonywanych przez czowieka) kodu rdowego aplikacji w celu weryfikacji projektu, implementacji i waciwego uycia mechanizmw bezpieczestwa. Oczekuje si, e analiza tego typu jest wspomagana narzdziami, jednak moe po prostu wykorzystywa powszechnie dostpne narzdzia, takie jak edytor kodu rdowego lub IDE. Zakres weryfikacji jest okrelony przez wymagania dotyczce architektury bezpieczestwa dla tego poziomu. L2B.1 Rczny przegld kodu aplikacji zgodnie z wymaganiami dla poziomu 2B opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to nowe wymaganie na poziomie 2.
W miejscach gdzie jest to uzasadnione weryfikujcy moe uy waciwego prbkowania do ustalenia, w jaki sposb uywany jest okrelony mechanizm bezpieczestwa. Weryfikujcy moe postanowi udokumentowa wzorzec podatnoci, ktry pozwoli developerom na sprawne znalezienie i poprawienie wszystkich wystpie tego wzorca w wersji bazowej oprogramowania. Wiele wystpie wzorca podatnoci, ktre mog by sprowadzone do jednej gwnej przyczyny ich wystpowania powinno by zgrupowane w pojedynczy wynik
Poziom 3 Weryfikacja projektu

Poziom 3 (Weryfikacja projektu) jest zwykle odpowiedni dla aplikacji obsugujcych wane transakcje biznesowe pomidzy organizacjami, wczajc to aplikacje przetwarzajce dane o stanie zdrowia, aplikacje speniajce krytyczne dla biznesu lub wraliwe funkcje lub przetwarzajce inne wraliwe aktywa. Typowymi zagroeniami dla bezpieczestwa bd w tym przypadku wirusy, robaki, napastnicy liczcy na okazj oraz zdeterminowani napastnicy (wykwalifikowani i zmotywowani, skupieni na okrelonych celach, uywajcy m.in. specjalnie przystosowanych narzdzi skanujcych). Zakres weryfikacji obejmuje cao kodu napisanego lub zmodyfikowanego w celu stworzenia aplikacji, a take ocen bezpieczestwa komponentw firm trzecich, dostarczajcych funkcjonalnoci bezpieczestwa dla aplikacji. Poziom 3 zapewnia, e mechanizmy bezpieczestwa funkcjonuj w sposb prawidowy i s uyte w aplikacji wszdzie tam, gdzie powinny by uyte by
Strona 12
ASVS 2009
egzekwowa polityki specyficzne dla aplikacji. Poziom 3 nie jest podzielony na wiele czci, jak to przedstawiono na rysunku poniej.
Rysunek 7 Poziom 3 OWASP ASVS Wystpuj nastpujce minimalne wysoko-poziomowe wymagania dla aplikacji poziomu 3: Zakres Weryfikacji L3.1 L3.2 Zakres weryfikacji obejmuje cao kodu napisanego lub zmodyfikowanego w celu stworzenia aplikacji. To wymaganie zostao wprowadzone na poziomie 1. Zakres weryfikacji obejmuje kod wszystkich pochodzcych z firm trzecich framework-w, bibliotek i funkcjonalnoci bezpieczestwa usug, realizujcych lub wspomagajcych bezpieczestwo aplikacji. To wymaganie zostao wprowadzone na poziomie 2. Zakres weryfikacji obejmuje kod wszystkich pochodzcych z firm trzecich framework-w , bibliotek i usug zwizanych z aplikacj. Jest to nowe wymaganie na poziomie 3.
L3.3
Wymagania dotyczce zachowania mechanizmw bezpieczestwa L3.4 Zweryfikuj czy wszystkie techniczne mechanizmy bezpieczestwa dokonujce kontroli bezpieczestwa podejmuj decyzj w oparciu o list dozwolonych wynikw (whitelist). To wymaganie zostao wprowadzone na poziomie 2. Zweryfikuj czy wszystkie mechanizmy bezpieczestwa dokonujce kontroli bezpieczestwa oraz mechanizmy bezpieczestwa, ktrych dziaanie ma wpyw na bezpieczestwo nie mog by ominite zgodnie z wymaganiami dla poziomu 3 opisanymi w sekcji Dokadne wymagania weryfikacyjne. To wymaganie zostao wprowadzone na poziomie 2.
L3.5
Wymagania dotyczce uycia mechanizmw bezpieczestwa L3.6 Zweryfikuj czy wszystkie mechanizmy bezpieczestwa s uywane w aplikacji wszdzie tam, gdzie s potrzebne, ich implementacje s scentralizowane i umieszczone po stronie serwera, zgodnie z wymaganiami dla poziomu 3 opisanymi w sekcji Dokadne wymagania weryfikacyjne. To wymaganie zostao wprowadzone na poziomie 2.
Wymagania dotyczce implementacji mechanizmw bezpieczestwa Brak Na poziomie 3 nie ma wymaga okrelajcych, w jaki sposb maj by zbudowane mechanizmy bezpieczestwa aplikacji.
Wymagania dotyczce weryfikacji mechanizmw bezpieczestwa L3.7 Zweryfikuj rcznie aplikacj zgodnie z wymaganiami dla poziomu 3 opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to rozszerzenie wymaga dla weryfikacji rcznej wprowadzonych na poziomie 2. Udokumentuj architektur bezpieczestwa i uyj jej do weryfikacji poprawnoci projektu i uycia wszystkich mechanizmw bezpieczestwa poprzez wykonanie modelowania zagroe. Jest to nowe wymaganie na poziomie 3.
L3.8
Strona 13
ASVS 2009
Wymagania Raportowe L3.9 Napisz raport z weryfikacji opisujcy architektur bezpieczestwa aplikacji poprzez pogrupowanie jej komponentw w wysoko-poziomow architektur, obejmujc wyniki modelowania zagroe oraz zawierajcy wyniki weryfikacji zgodnie z wymaganiami opisanymi w sekcji Wymagania raportowe z weryfikacji. Jest to rozszerzenie wymaga raportowych poziomu 2.
Na poziomie 3 komponenty aplikacji mog by okrelone jako pojedyncze lub grupy plikw rdowych, bibliotek i/lub plikw wykonywalnych, zorganizowane w wysoko-poziomow architektur (np. komponenty MVC, komponenty funkcji biznesowych, komponenty warstwy danych). Na poziomie 3 wymagane s dodatkowo informacje wspomagajce modelowanie zagroe takie jak czynniki stwarzajce zagroenia oraz aktywa. cieka lub cieki, jakimi w wysokopoziomowym widoku aplikacji przechodzi dane zapytanie uytkownika kocowego musz by udokumentowane, jak przedstawiono to na rysunku poniej. Na poziomie 3 wszystkie potencjalne cieki przechodzce przez wysoko-poziomowy widok aplikacji musz by sprawdzone.
Rysunek 8 Przykad architektury bezpieczestwa dla poziomu 3 OWASP ASVS12
12
Znaki dolara na diagramie oznaczaj aktywa.
Strona 14
ASVS 2009
Poziom 4 Weryfikacja wewntrzna

Poziom 4 (Weryfikacja wewntrzna) jest zwykle odpowiedni dla krytycznych aplikacji, od ktrych zaley ycie i bezpieczestwo, krytyczna infrastruktura lub zadania zwizane z obronnoci. Poziom 4 moe by rwnie odpowiedni dla aplikacji sucych do przetwarzania wraliwych aktyww. Poziom 4 zapewnia, e mechanizmy bezpieczestwa pracuj prawidowo, s uyte w aplikacji wszdzie tam gdzie s potrzebne do egzekwowania polityk specyficznych dla aplikacji oraz przestrzegano praktyk pisania bezpiecznego kodu. Zagroeniami dla bezpieczestwa w tym przypadku bd zdeterminowani napastnicy (wykwalifikowani i zmotywowani napastnicy skupieni na okrelonych celach, uywajcy m.in. specjalnie przystosowanych narzdzi skanujcych). Zakres weryfikacji wykracza poza zakres poziomu 3 by obj cay kod uywany przez aplikacj. Poziom 4 nie jest podzielony na element skadowe, jak to przedstawiono na rysunku poniej.
Rysunek 9 Poziom 4 OWASP ASVS
Wystpuj nastpujce minimalne wysoko-poziomowe wymagania dla aplikacji poziomu 4: Zakres Weryfikacji L4.1 L4.2 Zakres weryfikacji obejmuje cao kodu napisanego lub zmodyfikowanego w celu stworzenia aplikacji. To wymaganie zostao wprowadzone na poziomie 1. Zakres weryfikacji obejmuje kod wszystkich pochodzcych z firm trzecich framework-w, bibliotek i funkcjonalnoci bezpieczestwa usug, realizujcych lub wspomagajcych bezpieczestwo aplikacji. To wymaganie zostao wprowadzone na poziomie 2. Zakres weryfikacji obejmuje kod wszystkich pochodzcych z firm trzecich framework-w, bibliotek i usug zwizanych z aplikacj. To wymaganie zostao wprowadzone na poziomie 3. Zakres weryfikacji obejmuje cao pozostaego kodu zwizanego z aplikacj, wczajc w to frameworki, biblioteki, rodowiska uruchomieniowe oraz narzdzia suce do rozwoju, budowania i wdraania aplikacji. Zakres nie obejmuje kodu oprogramowania platformy, takich jak serwer aplikacyjny, serwer bazy danych, wirtualna maszyna lub system operacyjny, ktre s poddawane staej publicznej kontroli. Jest to nowe wymaganie na poziomie 4.
L4.3 L4.4
Wymagania dotyczce zachowania mechanizmw bezpieczestwa L4.5 Zweryfikuj czy wszystkie mechanizmy bezpieczestwa dokonujce kontroli bezpieczestwa podejmuj decyzje w oparciu o list dozwolonych wynikw (model pozytywny). To wymaganie zostao wprowadzone na poziomie 2. Zweryfikuj czy wszystkie mechanizmy bezpieczestwa dokonujce kontroli bezpieczestwa oraz mechanizmy bezpieczestwa, ktrych dziaanie ma wpyw na bezpieczestwo nie mog by ominite zgodnie z wymaganiami dla poziomu 4 opisanymi w sekcji Dokadne wymagania weryfikacyjne. To wymaganie zostao wprowadzone na poziomie 2.
L4.6
Wymagania dotyczce uycia mechanizmw bezpieczestwa L4.7 Zweryfikuj czy wszystkie mechanizmy bezpieczestwa s uywane w aplikacji wszdzie tam, gdzie s potrzebne, ich implementacje s scentralizowane i umieszczone po stronie serwera zgodnie z wymaganiami dla poziomu 4 opisanymi w sekcji Dokadne wymagania weryfikacyjne. To wymaganie zostao wprowadzone na poziomie 3.
Strona 15
ASVS 2009
Wymagania dotyczce implementacji mechanizmw bezpieczestwa L4.8 Zweryfikuj czy aplikacja nie zawiera zoliwego kodu zgodnie z wymaganiami dla poziomu 4 opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to nowe wymaganie na poziomie 4.
Wymagania dotyczce weryfikacji mechanizmw bezpieczestwa L4.9 L4.10 Rcznie zweryfikuj aplikacj zgodnie z wymaganiami dla poziomu 4 opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to rozszerzenie wymagania z poziomu 3. Udokumentuj architektur bezpieczestwa i uyj jej do weryfikacji poprawnoci projektu i uycia mechanizmw bezpieczestwa poprzez wykonanie modelowania zagroe. To wymaganie zostao wprowadzone na poziomie 3. Przejrzyj rcznie cao kodu napisanego lub zmodyfikowanego w aplikacji pod ktem zoliwego kodu13 zgodnie z wymaganiami dla poziomu 4 opisanymi w sekcji Dokadne wymagania weryfikacyjne. Jest to nowe wymaganie na poziomie 4.
L4.11
Wymagania Raportowe L4.12 Napisz raport z weryfikacji opisujcy architektur bezpieczestwa aplikacji zgodnie z wymaganiami dla poziomu 3, obejmujcy cao kodu aplikacji i zawierajcy wyniki weryfikacji zgodnie z wymaganiami opisanymi w sekcji Wymagania raportowe z weryfikacji. Jest to rozszerzenie wymaga raportowych z poziomu 3.
Na poziomie 4 architektura aplikacji powinna by odwzorowana tak jak dla poziomu 3. Dodatkowo poziom 4 wymaga by cao kodu aplikacji, wczajc w to kod, ktry nie podlega wyraniej ocenie, by zidentyfikowany, jako cz definicji aplikacji, jak to przedstawiono na diagramie poniej. Ten kod musi zawiera wszystkie bliblioteki, frameworki i kod wspomagajcy, od ktrego zaley praca aplikacji. Poprzednie weryfikacje tych komponentw mog by uyte ponownie, jako cz innej weryfikacji. Kod platform takich jak system operacyjny, maszyna wirtualna lub bazowe biblioteki dostarczone ze rodowiskiem wirtualnej maszyny, serwer Web lub serwer aplikacyjny nie jest uwzgldniany na poziomie 4. Na przykad biblioteki zwizane ze rodowiskiem uruchomieniowym Java nie musz podlega ocenie na poziomie 4.
Zoliwy kod nie jest dokadnie tym samym pojciem co malware. Patrz definicja zoliwego kodu w sowniczku.
13
Strona 16
ASVS 2009
Rysunek 10 Przykad niezbadanego kodu na poziomie 4 OWASP ASVS
Interpretacje wymaga i precedensy

OWASP ASVS jest yjcym dokumentem. Jeli przeprowadzasz weryfikacj bezpieczestwa aplikacji zgodnie z tym standardem powiniene zapozna si z artykuami na stronie projektu OWASP ASVS pod adresem: http://www.owasp.org/index.php/ASVS#Articles_Below_-_More_About_ASVS_and_Using_It Artykuy na stronie projektu OWASP ASVS zawieraj objanienia wymaga, precedensy werdyktw weryfikacji i pomocne podpowiedzi.
Strona 17
ASVS 2009
Szczegowe wymagania weryfikacyjne

Niniejsza sekcja ASVS okrela dokadne wymagania weryfikacyjne wywodzce si z wymaga wysoko-poziomowych dla kadego z poziomw weryfikacji zdefiniowanych w tym standardzie. Kada z poniszych sekcji okrela zestaw dokadnych wymaga weryfikacyjnych pogrupowanych w spokrewnione obszary. ASVS okrela nastpujce obszary wymaga bezpieczestwa: V1. Architektura bezpieczestwa V2. Uwierzytelnianie V3. Zarzdzanie sesj V4. Kontrola dostpu V5. Walidacja wejcia V6. Enkodowanie/escapowanie wyjcia V7. Kryptografia V8. Obsuga bdw i logowanie V9. Ochrona danych V10. Bezpieczestwo komunikacji V11. Bezpieczestwo HTTP V12. Konfiguracja zabezpiecze V13. Wyszukiwanie zoliwego kodu V14. Bezpieczestwo wewntrzne Poniej wymienione s wymagania dla kadego z tych obszarw, ktre musz by spenione dla kadego z poziomw weryfikacji: Poziom 1: Weryfikacja automatyczna Poziom 1A - Skanowanie dynamiczne (czciowa weryfikacja automatyczna) Poziom 1B - Skanowanie kodu rdowego (czciowa weryfikacja automatyczna) Poziom 2: Weryfikacja rczna Poziom 2A - Test bezpieczestwa (czciowa weryfikacja rczna) Poziom 2B - Przegld kodu (czciowa weryfikacja rczna) Poziom 3: Weryfikacja projektu Poziom 4: Weryfikacja wewntrzna
Strona 18
ASVS 2009
V1 Wymagania dotyczce dokumentacji architektury bezpieczestwa

Dla zapewnienia kompletnoci i dokadnoci (oraz powtarzalnoci w przypadku koniecznoci wykonania dziaa naprawczych) przeprowadzanej weryfikacji bezpieczestwa aplikacji wszystkie poziomy ASVS wymagaj udokumentowania pewnych podstawowych informacji dotyczcych architektury bezpieczestwa. Analiza moe wrci do wysoko-poziomowej architektury bezpieczestwa aplikacji, gdzie wyniki mog zosta ponownie przeledzone. Wymagania zaczynaj si od podstawowego poziomu iloci informacji na temat architektury bezpieczestwa, ktre musz by zgromadzone, a ich ilo ronie z kadym poziomem. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji odnonie dokumentacji architektury bezpieczestwa. Tabela 1 Wymagania dotyczce dokumentacji architektury bezpieczestwa w OWASP ASVS (V1) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 19
Wymaganie weryfikacyjne
V1.1
Zweryfikuj czy zostay zidentyfikowane wszystkie komponenty wystpujce w aplikacji (zarwno pojedyncze jak i grupy plikw rdowych, bibliotek i/lub plikw wykonywalnych). Zweryfikuj czy zostay zidentyfikowane wszystkie komponenty, ktre nie s czci aplikacji, ale s potrzebne do jej dziaania. Zweryfikuj czy zostaa zdefiniowana wysoko-poziomowa architektura aplikacji.14 Zweryfikuj czy wszystkie komponenty aplikacji zostay zdefiniowane w kategoriach funkcji biznesowych i/lub funkcji bezpieczestwa, dostarczanych przez te komponenty. Zweryfikuj czy wszystkie komponenty, ktre nie s czci aplikacji, ale zaley od nich jej dziaanie zostay zdefiniowane w kategoriach funkcji biznesowych i/lub funkcji bezpieczestwa, dostarczanych przez te komponenty.
V1.2
V1.3
V1.4
V1.5
Weryfikujcy moe opracowa lub udokumentowa wysoko-poziomowy projekt, jeli nie zosta dostarczony przez developera aplikacji.
14
ASVS 2009
V1.6
Zweryfikuj czy s dostpne informacje wynikajce z modelowania zagroe.
Strona 20
ASVS 2009
V2 Wymagania weryfikacyjne dotyczce uwierzytelniania

Wymagania weryfikacyjne dotyczce uwierzytelniania definiuj zestaw wymaga wzgldem bezpiecznego generowania i obsugi danych sucych do logowania. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji. Tabela 2 Wymagania dotyczce uwierzytelniania w OWASP ASVS (V2) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 21
V2.1
Zweryfikuj czy wszystkie strony oraz zasoby wymagaj uwierzytelnienia za wyjtkiem tych, ktre maj by dostpne publicznie. Zweryfikuj czy wszystkie pola suce do wprowadzania hase nie pokazuj hase uytkownikw w czasie ich wpisywania i maj wyczon funkcj automatycznego uzupeniania (to samo odnosi si do formularzy, w ktrych znajduj si pola suce do wprowadzania hase). Zweryfikuj czy po przekroczeniu maksymalnej liczby prb uwierzytelnienia konto zostaje zablokowane na okres czasu pozwalajcy na powstrzymanie atakw typu brute force. Zweryfikuj czy wszystkie mechanizmy uwierzytelniania s egzekwowane po stronie serwera. Zweryfikuj czy wszystkie mechanizmy uwierzytelniania (rwnie biblioteki wywoujce zewntrzne usugi uwierzytelniania) s zaimplementowane centralnie. Zweryfikuj czy wszystkie mechanizmy uwierzytelniania, ktre kocz prac niepowodzeniem robi to sposb bezpieczny. Zweryfikuj czy sia danych wykorzystywanych w procesie uwierzytelniania jest wystarczajca do wytrzymania atakw typowych dla zagroe we wdroonym rodowisku.
V2.2
V2.3
V2.4
V2.5
V2.6
V2.7
ASVS 2009
V2.8
Zweryfikuj czy wszystkie funkcje zarzdzania kontami s odporne na ataki przynajmniej w takim stopniu jak podstawowy mechanizm uwierzytelniania. Zweryfikuj czy uytkownicy mog w sposb bezpieczny zmieni swoje dane do uwierzytelniania przy uyciu mechanizmu, ktry jest odporny na ataki przynajmniej w takim stopniu jak podstawowy mechanizm uwierzytelniania. Zweryfikuj czy przed zezwoleniem na wykonanie wraliwych operacji w aplikacji wymagane jest ponowne uwierzytelnienie. Zweryfikuj czy wano danych do uwierzytelniania wygasa w konfigurowalnym przez administratora czasie. Zweryfikuj czy s logowane wszystkie decyzje dotyczce wynikw uwierzytelnienia. Zweryfikuj czy hasa do kont s tworzone z uyciem soli (salt) unikalnej dla danego konta (np. wewntrzny identyfikator uytkownika, czas utworzenia konta) i przeksztacane przy uyciu mechanizmu hashowania przed ich zapisaniem. Zweryfikuj czy wszystkie dane uwierzytelniania suce do uzyskiwania dostpu do usug zewntrznych wzgldem aplikacji s zaszyfrowane i przechowywane w zabezpieczonej lokalizacji (nie w kodzie rdowym). Zweryfikuj czy kod implementujcy mechanizmy uwierzytelniania lub wykorzystujcy te mechanizmy nie zawiera kodu zoliwego.
V2.9
V2.10
V2.11
V2.12
V2.13
V2.14
V2.15
V3 Wymagania weryfikacyjne dotyczce zarzdzania sesj

Wymagania weryfikacyjne dotyczce zarzdzania sesj definiuj zestaw wymaga wzgldem bezpiecznego uycia zapyta HTTP, odpowiedzi, sesji, cookie, nagwkw i logowania w celu zapewnienia odpowiedniego zarzdzania sesjami. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji.
Tabela 3 Wymagania dotyczce zarzdzania sesj w OWASP ASVS (V3)
Strona 22
ASVS 2009
Poziom 1A
Poziom 2A
Poziom 1B
Poziom 2B
Poziom 3
V3.1
Zweryfikuj czy aplikacja wykorzystuje domyln implementacj mechanizmu zarzdzania sesj, dostarczan przez framework. Zweryfikuj czy sesje s uniewaniane przy wylogowaniu uytkownika. Zweryfikuj czy sesje wygasaj po okrelonym czasie bezczynnoci. Zweryfikuj czy sesje wygasaj po administracyjnie konfigurowalnym maksymalnym okresie czasu, niezalenie od aktywnoci (bezwarunkowy okres wanoci). Zweryfikuj czy wszystkie strony, do ktrych dostp wymaga uwierzytelnienia zawieraj linki umoliwiajce wylogowanie. Zweryfikuj czy identyfikatory sesji nie s nie s ujawniane poza nagwkami cookie, w szczeglnoci nie s ujawniane w URL, komunikatach bdw lub logach. Naley rwnie zweryfikowa, czy aplikacja nie pozwala na przepisywanie w URL cookie sesyjnych. Zweryfikuj czy identyfikator sesji jest zmieniany przy logowaniu. Zweryfikuj czy identyfikator sesji jest zmieniany przy ponownym uwierzytelnieniu. Zweryfikuj czy identyfikator sesji jest zmieniany lub usuwany przy wylogowaniu. Zweryfikuj czy tylko identyfikatory sesji wygenerowane przez framework aplikacji s uznawane przez aplikacj za poprawne. Zweryfikuj czy tokeny uwierzytelnionych sesji s odpowiednio dugie i losowe by wytrzyma ataki typowe dla zagroe we wdroonym rodowisku.
V3.2 V3.3 V3.4
V3.5
V3.6
V3.7 V3.8
V3.9
V3.10
V3.11
Strona 23
Poziom 4
ASVS 2009
V3.12
Zweryfikuj czy cookie zawierajce uwierzytelnione tokeny/identyfikatory sesji maj swoje atrybuty domain i path ustawione odpowiednio do tej lokalizacji. Zweryfikuj czy cay kod implementujcy lub wykorzystujcy mechanizmy zarzdzania sesj nie zawiera kodu zoliwego.
V3.13
V4 Wymagania weryfikacyjne dotyczce kontroli dostpu

Wymagania weryfikacyjne dotyczce kontroli dostpu definiuj, w jaki sposb aplikacja moe bezpiecznie egzekwowa kontrol dostpu. W wikszoci aplikacji kontrola dostpu musi by realizowana w wielu miejscach i rnych warstwach aplikacyjnych. Niniejsze wymagania definiuj wymagania weryfikacyjne dotyczce kontroli dostpu do URL, funkcji biznesowych, danych, usug i plikw. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji.
Strona 24
ASVS 2009
Tabela 4 Wymagania dotyczce kontroli dostpu w OWASP ASVS (V4) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 25
V4.1
Zweryfikuj czy uytkownicy mog uzyska dostp wycznie do chronionych funkcji, do ktrych posiadaj przyznane uprawnienia. Zweryfikuj czy uytkownicy mog uzyska dostp wycznie do URLi, do ktrych posiadaj przyznane uprawnienia. Zweryfikuj czy uytkownicy mog uzyska dostp wycznie do tych plikw z danymi, do ktrych posiadaj przyznane uprawnienia. Zweryfikuj czy bezporednie odwoania do obiektw s chronione w taki sposb, e tylko autoryzowane obiekty s osigalne dla uytkownikw. Zweryfikuj czy przegldanie zawartoci katalogw jest wyczone, chyba e wiadomie zadecydowano inaczej. Zweryfikuj czy uytkownicy mog uzyska dostp wycznie do usug, do ktrych posiadaj przyznane uprawnienia. Zweryfikuj czy uytkownicy mog uzyska dostp wycznie do tych danych, do ktrych posiadaj przyznane uprawnienia. Zweryfikuj czy mechanizmy kontroli dostpu, ktre kocz prac niepowodzeniem robi to w sposb bezpieczny. Zweryfikuj czy reguy kontroli dostpu warstwy prezentacji s egzekwowane po stronie serwera. Zweryfikuj czy wszystkie atrybuty uytkownikw i danych oraz informacje o polityce wykorzystywane przez mechanizmy kontroli dostpu nie mog by poddawane manipulacji przez uytkownikw, chyba, e s oni do tego uprawnieni.
V4.2
V4.3
V4.4
V4.5
V4.6
V4.7
V4.8
V4.9
V4.10
ASVS 2009
V4.11
Zweryfikuj czy wszystkie mechanizmy kontroli dostpu s egzekwowane po stronie serwera. Zweryfikuj czy istnieje scentralizowany mechanizm (rwnie dla bibliotek wywoujcych zewntrzne usugi autoryzacji) zabezpieczajcy dostp do kadego typu chronionych zasobw. Zweryfikuj czy nie mona omin ogranicze dotyczcych wejcia i dostpu naoonych na aplikacj przez wymagania biznesowe (takie jak dzienne limity transakcji lub kolejno zada). Zweryfikuj czy wszystkie decyzje dotyczce kontroli dostpu mog by logowane a wszystkie decyzje zakoczone niepowodzeniem s logowane. Zweryfikuj czy cay kod implementujcy lub wykorzystujcy mechanizmy kontroli dostpu nie zawiera kodu zoliwego.
V4.12
V4.13
V4.14
V4.15
V5 Wymagania weryfikacyjne dotyczce walidacji wejcia

Wymagania weryfikacyjne dotyczce walidacji wejcia definiuj zestaw wymaga wzgldem walidacji danych wejciowych tak, aby mogy by bezpiecznie uyte w aplikacji. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji. Tabela 5 Wymagania dotyczce walidacji wejcia w OWASP ASVS (V5) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 26
V5.1
Zweryfikuj czy rodowisko uruchomieniowe nie jest podatne na przepenienia bufora lub mechanizmy bezpieczestwa zapobiegaj wystpieniu takich bdw. Zweryfikuj czy dla wszystkich wej s zdefiniowane i zastosowane wzorce pozytywnej walidacji. Zweryfikuj czy wszystkie walidacje wejcia zakoczone niepowodzeniem powoduj odrzucenie lub oczyszczenie danych wejciowych.
V5.2
V5.3
ASVS 2009
V5.4
Zweryfikuj czy dla wszystkich rde wejcia jest zdefiniowana strona kodowa, np. UTF-8. Zweryfikuj czy caa walidacja danych wejciowych jest realizowana po stronie serwera. Zweryfikuj czy aplikacja wykorzystuje jeden mechanizm walidacji danych wejciowych dla kadego typu przyjmowanych danych. Zweryfikuj czy wszystkie walidacje wejcia zakoczone niepowodzeniem s logowane. Zweryfikuj czy dla wszystkich dekoderw lub interpreterw przed rozpoczciem walidacji wszystkie dane wejciowe s ustandaryzowane. Zweryfikuj czy mechanizmy walidacji wejcia nie zawieraj kodu zoliwego
V5.5
V5.6
V5.7
V5.8
V5.9
V6 Wymagania weryfikacyjne dotyczce enkodowania/escapowania wyjcia

Wymagania weryfikacyjne dotyczce enkodowania/escapowania wyjcia definiuj zestaw wymaga, ktre pozwalaj upewni si, e dane wyjciowe s poprawnie enkodowane tak, aby byy bezpieczne dla zewntrznych aplikacji. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji. Tabela 6 Wymagania dotyczce enkodowania/escapowania wyjcia w OWASP ASVS (V6) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 27
V6.1
Zweryfikuj czy wszystkie niezaufane dane, ktrych wynikiem jest kod HTML (elementy HTML, atrybuty HTML, wartoci danych javascript, bloki CSS i atrybuty URI) podlegaj escapowaniu odpowiednio do kontekstu. Zweryfikuj czy wszystkie mechanizmy enkodowania/escapowania s zaimplementowane po stronie serwera.
V6.2
ASVS 2009
V6.3
Zweryfikuj czy mechanizmy enkodowania/escapowania danych wyjciowych enkoduj wszystkie znaki, ktre nie s uwaane za bezpieczne dla danego interpretera. Zweryfikuj czy wszystkie niezaufane dane trafiajce do interpreterw SQL uywaj parametryzowanych interfejsw (ang. prepared statements), przygotowanych instrukcji lub s waciwie escapowane. Zweryfikuj czy wszystkie niezaufane dane, ktrych wynikiem jest XML uywaj parametryzowanych interfejsw lub s waciwie escapowane. Zweryfikuj czy wszystkie niezaufane dane uywane w zapytaniach LDAP s waciwie escapowane. Zweryfikuj czy wszystkie niezaufane dane uywane jako parametry polece systemu operacyjnego s waciwie escapowane. Zweryfikuj czy wszystkie niezaufane dane, ktre s przekazywane do interpreterw niewymienionych powyej s waciwie escapowane. Zweryfikuj czy dla kadego typu enkodowania/escapowania wyjcia wykonywanego przez aplikacj istnieje pojedynczy mechanizm bezpieczestwa dla tego typu docelowych danych wyjciowych. Zweryfikuj czy kod implementujcy lub wykorzystujcy mechanizmy walidacji wyjcia nie zawiera kodu zoliwego.
V6.4
V6.5
V6.6
V6.7
V6.8
V6.9
V6.10
V7 Wymagania weryfikacyjne dotyczce kryptografii

Wymagania weryfikacyjne dotyczce kryptografii definiuj zestaw wymaga, ktre mog by uyte do weryfikacji uywanych w aplikacji operacji szyfrowania, zarzdzania kluczami, generowania liczb losowych oraz hashowania. Aplikacje powinny zawsze korzysta z moduw kryptograficznych sprawdzonych pod ktem zgodnoci z FIPS 140-2 lub innym rwnowanym standardem (np. niepochodzcym z USA). Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji.
Strona 28
ASVS 2009
Tabela 7 Wymagania dotyczce kryptografii w OWASP ASVS (V7) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 29
V7.1
Zweryfikuj czy wszystkie funkcje kryptograficzne suce do zabezpieczenia danych poufnych przed uytkownikiem aplikacji s zaimplementowane po stronie serwera. Zweryfikuj czy wszystkie moduy kryptograficzne, ktre kocz prac niepowodzeniem robi to sposb bezpieczny. Zweryfikuj czy dostp do wszystkich kluczy master secret jest chroniony przed nieuprawnionym dostpem (klucz master secret to poufne dane aplikacji przechowywane na dysku w formie niezaszyfrowanego pliku, uywane do ochrony dostpu do informacji o konfiguracji zabezpiecze). Zweryfikuj czy hashe hase s tworzone przy uyciu soli. Zweryfikuj czy dziaania moduu kryptograficznego zakoczone niepowodzeniem s logowane. Zweryfikuj czy wszystkie liczby losowe, losowe nazwy plikw, losowe GUIDy oraz losowe cigi znakw, ktrych napastnik nie powinien odgadn generowane s z wykorzystaniem zatwierdzonego generatora liczb losowych z moduu kryptograficznego. Zweryfikuj czy moduy kryptograficzne wykorzystywane przez aplikacj zostay zatwierdzone w zakresie zgodnoci ze standardem FIPS 140-2 lub jego odpowiednikiem (patrz http://csrc.nist.gov/groups/STM/cmvp/validati on.html). Zweryfikuj czy moduy kryptograficzne pracuj w trybie zgodnym z opublikowanymi politykami bezpieczestwa dla danego moduu (patrz http://csrc.nist.gov/groups/STM/cmvp/validati on.html). Zweryfikuj czy istnieje jasna polityka okrelajca jak s zarzdzane klucze kryptograficzne (np. jak s generowane, rozprowadzane, uniewaniane, w jaki sposb wygasaj). Zweryfikuj czy ta polityka jest waciwie egzekwowana. Zweryfikuj czy cay kod wspierajcy lub wykorzystujcy moduy kryptograficzne nie zoliwego zawiera kodu zoliwego.
V7.2
V7.3
V7.4 V7.5
V7.6
V7.7
V7.8
V7.9
V7.10
ASVS 2009
V8 Wymagania weryfikacyjne dotyczce obsugi bdw i logowania

Wymagania weryfikacyjne dotyczce obsugi bdw i logowania definiuj zestaw wymaga, ktre mog by uyte do weryfikacji ledzenia zdarze istotnych dla bezpieczestwa i identyfikacji zachowa ataku. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji. Tabela 8 Wymagania dotyczce obsugi bdw i logowania w OWASP ASVS (V8) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 30
V8.1
Zweryfikuj czy aplikacja nie zwraca komunikatw o bdach lub ladw stosu (stack traces), zawierajcych dane wraliwe, ktre mog pomc napastnikowi, wczajc w to identyfikatory sesji i dane osobowe. Zweryfikuj czy wszystkie bdy po stronie serwera s obsugiwane przez serwer. Zweryfikuj czy wszystkie mechanizmy logowania s zaimplementowane na serwerze. Zweryfikuj czy logika obsugi bdw w mechanizmach bezpieczestwa domylnie zabrania dostpu. Zweryfikuj czy mechanizmy logowania zdarze bezpieczestwa zapewniaj moliwo logowania zdarze istotnych dla bezpieczestwa zakoczonych zarwno sukcesem jak i porak.
V8.2
V8.3
V8.4
V8.5
ASVS 2009
V8.6
Zweryfikuj czy kade zdarzenie w logu zawiera: 1. znacznik czasu z wiarygodnego rda, 2. poziom wanoci zdarzenia, 3. informacj czy oznaczenie e zdarzenie jest istotne dla bezpieczestwa (jeli rnego typu logi s wymieszane), 4. tosamo uytkownika, ktry spowodowa zdarzenie (jeli ze zdarzeniem powizany jest uytkownik), 5. rdowy adres IP zapytania zwizanego ze zdarzeniem, 6. informacj czy zdarzenie zakoczyo si sukcesem czy porak, 7. opis zdarzenia. Zweryfikuj czy wszystkie zdarzenia zawierajce niezaufane dane nie zostan uruchomione jako kod w oprogramowaniu sucym do przegldania logw. Zweryfikuj czy logi bezpieczestwa s chronione przed nieautoryzowanym dostpem i modyfikacj. Zweryfikuj czy aplikacja uywa pojedynczej implementacji mechanizmu logowania. Zweryfikuj czy aplikacja nie loguje specyficznych dla aplikacji wraliwych danych, ktre mogyby pomc napastnikowi, wczajc w to identyfikatory sesji, dane osobowe lub informacje wraliwe. Zweryfikuj czy dostpne s narzdzia suce do analizy logw pozwalajce analitykowi na wyszukiwanie zdarze odpowiadajcych kombinacjom kryteriw wyszukiwania, obejmujcych wszystkie pola w logach w formacie wspieranym przez dany system. Zweryfikuj czy kod implementujcy lub wykorzystujcy mechanizmy obsugi bdw i logowania nie zoliwego zawiera kodu zoliwego.
V8.7
V8.8
V8.9
V8.10
V8.11
V8.12
Strona 31
ASVS 2009
V9 Wymagania weryfikacyjne dotyczce ochrony danych

Wymagania weryfikacyjne dotyczce ochrony danych definiuj zestaw wymaga, ktre mog by uyte do weryfikacji zabezpieczania danych wraliwych (np. numer karty kredytowej, numer paszportu, informacje umoliwiajce identyfikacj osb). Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji. Tabela 9 Wymagania dotyczce ochrony danych w OWASP ASVS (V9) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 32
V9.1
Zweryfikuj czy dla wszystkich formularzy zawierajcych dane wraliwe wyczone jest cachowanie po stronie klienta, wczajc w to funkcjonalno automatycznego wypeniania pl. Zweryfikuj czy zidentyfikowano list danych wraliwych przetwarzanych przez aplikacj i istnieje jasna polityka okrelajca jak musi by kontrolowany dostp do tych danych oraz kiedy te dane musz podlega szyfrowaniu (zarwno w trakcie przechowywania jak i przesyania). Upewnij si, e polityka jest poprawnie egzekwowana. Zweryfikuj czy wszystkie dane wraliwe s przesyane do serwera wewntrz wiadomoci HTTP (tzn. parametry URL nie s uywane do przesyania danych wraliwych). Zweryfikuj czy wszystkie wraliwe dane w cache lub kopiach tymczasowych przesyane do klienta s chronione przed nieautoryzowanym dostpem lub czyszczone/uniewaniane po uzyskaniu dostpu do danych wraliwych przez upowanionego uytkownika (np. s ustawiane odpowiednie nagwki kontrolne Cache-Control: no-cache i no-store). Zweryfikuj czy wszystkie wraliwe dane w cache lub kopiach tymczasowych przechowywane na serwerze s chronione przed nieautoryzowanym dostpem lub czyszczone/uniewaniane po uzyskaniu dostpu do danych wraliwych przez upowanionego uytkownika.
V9.2
V9.3
V9.4
V9.5
ASVS 2009
V9.6
Zweryfikuj czy istnieje metoda usunicia z aplikacji kadego typu wraliwych danych na kocu ich wymaganego okresu wanoci.
V10 Wymagania weryfikacyjne dotyczce bezpieczestwa komunikacji

Wymagania weryfikacyjne dotyczce bezpieczestwa komunikacji definiuj zestaw wymaga, ktre mog by uyte do weryfikacji czy caa komunikacja z aplikacj jest poprawnie zabezpieczona. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji. Tabela 10 Wymagania dotyczce bezpieczestwa komunikacji w OWASP ASVS (V10) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 33
V10.1
Zweryfikuj czy moliwe jest zbudowanie cieki z zaufanego CA do kadego serwerowego certyfikatu Transport Layer Security (TLS) i kady certyfikat serwera jest wany. Zweryfikuj czy nieudane poczenia TLS nie s powtrnie nawizywane, jako poczenia niezabezpieczone. Zweryfikuj czy TLS uywane jest dla wszystkich pocze (zewntrznych i backendowych), ktre s uwierzytelnione lub s zwizane z wraliwymi danymi lub funkcjami. Zweryfikuj czy nieudane backendowe poczenia TLS s logowane. Zweryfikuj czy cieki certyfikatw s budowane i weryfikowane dla wszystkich certyfikatw klienckich przy uyciu skonfigurowanych powiza zaufania i informacji nt. uniewaniania certyfikatw. Zweryfikuj czy wszystkie poczenia do zewntrznych systemw, ktre dotycz wraliwych informacji lub funkcji s uwierzytelnione. Zweryfikuj czy wszystkie poczenia do zewntrznych systemw, ktre dotycz wraliwych informacji lub funkcji uywaj konta o minimalnych przywilejach koniecznych do waciwej pracy aplikacji.
V10.2
V10.3
V10.4 V10.5
V10.6
V10.7
ASVS 2009
V10.8
Zweryfikuj czy aplikacja uywa implementacji TLS opartej na pojedynczym standardzie, skonfigurowanej do dziaania w zatwierdzonym trybie pracy (patrz http://csrc.nist.gov/groups/STM/cm vp/documents/fips1402/FIPS1402IG.pdf). Zweryfikuj czy dla wszystkich pocze jest zdefiniowane kodowanie znakw (np. UTF-8).
V10.9
V11 Wymagania weryfikacyjne dotyczce bezpieczestwa HTTP

Wymagania weryfikacyjne dotyczce bezpieczestwa HTTP definiuj zestaw wymaga, ktre mog by uyte do weryfikacji bezpieczestwa zapyta HTTP, odpowiedzi, sesji, cookie, nagwkw i logowania. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji.
Tabela 11 Wymagania dotyczce bezpieczestwa HTTP w OWASP ASVS (V11) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 34
V11.1
Zweryfikuj czy przekierowania nie zawieraj danych, ktre nie podlegay walidacji. Zweryfikuj czy aplikacja akceptuje tylko zdefiniowany zestaw metod zapyta HTTP, takich jak GET i POST. Zweryfikuj czy kada odpowied HTTP zawiera nagwek content type, okrelajcy zestaw bezpiecznych znakw (np. UTF-8). Zweryfikuj czy flaga HTTPOnly jest wykorzystywana dla wszystkich cookie, do ktrych nie jest wymagany dostp z JavaScript. Zweryfikuj czy flaga secure jest wykorzystywana dla wszystkich cookie, ktre zawieraj wraliwe informacje, wczajc w to cookie sesyjne. Zweryfikuj czy nagwki HTTP w zapytaniach i odpowiedziach zawieraj wycznie drukowalne znaki ASCII.
V11.2
V11.3
V11.4
V11.5
V11.6
ASVS 2009
V11.7
Zweryfikuj czy aplikacja generuje silne losowe tokeny bdce czci linkw i formularzy powizanych z transakcjami lub majcych dostp do wraliwych danych, a take w trakcie przetwarzania takich zapyta aplikacja sprawdza obecno tego tokena oraz poprawno jego wartoci odpowiednio dla biecego uytkownika. 15
V12 Wymagania weryfikacyjne dotyczce konfiguracji zabezpiecze

Wymagania weryfikacyjne dotyczce konfiguracji zabezpiecze definiuj zestaw wymaga, ktre mog by uyte do weryfikacji bezpiecznego przechowywania wszystkich informacji o konfiguracji, ktre kieruj zachowaniem aplikacji zwizanym z bezpieczestwem. Ochrona tych informacji o konfiguracji jest krytyczna dla bezpiecznego dziaania aplikacji. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji. Tabela 12 Wymagania dotyczce konfiguracji zabezpiecze w OWASP ASVS (V12) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 35
V12.1
Zweryfikuj czy wszystkie informacje o konfiguracji zwizanej z bezpieczestwem s przechowywane w miejscach chronionych przed nieautoryzowanym dostpem. Zweryfikuj czy wszelki dostp do aplikacji jest zablokowany w przypadku, gdy aplikacja nie moe uzyska dostpu do informacji o swojej konfiguracji zabezpiecze. Zweryfikuj czy wszystkie zmiany w zarzdzanych przez aplikacj ustawieniach konfiguracji zabezpiecze s logowane w logu zdarze bezpieczestwa. Zweryfikuj czy przechowywana konfiguracja dla uatwienia audytu moe by pobrana w formacie czytelnym dla czowieka.
V12.2
V12.3
V12.4
Wymaganie opisuje mechanizm potrzebny do ochrony przed atakami Cross Site Request Forgery (CSRF).
15
ASVS 2009
V13 Wymagania weryfikacyjne dotyczce wyszukiwania zoliwego kodu

Dla poziomu 4 wymagane jest przeszukiwanie kadego kodu nieprzeanalizowanego jeszcze po weryfikacji aplikacji na poziomie 3 pod ktem zoliwego kodu. Tabela poniej okrela wymagania dotyczce wyszukiwania zoliwego kodu, ktre zostay wprowadzone na poziomie 4. Tabela 13 Wymagania dotyczce wyszukiwania zoliwego kodu w OWASP ASVS (V13) Poziom 1A Poziom 2A Poziom 2B Poziom 1B Poziom 3 Poziom 4 Strona 36
Wymaganie werfikacyjne
V13.1
Zweryfikuj czy w kodzie, ktry zosta napisany lub zmodyfikowany w celu stworzenia aplikacji nie ma zoliwego kodu. 16 Zweryfikuj czy integralno interpretowanego kodu, bibliotek, plikw wykonywalnych i plikw konfiguracyjnych jest weryfikowana przy uyciu sum kontrolnych lub hashy.
V13.2
16
Przykadowo: zbadaj wywoania do zegara systemowego pod ktem wyszukiwania bomb czasowych(time bomb), funkcje nie zwizane z wymaganiami biznesowymi pod ktem wyszukiwania tylnych wej (back door), cieki uruchomieniowe pod ktem wyszukiwania jaj wielkanocnych (Easter egg), operacje finansowe pod ktem wyszukiwania bdnej logiki, ktra moe wskazywa na atak salami, inne rodzaje zoliwego kodu.
ASVS 2009
V14 Wymagania wewntrznego
weryfikacyjne
dotyczce
bezpieczestwa
Wymagania weryfikacyjne dotyczce bezpieczestwa wewntrznego definiuj zestaw wymaga, ktre mog by uyte do weryfikacji czy aplikacja dodatkowo chroni sam siebie przed bdami implementacyjnymi. Tabela poniej okrela wymagania odpowiednie dla kadego z czterech poziomw weryfikacji.
Tabela 14 Wymagania dotyczce bezpieczestwa wewntrznego w OWASP ASVS (V14) Poziom 1A Poziom 2A Poziom 1B Poziom 2B Poziom 3 Poziom 4 Strona 37
V14.1
Zweryfikuj czy aplikacja chroni przed nieautoryzowanym dostpem lub modyfikacj atrybuty uytkownika i danych oraz informacje o polityce uywane przez mechanizmy kontroli dostpu. Zweryfikuj czy interfejsy mechanizmw bezpieczestwa s wystarczajco proste w uyciu by byy prawidowo uywane przez developerw. Zweryfikuj czy aplikacja odpowiednio chroni przed nieodpowiednim jednoczesnym dostpem wspdzielone zmienne i zasoby.
V14.2
V14.3
ASVS 2009
Wymagania dotyczce raportowania weryfikacji

Raport OWASP ASVS zawiera opis aplikacji, ktra zostaa przeanalizowana wzgldem wymaga OWASP ASVS dla danego poziomu. Raport dokumentuje rwnie wyniki analizy, w tym wymagane poprawki dla podatnoci. Wymagania raportowe ASVS okrelaj rodzaj informacji, ktrych obecno jest wymagana w raporcie. Wymagania raportowe ASVS nie okrelaj struktury, organizacji ani formatu raportu. Wymagania raportowe ASVS nie wykluczaj moliwoci zamieszczania w raporcie dodatkowych informacji. Rodzaj informacji wymaganych przez kady z zestaww wymaga raportowych ASVS moe by nazywany, formatowany i organizowany zgodnie z wymaganiami weryfikujcego. Wymagania raportowe ASVS s spenione, jeli obecne s wszystkie wymagane informacje. Raport powinien zawiera wszelkie materiay niezbdne czytelnikowi do zrozumienia przeprowadzonej analizy i jej wynikw, wczajc w to informacje o konfiguracji oraz fragmenty kodu jak przedstawiono na przylegym rysunku, ktry moe by uywany przy tworzeniu zarysu raportu.
Raport
Wstp
Opis
Architektura
Wyniki
Zweryfikuj... Pozytywny/ Negatywny
Rysunek 11 Zawarto raportu
R1 Wstp do raportu
R1.1 R1.2 R1.3 R1.4 Wstp do raportu powinien dostarcza informacji wystarczajcych do identyfikacji zarwno raportu, jak i aplikacji, ktra jest tematem raportu. Wstp do raportu powinien podsumowywa cakowite zaufanie do bezpieczestwa aplikacji. Wstp do raportu powinien identyfikowa kluczowe ryzyka biznesowe zwizane z dziaaniem aplikacji. Wstp do raportu powinien opisywa zasady zaangaowania zwizane z wykonywaniem weryfikacji lub to, co mogo ogranicza zakres weryfikacji.
R2 Opis Aplikacji
R2.1 Sekcja opis aplikacji powinna dostarczy odpowiedniego opisu aplikacji pomagajcego w zrozumieniu jej dziaania i rodowiska, w ktrym dziaa.
R3 Architektura bezpieczestwa aplikacji

R3.1 Sekcja architektura bezpieczestwa aplikacji powinna dostarcza dodatkowe szczegy opisujce aplikacj, stanowic pierwszy krok w zapewnieniu czytelnikowi raportu pewnoci, e wykonana analiza jest kompletna i dokadna. Ta cz raportu dostarcza kontekst dla analizy. Informacje przedstawione w tej sekcji bd suy w trakcie analizy do identyfikacji niespjnoci.Ta cz raportu powinna zawiera detale o szczegowoci zalenej od poziomu OWASP ASVS, zgodnie z ktrym zostaa przeprowadzona analiza. Szczegy bd rni si w zalenoci od poziomu (ASVS).
Strona 38
ASVS 2009
R4 Wyniki weryfikacji
R4.1 Te wyniki weryfikacji powinny przedstawia rezultat analizy przeprowadzonej zgodnie z sekcj Wymagania weryfikacyjne niniejszego standardu, wcznie z opisem wymaganych poprawek dla podatnoci, w nastpujcy sposb:
Tabela 15 Zawarto wynikw weryfikacji w raporcie OWASP ASVS Poziom Wyniki poziomu 1 Pozytywny Werdykt. Konfiguracja narzdzia (jeli narzdzie moe suy sprawdzeniu) lub uzasadnienie werdyktu (argument przemawiajcy za kompletnoci i poprawnoci, zapewniajcy specyficzny dowd). Mapowanie moliwoci narzdzi automatycznych na dajce si zastosowa szczegowe wymagania weryfikacyjne. Opis konfiguracji narzdzia i mapowanie moliwoci narzdzia musz by dostarczone jako cz raportu tylko jednorazowo. Werdykt Lokalizacja (URL z parametrami i/lub ciek do kodu rdowego, nazwa i numer(y) linii) Opis (uwzgldniajcy informacje konfiguracyjne tam, gdzie jest to odpowiednie) Ocena ryzyka
17
Negatywny
Uzasadnienie ryzyka
Opis konfiguracji narzdzia oraz mapowanie moliwoci narzdzia musz by rwnie dostarczone jako cz raportu. Wyniki poziomw 24 Werdykt Uzasadnienie werdyktu (argument przemawiajce za kompletnoci i poprawnoci, zapewniajcy specyficzny dowd) Werdykt Lokalizacja (URL z parametrami i/lub ciek do kodu rdowego, nazwa i numer(y) linii)
Opis (uwzgldniajcy ciek komponentw aplikacji oraz kroki potrzebne do odtworzenia) Ocena ryzyka (patrz OWASP Risk Rating Methodology) Uzasadnienie ryzyka
Wicej informacji na temat identyfikacji i szacowania ryzyk zwizanych z podatnociami mona znale w Testing Guide (OWASP, 2008).
17
Strona 39
ASVS 2009
Sowniczek
Application Security Verification Standard (ASVS) standard OWASP definiujcy cztery poziomy weryfikacji bezpieczestwa aplikacji. Architektura bezpieczestwa abstrakcyjna reprezentacja projektu aplikacji, ktra identyfikuje i opisuje gdzie i jak s uyte mechanizmy bezpieczestwa oraz lokalizacj i wraliwo danych uytkownika oraz aplikacji. Ataki DoS zalewanie aplikacji wiksz liczb zapyta, ni ta jest w stanie obsuy. Atak salami rodzaj zoliwego kodu, ktry jest wykorzystywany do przekierowywania maych sum pienidzy niezauwaalnych w transakcjach finansowych. Bezpieczestwo aplikacji bezpieczestwo na poziomie aplikacji skupia si na analizie komponentw skadajcych si na warstw aplikacji modelu OSI, nie skupiajc si np. na systemie operacyjnym poniej lub podczonych sieciach. Bezpieczestwo komunikacji - ochrona danych aplikacji podczas transmisji pomidzy komponentami aplikacji, pomidzy klientami i serwerami oraz pomidzy systemami zewntrznymi a aplikacj. Biaa lista lista dozwolonych danych lub operacji, na przykad lista znakw, ktre s dozwolone w celu sprawdzania poprawnoci danych wejciowych. Bomba czasowa rodzaj zoliwego kodu, ktry nie uruchamia si przed zaprogramowanym czasem lub dat. Cel weryfikacji (TOV) jeli wykonujesz weryfikacj bezpieczestwa aplikacji zgodnie z wymaganiami OWASP ASVS, weryfikacja ta bdzie dotyczy okrelonej aplikacji. Ta aplikacja jest nazywana celem weryfikacji (TOV). Common Criteria (CC) wieloczciowy standard, ktry moe by uywany, jako podstawa do weryfikacji projektu i wdroenia mechanizmw bezpieczestwa w produktach IT. Czarna lista lista danych lub operacji, ktre nie s dozwolone na przykad lista znakw, ktre nie s dozwolone jako dane wejciowe. FIPS 140-2 standard, ktry moe by uywany jako podstawa weryfikacji projektu i implementacji moduw kryptograficznych. Jaja wielkanocne rodzaj zoliwego kodu uruchamianego poprzez specyficzne dane wejciowe uytkownika. Kontrola dostpu rodki ograniczajce dostp do plikw, wskazanych funkcji, adresw URL i danych w oparciu o tosamo uytkownikw i/lub grup, do ktrych nale. Kod zoliwy kod wczony do aplikacji podczas jej tworzenia, bez wiedzy waciciela aplikacji, ktry omija przyjt polityk bezpieczestwa aplikacji. Nie myli z programami zoliwymi (malware), takimi jak wirus czy robak! Komponent aplikacji pojedynczy lub grupa plikw rdowych, bibliotek i/lub plikw wykonywalnych, zdefiniowane dla danej aplikacji przez weryfikujcego. Konfiguracja zabezpiecze konfiguracja uruchomieniowa aplikacji wpywajca na sposb uycia mechanizmw bezpieczestwa. Mechanizm bezpieczestwa funkcja lub komponent dokonujcy sprawdzenia bezpieczestwa (np. kontroli dostpu) lub w przypadku wywoania wpywajca na dziaanie zabezpiecze (np. generowanie wpisu audytowego). Modelowanie zagroe technika polegajca na tworzeniu coraz bardziej wyrafinowanych architektur bezpieczestwa w celu identyfikacji czynnikw stwarzajcych zagroenia, stref bezpieczestwa, mechanizmw bezpieczestwa oraz wanych aktyww technicznych i biznesowych.
Strona 40
ASVS 2009
Modu kryptograficzny sprzt, oprogramowanie i/lub firmware implementujce algorytmy kryptograficzne i/lub generujce klucze kryptograficzne. Open Web Application Security Project (OWASP) Open Web Application Security Project (OWASP) jest darmow i otwart spoecznoci o zasigu wiatowym, skupion na poprawie bezpieczestwa aplikacji. Nasz misj jest sprawianie, e bezpieczestwo aplikacji jest widoczne tak, aby ludzie i organizacje mogy podejmowa wiadome decyzje odnonie ryzyk zwizanych z bezpieczestwem aplikacji. Zobacz http://www.owasp.org/ OWASP Enterprise Security API (ESAPI) darmowa i otwarta kolekcja wszystkich metod bezpieczestwa potrzebnych developerom do tworzenia bezpiecznych aplikacji Web. Zobacz http://www.owasp.org/index.php/ESAPI OWASP Testing Guide dokument majcy na celu pomc organizacjom zrozumie, z czego skada si program testowania oraz pomc im ustali kroki potrzebne do stworzenia i uruchomienia tego programu testw. Zobacz http://www.owasp.org/index.php/Category:OWASP_Testing_Project OWASP Top Ten dokument reprezentujcy szeroki konsensus w kwestii najbardziej krytycznych bdw bezpieczestwa aplikacji. Zobacz http://www.owasp.org/index.php/Top10 OWASP Risk Rating Methodology metodyka oceny ryzyka dostosowana do bezpieczestwa aplikacji. Zobacz http://www.owasp.org/index.php/How_to_value_the_real_risk Pozytywny patrz biaa lista. Program zoliwy kod uruchamialny wczony do aplikacji podczas jej pracy bez wiedzy uytkownika aplikacji lub administratora. Raport z weryfikacji bezpieczestwa aplikacji raport napisany dla danej aplikacji przez weryfikujcego, dokumentujcy caociowe wyniki i wspomagajce je badania. System zewntrzny aplikacja serwerowa lub usuga, ktre nie s czci aplikacji. Tylne wejcia rodzaj zoliwego kodu umoliwiajcego nieuprawniony dostp do aplikacji. Uwierzytelnienie weryfikacja tosamoci deklarowanej przez uytkownika aplikacji. Walidacja wejcia normalizacja i walidacja niezaufanych danych wejciowych uytkownika. Walidacja wyjcia normalizacja i walidacja danych wyjciowych z aplikacji do przegldarek Web i systemw zewntrznych. Weryfikacja automatyczna uycie automatycznych narzdzi (narzdzi do analizy dynamicznej, analizy statycznej lub obu typw) wykorzystujcych wzorce podatnoci do wyszukiwania problemw. Weryfikacja bezpieczestwa aplikacji techniczna ocena zgodnoci aplikacji z OWASP ASVS Weryfikacja dynamiczna - uycie automatycznych narzdzi wykorzystujcych wzorce podatnoci do zlokalizowania problemw podczas pracy aplikacji. Weryfikacja projektu techniczna ocena architektury bezpieczestwa aplikacji. Weryfikacja statyczna uycie automatycznych narzdzi wykorzystujcych wzorce podatnoci do zlokalizowania problemw w kodzie rdowym aplikacji. Weryfikacja wewntrzna techniczna ocena specyficznych aspektw architektury bezpieczestwa aplikacji zgodnie z OWASP ASVS. Weryfikujcy osoba lub zesp wykonujcy przegld zgodnoci aplikacji z wymaganiami OWASP ASVS.
Strona 41
ASVS 2009
Gdzie jeszcze moesz si uda?

OWASP jest gwn stron dotyczc bezpieczestwa aplikacji Web. Na stronach OWASP znajduje si wiele projektw, for, blogw, prezentacji, narzdzi i dokumentw. Dodatkowo OWASP jest organizatorem dwch w roku gwnych konferencji dotyczcych bezpieczestwa aplikacji Web i posiada 80 lokalnych oddziaw. Stron projektu OWASP ASVS moesz znale: http://www.owasp.org/index.php/ASVS Nastpujce projekty OWASP najprawdopodobniej bd uyteczne dla uytkownikw niniejszego standardu: OWASP Top Ten Project - http://www.owasp.org/index.php/Top_10 OWASP Code Review Guide http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Testing Guide - http://www.owasp.org/index.php/Testing_Guide OWASP Enterprise Security API (ESAPI) Project - http://www.owasp.org/index.php/ESAPI OWASP Legal Project - http://www.owasp.org/index.php/Category:OWASP_Legal_Project
Podobnie nastpujce strony Web najprawdopodobniej bd uyteczne dla uytkownikw niniejszego standardu: OWASP - http://www.owasp.org MITRE - Common Weakness Enumeration Trendy podatnoci, PCI Security Standards Council - wydawcy standardw PCI, odpowiednich dla wszystkich organizacji przetwarzajcych lub przechowujcych dane kart kredytowych, https://www.pcisecuritystandards.org PCI Data Security Standard (DSS) v1.1 https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf
Strona 42
ASVS 2009
Strona 43

Asvs Webapp Release 2009 PL

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Asvs Webapp Release 2009 PL

Uploaded by

Copyright:

Available Formats

wwwused everywhere

Standard Aplikacji Web

Prawa Autorskie I Licencja

Standard Aplikacji Web

Standard Aplikacji Web

Standard Aplikacji Web

Standard Aplikacji Web

Standard Aplikacji Web

Rysunek 2 Jeden ze sposobw wprowadzenia weryfikacji, jako czynnoci w Twoim SDLC6

Standard Aplikacji Web

Tumaczenie: Tomasz Polaski (jmsblond@gmail.com) Przegld i korekta: dr in. Mariusz Stawowski

Email: mike.boberski@owasp.org Email: jeff.williams@owasp.org, dave.wichers@owasp.org

Standard Aplikacji Web

Poziomy weryfikacji acji bezpieczestwa a aplikacji

Poziom 1 Weryfikacja automatyczna a

Standard Aplikacji Web

Rysunek 3 Poziomy 1, 1A i 1B OWASP ASVS

Standard Aplikacji Web

Rysunek 4 Przykad architektury bezpieczestwa dla poziomu 1 OWASP ASVS

Standard Aplikacji Web

Poziom 1B Skanowanie kodu rdowego (czciowa weryfikacja automatyczna)

Poziom 2 Weryfikacja rczna

Standard Aplikacji Web

Standard Aplikacji Web

Standard Aplikacji Web

Aplikacja Web bdca celem weryfikacji

Kontroler Funkcje biznesowe Warstwa prezentacji Warstwa danych

wywoania Frameworki Biblioteki Serwer aplikacyjny Serwer WWW Baza Danych

Rysunek 6 Przykad architektury bezpieczestwa dla poziomu 2 OWASP ASVS

Standard Aplikacji Web

Poziom 2A Test bezpieczestwa (czciowa weryfikacja rczna)

Poziom 2B Przegld kodu (czciowa weryfikacja rczna)

Poziom 3 Weryfikacja projektu

Standard Aplikacji Web

Standard Aplikacji Web

Rysunek 8 Przykad architektury bezpieczestwa dla poziomu 3 OWASP ASVS12

Znaki dolara na diagramie oznaczaj aktywa.

Standard Aplikacji Web

Poziom 4 Weryfikacja wewntrzna

Rysunek 9 Poziom 4 OWASP ASVS

Standard Aplikacji Web

Standard Aplikacji Web

Rysunek 10 Przykad niezbadanego kodu na poziomie 4 OWASP ASVS

Interpretacje wymaga i precedensy

Standard Aplikacji Web

Szczegowe wymagania weryfikacyjne

Standard Aplikacji Web

V1 Wymagania dotyczce dokumentacji architektury bezpieczestwa

Standard Aplikacji Web

Zweryfikuj czy s dostpne informacje wynikajce z modelowania zagroe.

Standard Aplikacji Web

V2 Wymagania weryfikacyjne dotyczce uwierzytelniania

Standard Aplikacji Web

V3 Wymagania weryfikacyjne dotyczce zarzdzania sesj

Tabela 3 Wymagania dotyczce zarzdzania sesj w OWASP ASVS (V3)

Standard Aplikacji Web

V3.2 V3.3 V3.4

Standard Aplikacji Web

V4 Wymagania weryfikacyjne dotyczce kontroli dostpu

Standard Aplikacji Web

Standard Aplikacji Web

V5 Wymagania weryfikacyjne dotyczce walidacji wejcia

Standard Aplikacji Web