10 najczęstszych luk w zabezpieczeniach sieci Web
Oliver Jones
OWASP lub Open Web Security Project to organizacja charytatywna non-profit, której celem jest poprawa bezpieczeństwa oprogramowania i aplikacji internetowych.
Organizacja publikuje listę najważniejszych luk w zabezpieczeniach sieci na podstawie danych pochodzących od różnych organizacji zajmujących się bezpieczeństwem.
Luki w zabezpieczeniach internetowych 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ższa możliwość wykorzystania, gdy do ataku potrzebna jest jedynie przeglądarka internetowa, a najniższa 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 –Jakie szkody zostaną wyrządzone, jeśli luka w zabezpieczeniach zostanie ujawniona lub zaatakowana? Najwyższy oznacza całkowitą awarię systemu, a najniższy oznacza brak jakichkolwiek informacji.
Głównym celem OWASP Top 10 jest edukowanie programistów, projektantów, menedżerów, architektów i organizacji na temat najważniejszych luk w zabezpieczeniach.
Oto 10 najpopularniejszych luk w zabezpieczeniach według OWASP Top 10:
SQL Injection
Opis
Wstrzykiwanie to luka w zabezpieczeniach, która umożliwia atakującemu zmianę backendu SQL oświadczenia poprzez manipulację danymi dostarczonymi przez użytkownika.
Wstrzyknięcie ma miejsce, gdy dane wejściowe użytkownika są wysyłane do interpretera jako część polecenia lub zapytania i oszukują interpretera do wykonania niezamierzonych poleceń i umożliwiają dostęp do nieautoryzowanych danych.
Polecenie SQL, które po wykonaniu przez aplikację internetową może również udostępnić bazę danych zaplecza.
Implikacja
- Osoba atakująca może wstrzyknąć złośliwą zawartość do wrażliwych pól.
- 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ń).
- Administracja Operaoperacje mogą być wykonywane w bazie danych
Wrażliwe obiekty
- Pola wejściowe
- Adresy URL współpracujące z bazą danych.
Przykłady:
- SQL injection na stronie logowania
Logowanie do aplikacji bez posiadania ważnych danych uwierzytelniających.
Dostępna jest prawidłowa nazwa użytkownika, 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 Tłumacza, jak poniżej
WYBIERZ * OD Użytkownicy GDZIE Nazwa_użytkownika = sjones ORAZ Hasło = 1=1′ lub pass123;
Zalecenia
- Biała lista pól wejściowych
- Unikaj wyświetlania szczegółowych komunikatów o błędach, które mogą być przydatne dla atakującego.
Skrypty między witrynami
Opis
Cross Site Scripting jest również w skrócie znany jako XSS.
Luki XSS atakują skrypty osadzone na stronie, które są wykonywane po stronie klienta, tj. przeglądarki użytkownika, a nie po stronie serwera. Wady te mogą wystąpić, gdy aplikacja pobiera niezaufane dane i wysyła je do przeglądarki internetowej bez odpowiedniej walidacji.
Osoby atakujące mogą używać XSS do wykonywania 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 zaufany, czy nie, skrypt zostanie wykonany, a osoba atakująca może przejąć pliki cookie sesji, zniszczyć strony internetowe lub przekierować użytkownika na niechciane i złośliwe strony internetowe.
XSS to atak, który umożliwia atakującemu wykonanie skryptów w przeglądarce ofiary.
Implikacja:
- Wykorzystując tę lukę w zabezpieczeniach, osoba atakująca może wprowadzić do aplikacji skrypty, ukraść pliki cookie sesji, uszkodzić strony internetowe i uruchomić złośliwe oprogramowanie na komputerach ofiary.
Wrażliwe obiekty
- Pola wejściowe
- Używać
Przykłady
1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>
Powyższy skrypt zostanie uruchomiony w przeglądarce, a jeśli witryna będzie podatna na atak XSS, wyświetli się okno dialogowe z komunikatem.
Poważniejszy atak można przeprowadzić, jeśli atakujący chce wyświetlić lub zapisać plik cookie sesji.
2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com szerokość = 500 wysokość 500>
Powyższy skrypt po uruchomieniu przeglądarka załaduje niewidoczną ramkę wskazującą http://google.com.
Atak może stać się poważny poprzez uruchomienie w przeglądarce złośliwego skryptu.
Zalecenia
- Pola wejściowe białej listy
- Kodowanie wejścia i wyjścia
Uszkodzone uwierzytelnianie i zarządzanie sesją
Opis
Witryny internetowe zazwyczaj tworzą sesyjny plik cookie i identyfikator sesji dla każdej ważnej sesji, a te pliki cookie zawierają wrażliwe dane, takie jak nazwa użytkownika, hasło itp. Gdy sesja zostanie zakończona w wyniku wylogowania lub nagłego zamknięcia przeglądarki, te pliki cookie powinny zostać unieważnione, tj. dla każdej sesji powinno pojawić się nowe ciasteczko.
Jeżeli pliki cookies nie zostaną unieważnione, wrażliwe dane pozostaną w systemie. Na przykład, użytkownik korzystający z komputera publicznego (Cyber Cafe), pliki cookie podatnej witryny zapisują się w systemie i są narażone na atak. Osoba atakująca korzysta z tego samego publicznego komputera po pewnym czasie, a wrażliwe dane zostają naruszone.
W ten sam sposób użytkownik korzystający z komputera publicznego, zamiast się wylogować, zamyka gwałtownie przeglądarkę. Osoba atakująca korzysta z tego samego systemu i podczas przeglądania tej samej podatnej na ataki witryny zostanie otwarta poprzednia sesja ofiary. Osoba atakująca może zrobić, co chce, od kradzieży informacji o profilu, danych karty kredytowej itp.
Należy sprawdzić siłę uwierzytelniania i zarządzania sesją. Klucze, tokeny sesji, pliki cookie powinny być poprawnie zaimplementowane, bez naruszania haseł.
Wrażliwe obiekty
- Identyfikatory sesji ujawnione w adresie URL mogą prowadzić do ataku polegającego na fiksacji sesji.
- Identyfikatory sesji są takie same przed i po wylogowaniu i zalogowaniu.
- Limity czasu sesji nie są poprawnie zaimplementowane.
- Aplikacja przypisuje ten sam identyfikator sesji dla każdej nowej sesji.
- Uwierzytelnione części aplikacji są chronione za pomocą protokołu SSL, a hasła są przechowywane w formacie zaszyfrowanym lub zaszyfrowanym.
- Sesja może być ponownie wykorzystana przez użytkownika z niskimi uprawnieniami.
Implikacja
- Wykorzystując tę lukę, osoba atakująca może przejąć sesję, uzyskać nieautoryzowany dostęp do systemu, co umożliwia ujawnienie i modyfikację nieautoryzowanych informacji.
- Sesje mogą być kontrolowane przy użyciu skradzionych plików cookie lub sesji przy użyciu XSS.
Przykłady
- Aplikacja do rezerwacji linii 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 poinformować znajomych o sprzedaży i wysyła wiadomość e-mail. Znajomi otrzymują identyfikator sesji i mogą być wykorzystywani do nieautoryzowanych modyfikacji lub niewłaściwego wykorzystania zapisanych danych karty kredytowej.
- Aplikacja jest podatna na atak 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 zamyka przeglądarkę zamiast wylogować się i odejść. 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 sesjami powinny zostać określone zgodnie ze standardem OWASP Application Security Verification Standard.
- Nigdy nie ujawniaj żadnych danych uwierzytelniających w adresach URL lub dziennikach.
- Należy również dołożyć wszelkich starań, aby uniknąć luk XSS, które mogą zostać wykorzystane do kradzieży identyfikatorów sesji.
Niebezpieczne bezpośrednie odwołania do obiektów
Opis
Występuje, gdy programista udostępnia 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 stworzyć przyszły atak mający na celu uzyskanie dostępu 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ć bezpieczeństwo aplikacji.
Wrażliwe obiekty
- W adresie URL.
Przykłady:
Zmiana „userid” w poniższym adresie URL może umożliwić atakującemu dostęp do informacji o innym użytkowniku.
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 kontroli dostępu.
- Unikaj ujawniania odniesień do obiektów w adresach URL.
- Zweryfikuj uprawnienia do wszystkich obiektów referencyjnych.
Fałszowanie żądań w różnych witrynach
Opis
Fałszywe żądanie między witrynami to sfałszowane żądanie pochodzące z różnych witryn.
Atak CSRF to atak, który występuje, gdy złośliwa witryna internetowa, e-mail lub program powoduje, że przeglądarka użytkownika wykonuje niechcianą czynność na zaufanej witrynie, na której użytkownik jest obecnie uwierzytelniony.
Atak CSRF zmusza przeglądarkę zalogowanej ofiary do wysłania sfałszowanego żądania HTTP, zawierającego plik cookie sesji ofiary i wszelkie inne automatycznie dołączone informacje uwierzytelniające, do podatnej na ataki aplikacji internetowej.
Link zostanie wysłany przez osobę atakującą do ofiary, gdy użytkownik kliknie adres URL po zalogowaniu się na oryginalną stronę internetową, a dane zostaną skradzione ze strony internetowej.
Implikacja
- Korzystając z tej luki, osoba atakująca może zmienić informacje w profilu użytkownika, zmienić jego status, utworzyć nowego użytkownika w imieniu administratora itp.
Wrażliwe obiekty
- Strona profilu użytkownika
- Formularze konta użytkownika
- Strona transakcji biznesowych
Przykłady
Ofiara jest zalogowana na stronie internetowej banku, używając prawidłowych danych uwierzytelniających. Otrzymuje wiadomość od atakującego, w której jest napisane: „Kliknij tutaj, aby przekazać 1 $ na rzecz organizacji”.
Kiedy ofiara kliknie, zostanie utworzona ważna prośba o przekazanie 1 dolara na określone konto.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
Osoba atakująca przechwytuje to żądanie, tworzy poniższe żądanie i osadza przycisk z napisem „Popieram przyczynę”.
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Ponieważ sesja jest uwierzytelniona, a żądanie przychodzi za pośrednictwem witryny banku, serwer przekaże atakującemu 1000 dolarów.
Rekomendacja
- Nakazuj obecność użytkownika podczas wykonywania poufnych działań.
- Wdrażaj mechanizmy takie jak CAPTCHA, ponowne uwierzytelnianie 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 zostaną one prawidłowo skonfigurowane, atakujący może uzyskać nieautoryzowany dostęp do poufnych danych lub funkcjonalności.
Czasami takie wady skutkują całkowitym kompromisem systemu. Aktualizowanie oprogramowania to także dobre bezpieczeństwo.
Implikacja
- Wykorzystując tę lukę, osoba atakująca może wyliczyć podstawową technologię i informacje o wersji serwera aplikacji, informacje o bazie danych oraz uzyskać informacje o aplikacji, aby przeprowadzić jeszcze kilka ataków.
Wrażliwe obiekty
- URL
- Pola formularza
- Pola wejściowe
Przykłady
- Konsola administracyjna serwera aplikacji jest instalowana automatycznie i nie jest usuwana. Domyślne konta nie ulegają zmianie. 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. Osoba atakująca odkrywa i może po prostu wyświetlić listę katalogów, aby znaleźć dowolny plik.
Zalecenia
- Solidna architektura aplikacji zapewniająca dobre rozdzielenie i bezpieczeństwo między komponentami.
- Zmień domyślne nazwy użytkowników i hasła.
- Wyłącz wykazy katalogów i zaimplementuj kontrole kontroli dostępu.
Niebezpieczne przechowywanie kryptograficzne
Opis
Niepewne przechowywanie kryptograficzne to powszechna luka w zabezpieczeniach, która pojawia się, gdy wrażliwe dane nie są bezpiecznie przechowywane.
Dane uwierzytelniające użytkownika, informacje profilowe, szczegóły dotyczące zdrowia, informacje o karcie kredytowej itp. zaliczają się do poufnych danych na stronie internetowej.
Dane te będą zapisane w bazie danych aplikacji. Jeśli dane te będą przechowywane nieprawidłowo, bez użycia szyfrowania lub mieszania*, będą podatne na ataki.
(*Haszowanie to transformacja znaków ciągu na krótsze ciągi o stałej długości lub klucz. Aby odszyfrować ciąg, powinien być dostępny algorytm użyty do utworzenia klucza)
Implikacja
- Wykorzystując tę lukę, osoba atakująca może ukraść, zmodyfikować tak słabo chronione dane w celu dokonania kradzieży tożsamości, oszustwa związanego z kartami kredytowymi lub innych przestępstw.
Wrażliwe obiekty
- Baza danych aplikacji.
Przykłady
W jednej z aplikacji bankowych baza danych haseł używa niesolonych skrótów * do przechowywania haseł wszystkich użytkowników. Luka polegająca na wstrzykiwaniu kodu SQL umożliwia atakującemu odzyskanie pliku z hasłami. Wszystkie niesolone skróty można brutalnie wymusić w mgnieniu oka, podczas gdy solone hasła zajęłyby tysiące lat.
(*Niesolone skróty – sól to losowe dane dodawane 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 znajdujące się poza siedzibą firmy są szyfrowane, ale klucze są zarządzane i tworzone osobno.
Brak ograniczenia dostępu do adresu URL
Opis
Aplikacje internetowe sprawdzają prawa dostępu do adresów URL przed wyświetleniem chronionych łączy i przycisków. Aplikacje muszą przeprowadzać podobne kontrole kontroli dostępu przy każdym dostępie 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 z uprawnieniami. Osoba atakująca może uzyskać dostęp do wrażliwych stron, wywołać funkcje i wyświetlić poufne informacje.
Implikacja
- Korzystając z tej luki, osoba atakująca może uzyskać dostęp do nieautoryzowanych adresów URL bez konieczności logowania się do aplikacji i wykorzystać lukę. Osoba atakująca może uzyskać dostęp do wrażliwych stron, wywołać funkcje i wyświetlić poufne informacje.
Wrażliwe obiekty:
- Używać
Przykłady
- Osoba atakująca zauważa, że adres URL wskazuje rolę jako „/user/getaccounts”. Modyfikuje jako „/admin/getaccounts”.
- Osoba atakująca może dołączyć rolę do adresu URL.
http://www.vulnerablsite.com można modyfikować jako http://www.vulnerablesite.com/admin
Zalecenia
- Wprowadź rygorystyczne kontrole dostępu.
- Zasady uwierzytelniania i autoryzacji powinny opierać się 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ą poufne informacje, takie jak szczegóły uwierzytelniania, informacje o karcie kredytowej i tokeny sesji przez sieć.
Stosowanie słabych algorytmów, wygasłych lub nieważnych certyfikatów albo niestosowanie protokołu SSL może spowodować ujawnienie komunikacji niezaufanym użytkownikom, co może zagrozić bezpieczeństwu aplikacji internetowej i/lub doprowadzić do kradzieży poufnych informacji.
Implikacja
- Wykorzystując tę lukę w zabezpieczeniach sieci, osoba atakująca może podsłuchać dane uwierzytelniające legalnego użytkownika i uzyskać dostęp do aplikacji.
- Może ukraść dane karty kredytowej.
Wrażliwe obiekty
- Dane przesyłane przez sieć.
Zalecenia
- Włącz bezpieczny protokół HTTP i wymuszaj przesyłanie danych uwierzytelniających wyłącznie za pośrednictwem protokołu HTTPS.
- Upewnij się, że Twój certyfikat jest ważny i nie wygasł.
Przykłady:
1. W przypadku aplikacji nie korzystającej z protokołu SSL osoba atakująca po prostu będzie monitorować ruch sieciowy i zaobserwuje plik cookie sesji uwierzytelnionej ofiary. Osoba atakująca może ukraść ten plik cookie i wykonać atak typu Man-in-the-Middle.
Niezatwierdzone przekierowania i przesyłanie dalej
Opis
Aplikacja internetowa wykorzystuje kilka metod przekierowywania i przekazywania użytkowników na inne strony zgodnie z ich przeznaczeniem.
Jeśli przekierowanie na inne strony nie zostanie odpowiednio zweryfikowane, napastnicy mogą to wykorzystać i przekierować ofiary do witryn phishingowych lub zawierających złośliwe oprogramowanie albo użyć przekierowań, aby uzyskać dostęp do nieautoryzowanych stron.
Implikacja
- Osoba atakująca może wysłać użytkownikowi adres URL zawierający prawdziwy adres URL z dołączonym zakodowanym złośliwym adresem URL. Użytkownik, widząc jedynie prawdziwą część adresu URL wysłanego przez atakującego, może go przeglądać i może 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 przesyłania dalej w aplikacji. Jeśli jest używany, nie uwzględniaj parametrów użytkownika przy obliczaniu miejsca docelowego.
- Jeżeli nie da się uniknąć parametrów docelowych, należy upewnić się, że podana wartość jest prawidłowa i autoryzowana dla użytkownika.
