OWASP czyli Open Web Security Project jest charytatywną organizacją non-profit skupiającą się na poprawie bezpieczeństwa oprogramowania i aplikacji internetowych.
Organizacja publikuje listę największych luk w bezpieczeństwie sieci na podstawie danych z różnych organizacji zajmujących się bezpieczeństwem.
Błędy w bezpieczeństwie sieci są uszeregowane pod względem możliwości ich wykorzystania, wykrywalności oraz wpływu na oprogramowanie.
- Wykorzystywalność –
Co jest potrzebne do wykorzystania luki w bezpieczeństwie? Najwyższa wykrywalność jest wtedy, gdy do ataku potrzebna jest tylko przeglądarka internetowa, najniższa, gdy potrzebne jest zaawansowane programowanie i narzędzia.
- Wykrywalność –
Jak łatwo jest wykryć zagrożenie? Najwyższą jest informacja wyświetlana na URL, formularzu lub komunikacie o błędzie, a najniższą kod źródłowy.
- Wpływ lub Szkody –
Jak duże szkody zostaną wyrządzone, jeśli luka bezpieczeństwa zostanie ujawniona lub zaatakowana? Najwyższy to całkowity rozpad systemu, a najniższy to nic.
Głównym celem OWASP Top 10 jest edukacja programistów, projektantów, menedżerów, architektów i organizacji na temat najważniejszych luk w zabezpieczeniach.
10 najważniejszych luk w zabezpieczeniach według OWASP Top 10 to:
- Wstrzyknięcie bazy danych
- Cross Site Scripting
- Błędne uwierzytelnianie i zarządzanie sesją
- Niezabezpieczone bezpośrednie odwołania do obiektów
- Cross Site Request Forgery
- Błędna konfiguracja zabezpieczeń
- Niezabezpieczone przechowywanie kryptograficzne
- Nieumiejętność ograniczenia dostępu do adresów URL
- Niewystarczająca Transport Layer Protection
- Unvalidated Redirects and Forwards
SQL Injection
Opis
Wstrzyknięcie jest luką w zabezpieczeniach, która pozwala atakującemu na zmianę instrukcji SQL poprzez manipulowanie danymi dostarczonymi przez użytkownika.
Wstrzyknięcie występuje wtedy, gdy dane wejściowe użytkownika są wysyłane do interpretera jako część polecenia lub zapytania i podstępnie zmuszają interpreter do wykonania niezamierzonych poleceń i dają dostęp do nieautoryzowanych danych.
Komenda SQL, która po wykonaniu przez aplikację webową może również odsłonić bazę danych back-end.
Impliakcja
- Atakujący może wstrzyknąć złośliwą treść do podatnych pól.
- Wrażliwe dane, takie jak nazwy użytkowników, hasła, itp. mogą zostać odczytane z bazy danych.
- Dane bazy danych mogą zostać zmodyfikowane (Insert/Update/ Delete).
- Operacje administracyjne mogą być wykonywane na bazie danych
Obiekty podatne na ataki
- Pola wejściowe
- URL wchodzące w interakcję z bazą danych.
Przykłady:
- Wstrzyknięcie bazy danych na stronie logowania
Zalogowanie się do aplikacji bez posiadania ważnych danych uwierzytelniających.
Prawidłowa nazwa użytkownika jest dostępna, natomiast hasło nie jest dostępne.
Testowy URL: http://demo.testfire.net/default.aspx
Nazwa użytkownika: sjones
Hasło: 1=1′ lub pass123
KwerendaSQL utworzona i wysłana do Interpretera jak poniżej
SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1′ lub pass123;
Zalecenia
- Wybielanie pól wejściowych
- Unikaj wyświetlania szczegółowych komunikatów o błędach, które są przydatne dla atakującego.
Cross Site Scripting
Opis
Cross Site Scripting jest również krótko znany jako XSS.
Błędy XSS są ukierunkowane na skrypty osadzone na stronie, które są wykonywane po stronie klienta, tj. przeglądarki użytkownika, a nie po stronie serwera. Błędy te mogą wystąpić, gdy aplikacja pobiera niezaufane dane i wysyła je do przeglądarki bez odpowiedniej walidacji.
Atakujący mogą wykorzystać XSS do wykonania złośliwych skryptów na użytkownikach, w tym przypadku na przeglądarkach ofiar. Ponieważ przeglądarka nie może wiedzieć, czy skrypt jest wiarygodny czy nie, zostanie on wykonany, a atakujący może porwać ciasteczka sesji, zniszczyć strony internetowe lub przekierować użytkownika na niechciane i złośliwe strony.
XSS jest atakiem, który pozwala atakującemu na wykonanie skryptów w przeglądarce ofiary.
Impliakcja:
- Wykorzystując tę lukę w zabezpieczeniach, atakujący może wstrzykiwać skrypty do aplikacji, może wykradać ciasteczka sesyjne, defragmentować strony internetowe oraz uruchamiać złośliwe oprogramowanie na maszynach ofiary.
Obiekty podatne na atak
- Pola wejściowe
- URL
Przykłady
1. http://www.vulnerablesite.com/home?”<script>alert(„xss”)</script>
Powyższy skrypt po uruchomieniu w przeglądarce wyświetli okno z komunikatem, że strona jest podatna na XSS.
Poważniejszy atak może zostać przeprowadzony, jeżeli atakujący będzie chciał wyświetlić lub przechować ciasteczko sesyjne.
2. http://demo.testfire.net/search.aspx?txtSearch<iframe><src = http://google.com width = 500 height 500></iframe>
Powyższy skrypt po uruchomieniu, przeglądarka załaduje niewidoczną ramkę wskazującą na http://google.com.
Atak można uczynić poważnym poprzez uruchomienie złośliwego skryptu w przeglądarce.
Zalecenia
- White Listing pól wejściowych
- Kodowanie wyjścia wejściowego
Złamane uwierzytelnianie i zarządzanie sesją
Opis
Strony internetowe zazwyczaj tworzą ciasteczko sesji i identyfikator sesji dla każdej ważnej sesji, i te pliki cookie zawierają poufne dane, takie jak nazwa użytkownika, hasło itp. Kiedy sesja zostaje zakończona przez wylogowanie lub nagłe zamknięcie przeglądarki, ciasteczka te powinny zostać unieważnione, tzn. dla każdej sesji powinno zostać utworzone nowe ciasteczko.
Jeżeli ciasteczka nie zostaną unieważnione, wrażliwe dane będą istniały w systemie. Na przykład, gdy użytkownik korzysta z publicznego komputera (Cyber Cafe), pliki cookie z zagrożonej strony znajdują się w systemie i są narażone na atak. Atakujący korzysta z tego samego publicznego komputera po pewnym czasie, wrażliwe dane są zagrożone.
W ten sam sposób, użytkownik korzystający z publicznego komputera, zamiast wylogować się, gwałtownie zamyka przeglądarkę. Atakujący korzysta z tego samego systemu, gdy przegląda tę samą podatną na ataki stronę, poprzednia sesja ofiary zostanie otwarta. Atakujący może zrobić wszystko, co zechce, począwszy od kradzieży informacji o profilu, danych karty kredytowej itp.
Należy sprawdzić siłę uwierzytelniania i zarządzania sesją. Klucze, tokeny sesyjne, ciasteczka powinny być odpowiednio zaimplementowane, bez naruszania haseł.
Podatne obiekty
- Identyfikatory sesji wystawione na URL mogą prowadzić do ataku typu session fixation.
- Identyfikatory sesji takie same przed i po wylogowaniu i zalogowaniu.
- Czas trwania sesji nie jest poprawnie zaimplementowany.
- Aplikacja przypisuje ten sam identyfikator sesji dla każdej nowej sesji.
- Autoryzowane części aplikacji są chronione za pomocą SSL, a hasła są przechowywane w formacie hashowanym lub zaszyfrowanym.
- Sesja może być ponownie użyta przez użytkownika o niskich uprawnieniach.
Impliakcja
- Wykorzystując tę lukę, atakujący może porwać sesję, uzyskać nieautoryzowany dostęp do systemu, co pozwala na ujawnienie i modyfikację nieautoryzowanych informacji.
- Sesje mogą zostać przechwycone przy użyciu skradzionych ciasteczek lub sesji wykorzystujących XSS.
Przykłady
- Aplikacja do rezerwacji biletów lotniczych obsługuje przepisywanie adresów URL, umieszczając identyfikatory sesji w adresie URL:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Sprzedaż biletów na Malediwy)
Uwierzytelniony użytkownik witryny chce powiadomić swoich znajomych o sprzedaży i wysyła wiadomość e-mail w poprzek. Znajomi otrzymują identyfikator sesji, który może zostać wykorzystany do nieautoryzowanych modyfikacji lub nadużycia zapisanych danych karty kredytowej.
- Aplikacja jest podatna na XSS, za pomocą którego atakujący może uzyskać dostęp do identyfikatora sesji i wykorzystać go do porwania sesji.
- Aplikacje nie mają prawidłowo ustawionych limitów czasu. Użytkownik korzysta z publicznego komputera, zamyka przeglądarkę zamiast się wylogować i odchodzi. Atakujący korzysta z tej samej przeglądarki jakiś czas później, a sesja zostaje uwierzytelniona.
Zalecenia
- Wszystkie wymagania dotyczące uwierzytelniania i zarządzania sesją powinny być zdefiniowane zgodnie ze standardem OWASP Application Security Verification Standard.
- Nigdy nie należy ujawniać żadnych danych uwierzytelniających w adresach URL lub logach.
- Należy również dołożyć wszelkich starań, aby uniknąć błędów XSS, które mogą zostać wykorzystane do kradzieży identyfikatorów sesji.
Niezabezpieczone bezpośrednie odniesienia do obiektów
Opis
Pojawiają się one, gdy programista eksponuje odniesienie do wewnętrznego obiektu implementacji, takiego jak plik, katalog lub klucz bazy danych w adresie URL lub jako parametr FORM. Atakujący może użyć tej informacji do uzyskania dostępu do innych obiektów i może stworzyć przyszły atak w celu uzyskania dostępu do nieautoryzowanych danych.
Impliakcja
- Używając tej luki, atakujący może uzyskać dostęp do nieautoryzowanych obiektów wewnętrznych, może modyfikować dane lub skompromitować aplikację.
Obiekty podatne na atak
- W adresie URL.
Przykłady:
Zmiana „userid” w poniższym adresie URL może sprawić, że atakujący będzie mógł zobaczyć informacje o innych użytkownikach.
http://www.vulnerablesite.com/userid=123 Zmodyfikowano do http://www.vulnerablesite.com/userid=124
Atakujący może przeglądać informacje o innych użytkownikach poprzez zmianę wartości identyfikatora użytkownika.
Rekomendacje:
- Wdrożenie kontroli dostępu.
- Unikanie eksponowania referencji obiektów w adresach URL.
- Weryfikacja autoryzacji do wszystkich obiektów referencyjnych.
Cross Site Request Forgery
Opis
Cross Site Request Forgery to sfałszowane żądanie pochodzące z witryny poprzecznej.
Atak CSRF to atak, który występuje, gdy złośliwa witryna, e-mail lub program powoduje, że przeglądarka użytkownika wykonuje niechciane działanie na zaufanej witrynie, dla której użytkownik jest aktualnie uwierzytelniony.
Atak CSRF zmusza zalogowaną przeglądarkę ofiary do wysłania fałszywego żądania HTTP, zawierającego ciasteczko sesyjne ofiary oraz wszelkie inne automatycznie dołączone informacje uwierzytelniające, do podatnej aplikacji internetowej.
Ofiara otrzyma link, który zostanie wysłany przez atakującego do ofiary, gdy użytkownik kliknie na ten adres URL będąc zalogowanym na oryginalnej witrynie, dane zostaną skradzione z witryny.
Impliakcja
- Używając tej luki jako atakujący może zmienić informacje w profilu użytkownika, zmienić status, stworzyć nowego użytkownika w imieniu administratora, itp.
Podlegające atakowi obiekty
- Strona profilu użytkownika
- Formularze konta użytkownika
- Strona transakcji biznesowych
Przykłady
Ofiara jest zalogowana na stronie banku używając ważnych danych uwierzytelniających. Otrzymuje maila od atakującego o treści „Please click here to donate $1 to cause”.
Kiedy ofiara kliknie na niego, zostanie utworzona ważna prośba o przekazanie 1$ na konkretne konto.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
Atakujący przechwytuje to żądanie i tworzy poniższe żądanie i osadza je w przycisku z napisem „Wspieram Przyczynę”.
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Ponieważ sesja jest uwierzytelniona, a żądanie przychodzi przez stronę banku, serwer przekazałby 1000 dolarów do atakującego.
Zalecenia
- Wymagaj obecności użytkownika podczas wykonywania wrażliwych akcji.
- Wdrożenie mechanizmów takich jak , Ponowne uwierzytelnianie oraz Unikalne Tokeny Żądań.
Błędna konfiguracja bezpieczeństwa
Opis
Konfiguracja bezpieczeństwa musi być zdefiniowana i wdrożona dla aplikacji, frameworków, serwera aplikacji, serwera WWW, serwera bazy danych i platformy. Jeśli są one prawidłowo skonfigurowane, atakujący może uzyskać nieautoryzowany dostęp do wrażliwych danych lub funkcjonalności.
Niekiedy takie błędy prowadzą do całkowitej kompromitacji systemu. Dbanie o aktualność oprogramowania to również dobre zabezpieczenie.
Impliakcja
- Wykorzystując tę lukę, atakujący może wyliczyć bazę danych technologii i wersji serwera aplikacji, informacje o bazie danych oraz zdobyć informacje o aplikacji w celu przeprowadzenia kilku kolejnych ataków.
Podlegające atakowi obiekty
- URL
- Pola formularza
- Pola wejściowe
Przykłady
- Konsola administracyjna serwera aplikacji jest automatycznie instalowana i nie jest usuwana. Domyślne konta nie są zmieniane. Atakujący może zalogować się przy użyciu domyślnych haseł i uzyskać nieautoryzowany dostęp.
- Directory Listing nie jest wyłączony na serwerze. Atakujący odkrywa i może po prostu wylistować katalogi, aby znaleźć dowolny plik.
Zalecenia
- Silna architektura aplikacji, która zapewnia dobrą separację i bezpieczeństwo pomiędzy komponentami.
- Zmień domyślne nazwy użytkowników i hasła.
- Wyłączenie list katalogów i wdrożenie kontroli dostępu.
Niezabezpieczone przechowywanie kryptograficzne
Opis
Niezabezpieczone przechowywanie kryptograficzne jest powszechną podatnością, która występuje, gdy wrażliwe dane nie są przechowywane w bezpieczny sposób.
Poświadczenia użytkownika, informacje o profilu, szczegóły dotyczące zdrowia, informacje o kartach kredytowych, itp. należą do wrażliwych danych na stronie internetowej.
Dane te będą przechowywane w bazie danych aplikacji. Jeśli dane te są przechowywane w niewłaściwy sposób, bez użycia szyfrowania lub haszowania*, będą one podatne na ataki.
(*Hashing to przekształcanie ciągów znaków w krótsze ciągi o ustalonej długości lub klucz. Aby odszyfrować ciąg znaków, algorytm użyty do utworzenia klucza powinien być dostępny)
Impliakcja
- Wykorzystując tę lukę, atakujący może wykraść, zmodyfikować tak słabo chronione dane w celu dokonania kradzieży tożsamości, wyłudzenia karty kredytowej lub innych przestępstw.
Podlegające atakowi obiekty
- Baza danych aplikacji.
Przykłady
W jednej z aplikacji bankowych, baza danych haseł używa niesalowanych haseł * do przechowywania haseł wszystkich użytkowników. Błąd SQL injection pozwala atakującemu na odzyskanie pliku z hasłami. Wszystkie niesolone hasze mogą zostać sforsowane w mgnieniu oka, podczas gdy zasolone hasła zajęłyby tysiące lat.
(* Niesolone Hasła – Sól jest losową daną dodawaną do oryginalnych danych. Sól jest dodawana do hasła przed haszowaniem)
Zalecenia
- Zapewnij odpowiednie silne standardowe algorytmy. Nie należy tworzyć własnych algorytmów kryptograficznych. Używaj tylko zatwierdzonych publicznych algorytmów, takich jak AES, RSA, SHA-256 itp.
- Zapewnij, że kopie zapasowe poza siedzibą firmy są szyfrowane, ale klucze są zarządzane i archiwizowane oddzielnie.
Nieograniczenie dostępu do URL
Opis
Aplikacje internetowe sprawdzają prawa dostępu do URL przed wyświetleniem chronionych linków i przycisków. Aplikacje muszą przeprowadzać podobne kontrole dostępu za każdym razem, gdy strony te są otwierane.
W większości aplikacji, uprzywilejowane strony, lokalizacje i zasoby nie są prezentowane uprzywilejowanym użytkownikom.
Dzięki inteligentnemu zgadywaniu, atakujący może uzyskać dostęp do stron uprzywilejowanych. Atakujący może uzyskać dostęp do wrażliwych stron, wywoływać funkcje i przeglądać poufne informacje.
Impliakcja
- Przy wykorzystaniu tej luki atakujący może uzyskać dostęp do nieautoryzowanych adresów URL, bez logowania się do aplikacji i wykorzystać lukę. Napastnik może uzyskać dostęp do wrażliwych stron, wywoływać funkcje i przeglądać poufne informacje.
Podlegające podatności obiekty:
- URLs
Przykłady
- Atakujący zauważa, że URL wskazuje rolę jako „/user/getaccounts”. Modyfikuje jako „/admin/getaccounts”.
- Atakujący może dodać rolę do adresu URL.
http://www.vulnerablsite.com może być zmodyfikowany jako http://www.vulnerablesite.com/admin
Zalecenia
- Wdrożenie silnych kontroli dostępu.
- Polityki uwierzytelniania i autoryzacji powinny być oparte na rolach.
- Ograniczyć dostęp do niepożądanych adresów URL.
Niewystarczająca ochrona warstwy transportowej
Opis
Zajmuje się wymianą informacji pomiędzy użytkownikiem (klientem) a serwerem (aplikacją). Aplikacje często przesyłają przez sieć wrażliwe informacje, takie jak dane uwierzytelniające, informacje o kartach kredytowych i tokeny sesji.
Dzięki zastosowaniu słabych algorytmów, wykorzystaniu wygasłych lub nieważnych certyfikatów lub niewykorzystaniu protokołu SSL komunikacja może być narażona na kontakt z niezaufanymi użytkownikami, którzy mogą narazić na szwank aplikację internetową lub wykraść poufne informacje.
Impliakcja
- Wykorzystując tę lukę w zabezpieczeniach sieciowych, osoba atakująca może wyłudzić dane uwierzytelniające legalnego użytkownika i uzyskać dostęp do aplikacji.
- Może ukraść informacje o kartach kredytowych.
Podatne obiekty
- Dane przesyłane przez sieć.
Zalecenia
- Włącz bezpieczny HTTP i wymuszaj przesyłanie danych uwierzytelniających wyłącznie przez HTTPS.
- Upewnij się, że Twój certyfikat jest ważny i nie wygasł.
Przykłady:
1. Aplikacja nie korzystająca z SSL, atakujący po prostu monitoruje ruch sieciowy i zauważa uwierzytelnione ciasteczko sesji ofiary. Napastnik może wykraść to ciasteczko i przeprowadzić atak Man-in-the-Middle.
Niezatwierdzone przekierowania i przekierowania
Opis
Aplikacja webowa używa kilku metod do przekierowania i przekierowania użytkowników na inne strony w zamierzonym celu.
Jeśli nie ma odpowiedniej walidacji podczas przekierowywania na inne strony, atakujący mogą to wykorzystać i przekierować ofiary na strony phishingowe lub złośliwe oprogramowanie, lub użyć przekierowań, aby uzyskać dostęp do nieautoryzowanych stron.
Impliakcja
- Atakujący może wysłać do użytkownika adres URL, który zawiera prawdziwy adres URL z zakodowanym złośliwym adresem URL. Użytkownik widząc tylko prawdziwą część wysłanego przez atakującego adresu URL może go przeglądać i stać się ofiarą.
Przykłady
1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Zmodyfikowano do
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Zalecenia
- Po prostu unikaj używania przekierowań i forwardów w aplikacji. Jeśli są używane, nie należy używać parametrów użytkownika do obliczania miejsca docelowego.
- Jeśli nie można uniknąć parametrów miejsca docelowego, należy upewnić się, że dostarczona wartość jest ważna i autoryzowana dla użytkownika.
Ten artykuł został napisany przez Prasanthi Eati