Spis treści
- Wstrzyknięcie bazy danych
- Zepsute uwierzytelnianie
- Narażenie na wrażliwe dane
- Jednostki zewnętrzne XML (XEE)
- Uszkodzona kontrola dostępu
- Błędna konfiguracja zabezpieczeń
- Skrypty między witrynami (XSS)
- Niebezpieczna deserializacja
- Korzystanie z komponentów ze znanymi podatnościami
- Niewystarczające rejestrowanie i monitorowanie
Wstrzyknięcie bazy danych:
W przypadku wysyłania niezaufanych fragmentów danych do interpretera w ramach polecenia przez dowolny obszar, który pobiera dane wejściowe użytkownika i.e wprowadzania danych z formularza lub innego obszaru wprowadzania danych, występują błędy wtrysku. Złośliwe zapytania atakującego mogą skłonić tłumacza do wykonania poleceń, które mogą pokazać poufne dane, do których użytkownik nie ma uprawnień. Na przykład w ataku typu SQL injection, gdy dane wejściowe formularza nie są odpowiednio oczyszczone, osoba atakująca może wejść do bazy danych SQL i uzyskać dostęp do jej zawartości bez autoryzacji, po prostu wprowadzając złośliwy kod bazy danych SQL w formularzu, który oczekuje na tekst jawny. Każdy rodzaj pola, które pobiera dane wejściowe użytkownika, można wstrzykiwać i.e parametry, zmienne środowiskowe, wszystkie usługi sieciowe itp.
Aplikacja jest podatna na atak polegający na wstrzyknięciu, gdy dane dostarczone przez użytkownika nie są oczyszczone i zweryfikowane poprzez użycie dynamicznych zapytań bez kontekstowego ucieczki i bezpośrednie użycie wrogich danych. Wady wstrzykiwania można łatwo wykryć poprzez badanie kodu i użycie zautomatyzowanych narzędzi, takich jak skanery i fuzzery. Aby zapobiec atakom typu injection, można zastosować pewne środki, takie jak oddzielenie danych od poleceń i zapytań, użycie bezpiecznego interfejsu API, który zapewnia sparametryzowany interfejs, użycie „białej listy” walidacji danych wejściowych po stronie serwera za pomocą narzędzi takich jak Snort, ucieczka znaków specjalnych przy użyciu określonej składni ucieczki itp.
Atak wstrzykiwania może prowadzić do masowej utraty danych, ujawnienia poufnych informacji, odmowy dostępu, a nawet całkowitego przejęcia aplikacji. Niektóre kontrolki SQL, takie jak LIMIT, mogą być używane do kontrolowania utraty dużej ilości danych w przypadku ataku. Niektóre rodzaje ataków wstrzykiwania to SQL, OS, NoSQL, ataki wstrzykiwania LDAP.
Zepsute uwierzytelnianie:
Atakujący mogą uzyskać dostęp do kont użytkowników, a nawet złamać cały system hosta za pośrednictwem kont administratora, wykorzystując luki w systemach uwierzytelniania. Luki uwierzytelniania umożliwiają atakującemu złamanie haseł, tokenów sesji, kluczy uwierzytelniających i mogą być połączone z innymi atakami, które mogą tymczasowo, a w niektórych przypadkach na stałe, prowadzić do nieautoryzowanego dostępu do dowolnego innego konta lub sesji użytkownika. Załóżmy, że użytkownik ma listę słów lub słownik milionów poprawnych nazw użytkowników i haseł uzyskanych podczas włamania. Może używać ich pojedynczo w niezwykle krótszym czasie, używając zautomatyzowanych narzędzi i skryptów w systemie logowania, aby sprawdzić, czy ktoś działa. Słabe wdrożenie zarządzania tożsamością i kontroli dostępu prowadzi do luk, takich jak zepsute uwierzytelnianie.
Aplikacja jest podatna na atak uwierzytelniający, gdy pozwala na próbowanie różnych nazw użytkowników i haseł, pozwala na ataki słownikowe lub ataki typu brute force bez żadnej strategii obrony, używa łatwych, domyślnych haseł lub haseł, które wyciekają przy każdym naruszeniu, ujawnia identyfikatory sesji w adresie URL, używa słaby schemat odzyskiwania hasła, wykorzystuje wzorzec plików cookie. Uszkodzone uwierzytelnianie można łatwo wykorzystać za pomocą prostych narzędzi do ataków brute-forcing i słownikowych z dobrym słownikiem. Tego typu atakom można zapobiec, stosując systemy uwierzytelniania wieloskładnikowego, wdrażając słabe sprawdzanie haseł, uruchamiając hasło w bazie danych złych haseł, nie używając domyślnych poświadczeń, dostosowując politykę złożoności haseł, używając dobrej strony serwera menedżer sesji, który po zalogowaniu generuje nowy losowy identyfikator sesji itp.
Uszkodzona luka w uwierzytelnianiu może skutkować przejęciem kilku kont użytkowników i konta administratora, czyli wszystkiego, czego potrzebuje atakujący, aby włamać się do systemu. Tego typu ataki prowadzą do kradzieży tożsamości, oszustw związanych z ubezpieczeniami społecznymi, prania pieniędzy i ujawnienia wysoce tajnych informacji. Ataki obejmują ataki słownikowe, brutalne wymuszanie, przejmowanie sesji i ataki związane z zarządzaniem sesją.
Narażenie na dane wrażliwe:
Czasami aplikacje internetowe nie chronią poufnych danych i informacji, takich jak hasła, dane uwierzytelniające bazy danych itp. Atakujący może łatwo ukraść lub zmodyfikować te słabo chronione dane uwierzytelniające i wykorzystać je do nielegalnych celów. Wrażliwe dane powinny być szyfrowane w spoczynku lub podczas przesyłania i mieć dodatkową warstwę zabezpieczeń, w przeciwnym razie atakujący mogą je ukraść. Atakujący mogą zdobyć wrażliwe dane i wykraść zaszyfrowanych lub czystych użytkowników oraz dane uwierzytelniające bazy danych z serwera lub przeglądarki internetowej. Na przykład, jeśli baza haseł używa niezasolonych lub prostych skrótów do przechowywania haseł, luka w przesłaniu pliku może umożliwić atakującemu odzyskanie bazy haseł, co doprowadzi do ujawnienia wszystkich haseł z tęczową tabelą wstępnie obliczonych skrótów.
Główną wadą jest nie tylko to, że dane nie są zaszyfrowane, nawet jeśli są zaszyfrowane, ale słabe generowanie klucza, słabe algorytmy haszujące, słabe użycie szyfrów mogą również skutkować tego typu jednym z najczęstszych ataków. Aby zapobiec tego typu atakom, najpierw sklasyfikuj, jaki rodzaj danych można uznać za wrażliwe zgodnie z przepisami dotyczącymi prywatności, i zastosuj kontrole zgodnie z klasyfikacją. Staraj się nie przechowywać żadnych tajnych danych, których nie potrzebujesz, umyj je, gdy tylko ich użyjesz. W przypadku przesyłanych danych zaszyfruj je bezpiecznymi protokołami i.e TLS z szyframi PFS itp.
Tego typu luki w zabezpieczeniach mogą skutkować ujawnieniem bardzo poufnych informacji, takich jak dane uwierzytelniające karty kredytowe, dane medyczne, hasła i wszelkie inne dane osobowe, które mogą prowadzić do kradzieży tożsamości i oszustw bankowych itp.
Jednostki zewnętrzne XML (XEE):
Źle skonfigurowane procesory XML przetwarzają odnośniki do encji zewnętrznych w dokumentach XML. Te zewnętrzne podmioty mogą być używane do pobierania danych z plików wewnętrznych, takich jak /etc/passwd plik lub wykonać inne złośliwe zadania. Podatne procesory XML można łatwo wykorzystać, jeśli atakujący może przesłać dokument XML lub dołączyć XML itp. Te wrażliwe jednostki XML można wykryć za pomocą narzędzi SAST i DAST lub ręcznie, sprawdzając zależności i konfiguracje.
Aplikacja internetowa jest podatna na atak XEE z wielu powodów, takich jak: jeśli aplikacja akceptuje bezpośrednie dane wejściowe XML z niezaufanych źródeł, włączone są definicje typu dokumentu (DTD) w aplikacji, aplikacja używa SAML do przetwarzania tożsamości, ponieważ SAML używa XML do tożsamości wstawki itp. Ataki XEE można złagodzić, unikając serializacji wrażliwych danych przy użyciu mniej skomplikowanych formatów danych i.e JSON, łatanie procesorów XML, z których obecnie korzysta aplikacja, a nawet biblioteki, wyłączanie DTD we wszystkich parserach XML, walidacja funkcjonalności przesyłania plików XML za pomocą weryfikacji XSD, itp.
Aplikacja podatna na tego typu ataki może prowadzić do ataku DOS, ataku Billion Laughs, skanowania systemów wewnętrznych, skanowania portów wewnętrznych, wykonywania zdalnego polecenia, które powoduje wpływ na wszystkie dane aplikacji.
Uszkodzona kontrola dostępu:
Kontrola dostępu daje użytkownikom uprawnienia do wykonywania określonych zadań. Uszkodzenie kontroli dostępu ma miejsce, gdy użytkownicy nie są odpowiednio ograniczeni do zadań, które mogą wykonywać. Atakujący mogą wykorzystać tę lukę, co może doprowadzić do uzyskania nieautoryzowanego dostępu do funkcji lub informacji. Załóżmy, że aplikacja internetowa umożliwia użytkownikowi zmianę konta, z którego jest zalogowany, poprzez zmianę adresu URL na konto innego użytkownika bez dalszej weryfikacji. Wykorzystywanie luki w kontroli dostępu jest bezpośrednim atakiem każdego napastnika, tę lukę można znaleźć ręcznie, a także za pomocą narzędzi SAFT i DAFT. Te luki istnieją z powodu braku testów i automatycznego wykrywania aplikacji internetowych, chociaż najlepszym sposobem na ich znalezienie jest zrobienie tego ręcznie.
Luki zawierają eskalację uprawnień i.e działając jako użytkownik, którym nie jesteś lub działając jako administrator, gdy jesteś użytkownikiem, omijanie kontroli dostępu poprzez modyfikację adresu URL lub zmianę stanu aplikacji, manipulację metadanymi, pozwalającą na zmianę klucza podstawowego jako klucza podstawowego innego użytkownika, itp. Aby zapobiec tego rodzaju atakom, mechanizmy kontroli dostępu muszą być zaimplementowane w kodzie po stronie serwera, gdzie atakujący nie mogą modyfikować kontroli dostępu. Egzekwowanie unikalnych limitów biznesowych aplikacji przez modele domen, wyłączanie listowania katalogów serwerów, ostrzeganie administratora o powtarzających się nieudanych próbach logowania, unieważnienie tokenów JWT po wylogowaniu musi być zapewnione w celu złagodzenia tego rodzaju ataków.
Atakujący mogą działać jako inny użytkownik lub administrator, wykorzystując tę lukę do wykonywania złośliwych zadań, takich jak tworzenie, usuwanie i modyfikowanie rekordów itp. Masowa utrata danych może wystąpić, jeśli dane nie są zabezpieczone nawet po naruszeniu.
Błędna konfiguracja zabezpieczeń:
Najczęstszą podatnością jest błędna konfiguracja bezpieczeństwa. Głównym powodem luki jest użycie domyślnej konfiguracji, niekompletnej konfiguracji, konfiguracji Adhoc, źle skonfigurowanych nagłówków HTTP i pełnych komunikatów o błędach zawierających więcej informacji, niż użytkownik faktycznie powinien wiedzieć. Na każdym poziomie aplikacji internetowej mogą wystąpić błędne konfiguracje zabezpieczeń i.e baza danych, serwer WWW, serwer aplikacji, usługi sieciowe itp. Atakujący mogą wykorzystać niezałatane systemy lub uzyskać dostęp do niechronionych plików i katalogów, aby uzyskać nieautoryzowany dostęp do systemu. Na przykład aplikacja nadmiernie rozwlekła komunikaty o błędach, które pomagają atakującemu poznać luki w systemie aplikacji i sposób, w jaki działa. Do wykrywania tego typu luk w zabezpieczeniach można używać zautomatyzowanych narzędzi i skanerów.
Aplikacja internetowa zawiera lukę tego typu, jeśli w jakiejkolwiek części aplikacji brakuje środków wzmacniających bezpieczeństwo, niepotrzebne porty są otwarte lub włącza niepotrzebne funkcje, używane są domyślne hasła, obsługa błędów ujawnia atakującemu błędy informacyjne, niezałatane lub przestarzałe oprogramowanie zabezpieczające itp. Można temu zapobiec, usuwając niepotrzebne cechy kodu, i.minimalna platforma bez zbędnych funkcji, dokumentacji itp. umożliwiająca zadanie aktualizacji i łatania dziur w zabezpieczeniach w ramach procesów zarządzania poprawkami, wykorzystanie procesu do weryfikacji skuteczności podjętych środków bezpieczeństwa, zastosowanie powtarzalnego procesu utwardzania do łatwo jest wdrożyć inne środowisko, które jest odpowiednio zablokowane.
Tego typu luki lub luki pozwalają atakującemu na uzyskanie nieautoryzowanego dostępu do danych systemowych, co prowadzi do całkowitego włamania się do systemu.
Skrypty między witrynami (XSS):
Luki XSS pojawiają się w momencie, gdy aplikacja internetowa zawiera niezaufane dane na nowej stronie internetowej bez uzasadnionej zgody lub ucieczki albo odświeża bieżącą stronę witryny danymi dostarczonymi przez klienta, korzystając z interfejsu API przeglądarki, który może tworzyć kody HTML lub JavaScript. Błędy XSS występują w przypadku, gdy strona internetowa pozwala użytkownikowi dodać niestandardowy kod do ścieżki URL, która może być widoczna dla innych użytkowników. Te luki są wykorzystywane do uruchamiania złośliwego kodu JavaScript w przeglądarce celu. Załóżmy, że atakujący może wysłać ofierze link zawierający link do strony dowolnej firmy company. W tym połączeniu może być osadzony jakiś złośliwy kod JavaScript. W przypadku, gdy strona banku nie jest odpowiednio zabezpieczona przed atakami XSS, po kliknięciu w link złośliwy kod zostanie uruchomiony w przeglądarce ofiary.
Cross-Site Scripting to luka w zabezpieczeniach, która jest obecna w prawie aplikacjach internetowych. Aplikacja jest podatna na XSS, jeśli przechowuje nieoczyszczone dane wejściowe użytkownika, które może zobaczyć inny użytkownik, dzięki wykorzystaniu struktur JavaScript, aplikacji jednostronicowych i interfejsów API, które potężnie zawierają informacje kontrolowane przez atakującego na stronie, są bezradne wobec DOM XSS. Ataki XSS można złagodzić poprzez wykorzystanie frameworków, które z natury wymykają się i oczyszczają dane wejściowe XSS, takie jak React JS itp.e w atrybutach HTML, URI, Javascript itp., użycie kodowania kontekstowego w przypadku modyfikacji dokumentu po stronie klienta itp.
Ataki oparte na XSS są trzech typów i.e Odbite XSS, DOM XSS i zapisane XSS. Wszystkie typy tych ataków mają znaczny wpływ, ale w przypadku Stored XSS wpływ jest jeszcze większy i.e kradzież danych uwierzytelniających, wysyłanie złośliwego oprogramowania do ofiary itp.
Niebezpieczna deserializacja:
Serializacja danych oznacza pobieranie obiektów i konwertowanie ich do dowolnego formatu, aby dane te mogły być później wykorzystane do innych celów, podczas gdy deserializacja danych oznacza przeciwieństwo tego. Deserializacja polega na rozpakowaniu tych serializowanych danych do użytku aplikacji. Niebezpieczna deserializacja oznacza temperowanie danych, które zostały zserializowane tuż przed rozpakowaniem lub deserializacją. Niebezpieczna deserializacja prowadzi do zdalnego wykonania kodu i jest wykorzystywana do wykonywania innych zadań do złośliwych celów, takich jak eskalacja uprawnień, ataki typu injection, ataki typu powtórka itp. Istnieje kilka narzędzi do wykrywania tego rodzaju wad, ale często potrzebna jest pomoc człowieka, aby zweryfikować problem. Wykorzystanie deserializacji jest nieco trudne, ponieważ exploity nie będą działać bez ręcznych zmian.
Gdy aplikacja deserializuje złośliwe obiekty dostarczone przez atakujący podmiot. Może to prowadzić do dwóch rodzajów ataków i.ataki związane ze strukturą danych i obiektami, w których atakujący modyfikuje logikę aplikacji lub wykonuje zdalny kod oraz typowe ataki manipulacji danymi, w których istniejące struktury danych są wykorzystywane ze zmodyfikowaną treścią np. ataki związane z kontrolą dostępu. Serializacji można używać w komunikacji procesów zdalnych (RPC) lub komunikacji między procesami (IPC), buforowaniu danych, usługach internetowych, serwerze pamięci podręcznej baz danych, systemach plików, tokenach uwierzytelniania API, plikach cookie HTML, parametrach formularzy HTML itp. Ataki deserializacji można złagodzić poprzez nieużywanie serializowanych obiektów z niezaufanych źródeł, wdrażanie kontroli integralności, izolowanie kodu działającego w nisko uprzywilejowanym środowisku, monitorowanie przychodzących i wychodzących połączeń sieciowych z serwerów, które często deserializują.
Korzystanie z komponentów ze znanymi podatnościami:
Różne komponenty, takie jak biblioteki, frameworki i moduły oprogramowania, są używane przez większość programistów w aplikacjach internetowych. Biblioteki te pomagają programiście uniknąć niepotrzebnej pracy i zapewniają niezbędną funkcjonalność. Atakujący szukają wad i luk w tych komponentach, aby koordynować atak. W przypadku znalezienia luki w zabezpieczeniach w komponencie, wszystkie strony korzystające z tego samego komponentu mogą być podatne. Exploity z tych luk są już dostępne, a napisanie niestandardowego exploita od zera wymaga dużo wysiłku. Jest to bardzo powszechny i powszechny problem, użycie dużej ilości komponentów w tworzeniu aplikacji internetowej może prowadzić do nawet nieznajomości i zrozumienia wszystkich użytych komponentów, łatanie i aktualizowanie wszystkich komponentów to długa droga.
Aplikacja jest podatna na ataki, jeśli programista nie zna wersji używanego komponentu, oprogramowanie jest nieaktualne i.e system operacyjny, DBMS, uruchomione oprogramowanie, środowiska uruchomieniowe i biblioteki, skanowanie podatności nie jest wykonywane regularnie, kompatybilność zaktualizowanego oprogramowania nie jest testowana przez programistów. Można temu zapobiec, usuwając nieużywane zależności, pliki, dokumentację i biblioteki, regularnie sprawdzając wersję komponentów po stronie klienta i serwera, pozyskując komponenty i biblioteki z oficjalnych i zaufanych bezpiecznych źródeł, monitorując niezałatane biblioteki i komponenty, zapewniając plan za regularne aktualizowanie i łatanie wrażliwych komponentów.
Te luki w zabezpieczeniach prowadzą do niewielkich skutków, ale mogą również prowadzić do kompromitacji serwera i systemu. Wiele dużych włamań opierało się na znanych lukach w zabezpieczeniach komponentów. Korzystanie z podatnych na ataki komponentów osłabia ochronę aplikacji i może być punktem wyjścia do dużego ataku for.
Niewystarczające rejestrowanie i monitorowanie:
Większość systemów nie podejmuje wystarczających środków i kroków w celu wykrycia naruszeń danych. Średni czas reakcji na incydent to 200 dni po jego wydarzeniu, to dużo czasu na zrobienie wszystkich paskudnych rzeczy dla atakującego podmiotu. Niewystarczające rejestrowanie i monitorowanie pozwala atakującemu na dalsze ataki na system, utrzymanie kontroli nad systemem, manipulowanie, przechowywanie i wydobywanie danych zgodnie z potrzebami. Atakujący wykorzystują brak monitorowania i odpowiedzi na swoją korzyść, aby zaatakować aplikację internetową.
Niewystarczające rejestrowanie i monitorowanie występują w dowolnym momencie i.Dzienniki aplikacji, które nie są monitorowane pod kątem nietypowych działań, zdarzenia podlegające kontroli, takie jak nieudane próby logowania i wysokie wartości transakcji, nie są prawidłowo rejestrowane, ostrzeżenia i błędy generują niejasne komunikaty o błędach, brak alertów wyzwalających w przypadku testów penetracyjnych przy użyciu automatycznych narzędzi DAST, brak możliwości wykrycia lub szybko zaalarmuj aktywne ataki itp. Można je złagodzić, zapewniając, że wszystkie błędy logowania, kontroli dostępu i weryfikacja danych wejściowych po stronie serwera mogą być rejestrowane w celu zidentyfikowania szkodliwego konta użytkownika i przechowywane przez wystarczająco długi czas, aby można było przeprowadzić opóźnione dochodzenie kryminalistyczne, zapewniając, że generowane dzienniki są w formacie kompatybilny ze scentralizowanymi rozwiązaniami do zarządzania logami, poprzez zapewnienie kontroli integralności transakcji o wysokiej wartości, poprzez ustanowienie systemu terminowego powiadamiania o podejrzanych działaniach itp.
Większość udanych ataków rozpoczyna się od sprawdzenia i sondowania podatności systemu, co pozwala na to, aby te sondowanie podatności mogło doprowadzić do narażenia całego systemu na szwank. . . . ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.
Wniosek:
Luki bezpieczeństwa w aplikacji internetowej wpływają na wszystkie podmioty powiązane z tą aplikacją. Należy zająć się tymi lukami, aby zapewnić użytkownikom bezpieczne i bezpieczne środowisko environment. Atakujący mogą wykorzystać te luki do włamania się do systemu, przejęcia go i eskalacji uprawnień. Wpływ zhakowanej aplikacji internetowej można zwizualizować od skradzionych danych uwierzytelniających karty kredytowej i kradzieży tożsamości po wyciek wysoce poufnych informacji itp. w zależności od potrzeb i wektorów ataku złośliwych podmiotów.