OWASP lub Open Web Security Project to organizacja charytatywna non-profit skupiona na poprawie bezpieczeństwa oprogramowania i aplikacji internetowych.
Organizacja publikuje listę najważniejszych luk w zabezpieczeniach sieci w oparciu o dane z różnych organizacji zajmujących się bezpieczeństwem.
Luki w zabezpieczeniach sieci są traktowane priorytetowo w zależności od możliwości wykorzystania, wykrywalności i wpływu na oprogramowanie.
- Możliwość wykorzystania -
Co jest potrzebne, aby wykorzystać lukę w zabezpieczeniach? Najwyższe możliwości wykorzystania, gdy atak wymaga tylko przeglądarki internetowej, a najniższe to zaawansowane oprogramowanie i narzędzia.
- Wykrywalność -
Jak łatwo jest wykryć zagrożenie? Najwyższa to informacja wyświetlana w adresie URL, formularzu lub komunikacie o błędzie, a najniższa to kod źródłowy.
- Uderzenie lub uszkodzenie -
Ile szkód zostanie wyrządzonych, jeśli luka w zabezpieczeniach zostanie ujawniona lub zaatakowana? Najwyższa oznacza kompletną awarię systemu, a najniższa to nic.
Głównym celem OWASP Top 10 jest edukacja deweloperów, projektantów, menedżerów, architektów i organizacji w zakresie najważniejszych luk w zabezpieczeniach.
Top 10 luk w zabezpieczeniach według OWASP Top 10 to:
- Wstrzyknięcie SQL
- Skrypty między witrynami
- Uszkodzone uwierzytelnianie i zarządzanie sesjami
- Niezabezpieczone bezpośrednie odwołania do obiektów
- Fałszerstwo żądań między lokacjami
- Błędna konfiguracja zabezpieczeń
- Niezabezpieczona pamięć kryptograficzna
- Brak ograniczenia dostępu do adresu URL
- Niewystarczająca ochrona warstwy transportowej
- Niezatwierdzone przekierowania i przekierowania
Wstrzyknięcie SQL
Opis
Wstrzyknięcie to luka w zabezpieczeniach, która umożliwia osobie atakującej zmianę instrukcji SQL zaplecza poprzez manipulowanie danymi dostarczonymi przez użytkownika.
Wstrzyknięcie ma miejsce, gdy dane wprowadzane przez użytkownika są wysyłane do tłumacza jako część polecenia lub zapytania i nakłaniają tłumacza do wykonania niezamierzonych poleceń i dają dostęp do nieautoryzowanych danych.
Polecenie SQL, które po wykonaniu przez aplikację internetową może również ujawnić wewnętrzną bazę danych.
Implikacja
- Osoba atakująca może wstrzyknąć złośliwą zawartość w podatne pola.
- Wrażliwe dane, takie jak nazwy użytkowników, hasła itp., Można odczytać z bazy danych.
- Dane bazy danych można modyfikować (Wstaw / Aktualizuj / Usuń).
- Operacje administracyjne mogą być wykonywane na bazie danych
Obiekty wrażliwe
- Pola wejściowe
- Adresy URL współdziałające z bazą danych.
Przykłady:
- Wstrzyknięcie SQL na stronie logowania
Logowanie do aplikacji bez ważnych poświadczeń.
Prawidłowa nazwa użytkownika jest dostępna, a hasło nie jest dostępne.
Testowy adres URL: http://demo.testfire.net/default.aspx
Nazwa użytkownika: sjones
Hasło: 1 = 1 'lub pass123
Zapytanie SQL zostało utworzone i wysłane do Interpretera, jak poniżej
SELECT * FROM Users WHERE User_Name = sjones AND Password = 1 = 1 'lub pass123;
Zalecenia
- Biała lista pól wejściowych
- Unikaj wyświetlania szczegółowych komunikatów o błędach, które są przydatne dla atakującego.
Skrypty między witrynami
Opis
Cross Site Scripting jest również krótko znany jako XSS.
Luki XSS dotyczą skryptów osadzonych na stronie, które są wykonywane po stronie klienta, tj. Przeglądarki użytkownika, a nie po stronie serwera. Te wady mogą wystąpić, gdy aplikacja pobiera niezaufane dane i wysyła je do przeglądarki internetowej bez odpowiedniej weryfikacji.
Atakujący mogą używać XSS do wykonywania złośliwych skryptów na użytkownikach, w tym przypadku w przeglądarkach ofiar. Ponieważ przeglądarka nie może wiedzieć, czy skrypt jest wiarygodny, czy nie, skrypt zostanie wykonany, a osoba atakująca może przejąć sesyjne pliki cookie, zniszczyć witryny internetowe lub przekierować użytkownika na niechciane i złośliwe witryny.
XSS to atak, który umożliwia atakującemu wykonanie skryptów w przeglądarce ofiary.
Implikacja:
- Korzystając z tej luki w zabezpieczeniach, osoba atakująca może wstrzyknąć skrypty do aplikacji, kraść sesyjne pliki cookie, niszczyć witryny internetowe i uruchamiać złośliwe oprogramowanie na komputerach ofiary.
Obiekty wrażliwe
- Pola wejściowe
- Adresy URL
Przykłady
1. http://www.vulnerablesite.com/home?" < script > alert("xss") script >
Powyższy skrypt po uruchomieniu w przeglądarce zostanie wyświetlony komunikat, jeśli witryna jest podatna na XSS.
Bardziej poważny atak można przeprowadzić, jeśli osoba atakująca chce wyświetlić lub przechowywać plik cookie sesji.
2. http://demo.testfire.net/search.aspx?txtSearch
Powyższy skrypt po uruchomieniu przeglądarka załaduje niewidoczną ramkę wskazującą na http://google.com .
Atak można uczynić poważnym, uruchamiając złośliwy skrypt w przeglądarce.
Zalecenia
- Pola wejściowe na białej liście
- Kodowanie danych wejściowych i wyjściowych
Uszkodzone uwierzytelnianie i zarządzanie sesjami
Opis
Strony internetowe zwykle tworzą sesyjny plik cookie i identyfikator sesji dla każdej ważnej sesji, a te pliki cookie zawierają poufne dane, takie jak nazwa użytkownika, hasło itp. Po zakończeniu sesji przez wylogowanie lub nagłe zamknięcie przeglądarki, te pliki cookie należy unieważnić, tj. Dla każdej sesji powinien być nowy plik cookie.
Jeśli pliki cookie nie zostaną unieważnione, dane wrażliwe będą istniały w systemie. Na przykład użytkownik korzystający z komputera publicznego (Cyber Cafe), pliki cookie z podatnej strony znajdują się w systemie i są narażone na atak. Osoba atakująca po pewnym czasie korzysta z tego samego publicznego komputera, poufne dane zostają przejęte.
W ten sam sposób użytkownik korzystający z publicznego komputera zamiast się wylogować, gwałtownie zamyka przeglądarkę. Atakujący korzysta z tego samego systemu, kiedy przegląda tę samą podatną stronę, zostanie otwarta poprzednia sesja ofiary. Atakujący może zrobić, co tylko zechce, od kradzieży informacji profilowych, danych karty kredytowej itp.
Należy sprawdzić siłę uwierzytelniania i zarządzania sesją. Klucze, tokeny sesji, pliki cookie powinny być wdrażane prawidłowo, bez naruszania haseł.
Obiekty wrażliwe
- Identyfikatory sesji ujawnione w adresie URL mogą prowadzić do ataku polegającego na utrwalaniu sesji.
- Identyfikatory sesji takie same przed i po wylogowaniu i zalogowaniu.
- Limity czasu sesji nie są poprawnie zaimplementowane.
- Aplikacja przypisuje ten sam identyfikator sesji do każdej nowej sesji.
- Uwierzytelnione części aplikacji są chronione za pomocą protokołu SSL, a hasła są przechowywane w postaci zaszyfrowanej lub zaszyfrowanej.
- Sesja może być ponownie wykorzystana przez użytkownika o niskich uprawnieniach.
Implikacja
- Korzystając z tej luki, osoba atakująca może przejąć sesję, uzyskać nieautoryzowany dostęp do systemu, który umożliwia ujawnienie i modyfikację nieautoryzowanych informacji.
- Sesje mogą być zabezpieczone za pomocą skradzionych plików cookie lub sesji za pomocą XSS.
Przykłady
- Aplikacja do rezerwacji linii lotniczych obsługuje przepisywanie adresów URL, umieszczanie identyfikatorów 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 e-mail. Znajomi otrzymują identyfikator sesji i mogą zostać wykorzystani do nieautoryzowanych modyfikacji lub niewłaściwego wykorzystania zapisanych danych karty kredytowej.
- Aplikacja jest podatna na XSS, dzięki któremu osoba atakująca może uzyskać dostęp do identyfikatora sesji i może zostać wykorzystana do przejęcia sesji.
- Limity czasu aplikacji nie są ustawione prawidłowo. Użytkownik korzysta z publicznego komputera i zamiast wylogowywać się, zamyka przeglądarkę i odchodzi. Atakujący używa tej samej przeglądarki jakiś czas później, a sesja jest uwierzytelniana.
Zalecenia
- Wszystkie wymagania dotyczące uwierzytelniania i zarządzania sesją powinny być zdefiniowane zgodnie ze standardem weryfikacji bezpieczeństwa aplikacji OWASP.
- Nigdy nie ujawniaj żadnych poświadczeń w adresach URL ani w dziennikach.
- Należy również dołożyć wszelkich starań, aby uniknąć błędów XSS, które można wykorzystać do kradzieży identyfikatorów sesji.
Niezabezpieczone bezpośrednie odwołania do obiektów
Opis
Występuje, gdy programista ujawnia odwołanie do wewnętrznego obiektu implementacji, takiego jak plik, katalog lub klucz bazy danych, jak w adresie URL lub jako parametr FORM. Osoba atakująca może wykorzystać te informacje, aby uzyskać dostęp do innych obiektów i może w przyszłości przeprowadzić atak, aby uzyskać dostęp do nieautoryzowanych danych.
Implikacja
- Korzystając z tej luki, osoba atakująca może uzyskać dostęp do nieautoryzowanych obiektów wewnętrznych, zmodyfikować dane lub złamać zabezpieczenia aplikacji.
Obiekty wrażliwe
- W adresie URL.
Przykłady:
Zmiana „identyfikatora użytkownika” w następującym adresie URL może spowodować, że osoba atakująca będzie przeglądać informacje innych użytkowników.
http://www.vulnerablesite.com/userid=123 Zmodyfikowano do http://www.vulnerablesite.com/userid=124
Osoba atakująca może przeglądać informacje innych osób, zmieniając wartość identyfikatora użytkownika.
Zalecenia:
- Wdrażaj kontrole dostępu.
- Unikaj ujawniania odniesień do obiektów w adresach URL.
- Sprawdź uprawnienia do wszystkich obiektów referencyjnych.
Fałszerstwo żądań między lokacjami
Opis
Fałszerstwo żądań między lokacjami to sfałszowane żądanie pochodzące z różnych witryn.
Atak CSRF to atak, który ma miejsce, gdy złośliwa witryna internetowa, e-mail lub program powodują, że przeglądarka użytkownika wykonuje niepożądane działanie w zaufanej witrynie, dla której użytkownik jest aktualnie uwierzytelniony.
Atak CSRF zmusza zalogowaną przeglądarkę ofiary do wysłania sfałszowanego żądania HTTP, w tym sesyjnego pliku cookie ofiary i wszelkich innych automatycznie dołączonych informacji uwierzytelniających, do podatnej na ataki aplikacji internetowej.
Osoba atakująca wyśle link do ofiary, gdy użytkownik kliknie na adres URL po zalogowaniu się na oryginalnej stronie internetowej, dane zostaną skradzione ze strony.
Implikacja
- Wykorzystanie tej luki jako osoby atakującej może zmienić informacje w profilu użytkownika, zmienić stan, utworzyć nowego użytkownika w imieniu administratora itp.
Obiekty wrażliwe
- Strona profilu użytkownika
- Formularze kont użytkowników
- Strona transakcji biznesowych
Przykłady
Ofiara jest logowana na stronie banku przy użyciu ważnych danych uwierzytelniających. Otrzymuje wiadomość od atakującego z informacją „Kliknij tutaj, aby przekazać 1 dolara na cel”.
Kiedy ofiara go kliknie, zostanie utworzona poprawna prośba o przekazanie 1 $ na określone konto.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
Osoba atakująca przechwytuje to żądanie i tworzy poniższe żądanie, a następnie umieszcza w przycisku „Popieram sprawę”.
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Ponieważ sesja jest uwierzytelniona, a żądanie przychodzi przez witrynę banku, serwer przesłałby atakującemu 1000 dolarów.
Rekomendacje
- Zezwól na obecność użytkownika podczas wykonywania wrażliwych działań.
- Wdrażaj mechanizmy, takie jak CAPTCHA, ponowne uwierzytelnienie i unikalne tokeny żądań.
Błędna konfiguracja zabezpieczeń
Opis
Konfiguracja zabezpieczeń musi zostać zdefiniowana i wdrożona dla aplikacji, struktur, serwera aplikacji, serwera WWW, serwera bazy danych i platformy. Jeśli są one prawidłowo skonfigurowane, osoba atakująca może uzyskać nieautoryzowany dostęp do poufnych danych lub funkcji.
Czasami takie wady skutkują całkowitym kompromitacją systemu. Aktualizowanie oprogramowania to również dobre zabezpieczenie.
Implikacja
- Korzystając z tej luki, osoba atakująca może wyliczyć informacje o podstawowej technologii i wersji serwera aplikacji, informacje z bazy danych oraz uzyskać informacje o aplikacji, aby przeprowadzić kilka kolejnych ataków.
Obiekty wrażliwe
- URL
- Pola formularza
- Pola wejściowe
Przykłady
- Konsola administracyjna serwera aplikacji jest instalowana automatycznie i nie jest usuwana. Konta domyślne nie są zmieniane. Osoba atakująca może zalogować się przy użyciu domyślnych haseł i uzyskać nieautoryzowany dostęp.
- Lista katalogów nie jest wyłączona na Twoim serwerze. Atakujący odkrywa i może po prostu wyświetlić listę katalogów, aby znaleźć dowolny plik.
Zalecenia
- Silna architektura aplikacji zapewniająca dobrą separację i bezpieczeństwo między komponentami.
- Zmień domyślne nazwy użytkowników i hasła.
- Wyłącz listy katalogów i zaimplementuj kontrolę dostępu.
Niezabezpieczona pamięć kryptograficzna
Opis
Niezabezpieczony magazyn kryptograficzny to powszechna luka w zabezpieczeniach, która występuje, gdy poufne dane nie są bezpiecznie przechowywane.
Poświadczenia użytkownika, informacje o profilu, szczegóły dotyczące zdrowia, informacje o karcie kredytowej itp. Są objęte poufnymi danymi na stronie internetowej.
Te dane będą przechowywane w bazie danych aplikacji. Gdy te dane są przechowywane w niewłaściwy sposób, bez użycia szyfrowania lub haszowania *, będą narażone na ataki.
(* Haszowanie to przekształcanie znaków ciągu w krótsze ciągi o stałej długości lub w klucz. Aby odszyfrować ciąg, powinien być dostępny algorytm użyty do utworzenia klucza)
Implikacja
- Korzystając z tej luki, osoba atakująca może kraść, modyfikować takie słabo chronione dane w celu kradzieży tożsamości, oszustw związanych z kartami kredytowymi lub innych przestępstw.
Obiekty wrażliwe
- Baza danych aplikacji.
Przykłady
W jednej z aplikacji bankowych baza danych haseł używa niesolonych skrótów * do przechowywania haseł wszystkich osób. Błąd iniekcji SQL umożliwia atakującemu odzyskanie pliku z hasłami. Wszystkie niesolone skróty mogą być brutalnie wymuszone w mgnieniu oka, podczas gdy solone hasła zajęłyby tysiące lat.
(* Niesolone skróty - sól to losowe dane dołączane do oryginalnych danych. Sól jest dodawana do hasła przed haszowaniem)
Zalecenia
- Zapewnij odpowiednie, silne standardowe algorytmy. Nie twórz własnych algorytmów kryptograficznych. Używaj tylko zatwierdzonych algorytmów publicznych, takich jak AES, kryptografia klucza publicznego RSA i SHA-256 itp.
- Upewnij się, że kopie zapasowe poza siedzibą firmy są szyfrowane, ale klucze są zarządzane i archiwizowane oddzielnie.
Brak ograniczenia dostępu do adresu URL
Opis
Aplikacje internetowe sprawdzają prawa dostępu do adresów URL przed renderowaniem chronionych łączy i przycisków. Aplikacje muszą przeprowadzać podobne kontrole dostępu za każdym razem, gdy uzyskuje się dostęp do tych stron.
W większości aplikacji uprzywilejowane strony, lokalizacje i zasoby nie są prezentowane uprzywilejowanym użytkownikom.
Dzięki inteligentnemu przypuszczeniu osoba atakująca może uzyskać dostęp do stron uprawnień. Osoba atakująca może uzyskać dostęp do wrażliwych stron, wywoływać funkcje i przeglądać poufne informacje.
Implikacja
- Korzystając z tej luki, osoba atakująca może uzyskać dostęp do nieautoryzowanych adresów URL bez logowania się do aplikacji i wykorzystać lukę. Osoba atakująca może uzyskać dostęp do wrażliwych stron, wywoływać funkcje i przeglądać poufne informacje.
Wrażliwe obiekty:
- Adresy URL
Przykłady
- Atakujący zauważa, że adres URL wskazuje rolę jako „/ user / getaccounts”. Modyfikuje się jako „/ admin / getaccounts”.
- Osoba atakująca może dołączyć rolę do adresu URL.
http://www.vulnerablsite.com można zmodyfikować jako http://www.vulnerablesite.com/admin
Zalecenia
- Wdrażaj silne kontrole dostępu.
- Zasady uwierzytelniania i autoryzacji powinny być oparte na rolach.
- Ogranicz dostęp do niechcianych adresów URL.
Niewystarczająca ochrona warstwy transportowej
Opis
Zajmuje się wymianą informacji między użytkownikiem (klientem) a serwerem (aplikacją). Aplikacje często przesyłają przez sieć poufne informacje, takie jak szczegóły uwierzytelniania, informacje o karcie kredytowej i tokeny sesji.
Korzystanie ze słabych algorytmów lub używanie wygasłych lub nieprawidłowych certyfikatów lub niestosowanie protokołu SSL może pozwolić na ujawnienie komunikacji niezaufanym użytkownikom, co może zagrozić aplikacji internetowej i lub wykraść poufne informacje.
Implikacja
- Korzystając z tej luki w zabezpieczeniach sieci Web, osoba atakująca może podsłuchać prawidłowe dane uwierzytelniające użytkownika i uzyskać dostęp do aplikacji.
- Może wykraść informacje o karcie kredytowej.
Obiekty wrażliwe
- Dane przesyłane przez sieć.
Zalecenia
- Włącz bezpieczny HTTP i wymuszaj transfer poświadczeń tylko przez HTTPS.
- Upewnij się, że Twój certyfikat jest ważny i nie wygasł.
Przykłady:
1. Jeśli aplikacja nie korzysta z SSL, osoba atakująca będzie po prostu monitorować ruch w sieci i obserwować uwierzytelniony plik cookie sesji ofiary. Atakujący może ukraść ten plik cookie i wykonać atak typu Man-in-the-Middle.
Niezatwierdzone przekierowania i przekierowania
Opis
Aplikacja internetowa wykorzystuje kilka metod do przekierowywania i przekierowywania użytkowników na inne strony w zamierzonym celu.
Jeśli podczas przekierowywania na inne strony nie zostanie przeprowadzona właściwa weryfikacja, osoby atakujące mogą to wykorzystać i mogą przekierować ofiary do witryn wyłudzających informacje lub stron zawierających złośliwe oprogramowanie lub przekierowań w celu uzyskania dostępu do nieautoryzowanych stron.
Implikacja
- Osoba atakująca może wysłać do użytkownika adres URL zawierający prawdziwy adres URL z dołączonym zakodowanym złośliwym adresem URL. Użytkownik, widząc autentyczną część adresu URL wysłanego przez atakującego, 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 przekierowań i przekierowań w aplikacji. Jeśli jest używany, nie należy używać parametrów użytkownika do obliczania miejsca docelowego.
- Jeśli nie można uniknąć parametrów docelowych, upewnij się, że podana wartość jest prawidłowa i autoryzowana dla użytkownika.
Ten artykuł jest autorstwa Prasanthi Eati