22 typowe luki w zabezpieczeniach aplikacji internetowych, które należy znać
Opublikowany: 2021-10-14Firmy nieustannie „przesuwają się w lewo” i korzystają z innowacyjnych doświadczeń klientów i pracowników dostarczanych przez aplikacje oparte na chmurze. Jednocześnie złośliwi sprawcy stale zmieniają swoje strategie ataków, aby dostosować się do tej zmiany.
Aby zachować prywatność i bezpieczeństwo danych, firmy muszą zadbać o ochronę przed tymi 22 typowymi lukami w zabezpieczeniach aplikacji internetowych .
Uszkodzona kontrola dostępu
Kontrole dostępu są odpowiedzialne za sposób interakcji użytkowników z zasobami i danymi, a także za to, co mogą edytować i/lub czytać. Wadliwa luka w kontroli dostępu jest możliwa, gdy użytkownik jest w stanie zaangażować dane w sposób, który jest naprawdę niepotrzebny. Na przykład, jeśli użytkownik powinien być w stanie tylko odczytać szczegóły płatności, ale faktycznie ma możliwość ich edycji, taka sytuacja jest przykładem złamanej kontroli dostępu. Złośliwi atakujący wykorzystują tę lukę, aby uzyskać nieautoryzowany dostęp do oprogramowania, sieci i systemów. Mogą następnie wykorzystać sytuację, przyznać identyfikatorowi użytkownika większy dostęp w infrastrukturze, naruszyć dostępność, poufność lub integralność danych.
Uszkodzone uwierzytelnianie
Luki w aplikacjach internetowych związane z uszkodzonym lub złamanym uwierzytelnianiem również wynikają z dostępu użytkownika. Jednak w tym przypadku złośliwi atakujący negatywnie wpływają na dane potwierdzające tożsamość użytkownika, na przykład poprzez przejęcie tokenów sesji, kluczy lub haseł. Złośliwy atakujący uzyskuje nieautoryzowany dostęp do oprogramowania, systemów i sieci, ponieważ organizacja nie była w stanie prawidłowo ustawić odpowiednich kontroli zarządzania tożsamością i dostępem.
Powrót karetki i wtrysk linii (CRLF)
Powrót karetki działa jak polecenie, które oznacza początek wiersza kodu, zwykle oznaczone jako /r. Z drugiej strony, wysuw wiersza to polecenie oznaczające koniec wiersza kodu, zwykle oznaczone jako /n. Podobnie jak kilka innych programów, każdy system operacyjny wykorzystuje różne kombinacje powrotu karetki i wysuwu wiersza. Gdy złośliwi atakujący biorą udział we wstrzyknięciach CRLF, wprowadzony kod zmienia sposób, w jaki aplikacja internetowa reaguje na polecenia. Może to być wykorzystane do ujawnienia poufnych danych lub wykonania kodu.
Niepewna transformacja szyfru
Szyfr, który jest standardowym terminem określającym „algorytm szyfrowania”, jest w rzeczywistości matematyką stojącą za procesem szyfrowania lub deszyfrowania. Transformacja odnosi się do zarysu operacji przeprowadzanych na wejściu w celu dostarczenia oczekiwanego wyjścia. Tak więc transformacja szyfru odnosi się do liczby operacji, które ukrywają nieczytelne zaszyfrowane dane z powrotem w czytelne, odszyfrowane dane. Luka w zabezpieczeniach transformacji szyfru oznacza, że algorytm szyfrowania można łatwo złamać, ostatecznie sabotując istotę szyfrowania w pierwszej kolejności.
Komponenty z oczywistymi podatnościami
Działanie każdej aplikacji internetowej zależy od innych komponentów. Na przykład, jeśli używasz aplikacji na niezałatanym serwerze WWW lub aplikacji, serwer jest częścią z oczywistymi lukami. Lista Common Vulnerabilities and Exposures (CVE) zawiera wszystkie znane luki w zabezpieczeniach. Ponieważ złośliwi atakujący znają tę listę, często szukają składników bez odpowiednich aktualizacji poprawek zabezpieczeń. W momencie, gdy mogą zinfiltrować jeden komponent aplikacji internetowej, mogą również uzyskać dostęp do danych aplikacji.
Zasady udostępniania zasobów między źródłami (CORS)
Wszystkie aplikacje internetowe wykorzystują adres URL jako medium łączące przeglądarkę użytkownika z jego serwerem. Polityka tego samego pochodzenia to jedna wspólna ochrona. Zgodnie z tym serwer odpowie tylko na adres URL z tym samym protokołem, schematem ścieżki i nazwą domeny najwyższego poziomu. Oznacza to, że możesz uzyskać dostęp do stron http://organization.com/page1 i http://organization.com/page2, ponieważ obie mają dostęp do następujących elementów:
- Protokół: HTTP
- Domena: Firma.com
- Schemat ścieżki: /strona#
Chociaż jest bezpieczna, zasady tego samego pochodzenia są restrykcyjne w przypadku aplikacji internetowych, które wymagają dostępu do zasobów łączących się ze stronami trzecimi lub subdomenami.
Polityka CORS przyznaje przeglądarce uprawnienia do przeglądania tych powiązanych zasobów, ustanawiając pewną liczbę dozwolonych nagłówków HTTP uważanych za „zaufane”. Na przykład aplikacja może być zmuszona do pobierania danych z dwóch baz danych na osobnych serwerach internetowych. Tworzenie określonej listy „dozwolonych” staje się zbyt pracochłonne, gdy dołącza się dodatkowe serwery. Ponieważ oba serwery „współdzielą” aplikację, firma tworzy politykę CORS, która umożliwia przeglądarkom łączenie się z obydwoma. Jeśli jednak zasada CORS nie jest prawidłowo zdefiniowana, może ona zezwolić serwerom na udzielenie dostępu na żądanie złośliwego atakującego.
Zarządzanie poświadczeniami
Poświadczenia użytkownika obejmują identyfikator użytkownika i klucz dostępu. Użytkownik musi podać oba elementy informacji na stronie logowania przed uzyskaniem dostępu do aplikacji. Jednak bazy danych mają tendencję do używania słabego szyfrowania lub przechowywania informacji w postaci zwykłego tekstu. Słabe zarządzanie danymi uwierzytelniającymi umożliwia atakującym łatwe kradzieże danych uwierzytelniających i wykorzystywanie ich w celu uzyskania dostępu do aplikacji internetowych.
Fałszowanie żądań między witrynami (CSRF)
Atak CSRF wykorzystuje metodologie socjotechniki, aby skłonić użytkownika do zmodyfikowania informacji, takich jak hasła lub nazwy użytkowników, w aplikacji. CSRF, w przeciwieństwie do ataków typu cross-site scripting (XXS) lub złośliwego oprogramowania, wymaga, aby użytkownik był zalogowany do aplikacji, która wykorzystuje tylko pliki cookie sesji do sprawdzania poprawności żądań użytkowników lub śledzenia sesji. W momencie, gdy użytkownik wykonuje oczekiwaną akcję, złośliwy aktor wykorzystuje przeglądarkę do wykonania pozostałej części ataku, takiej jak przeniesienie środków, bez wiedzy użytkownika o tym, co się stało.
Skrypty między witrynami (XXS)
W przeciwieństwie do CSRF, który wymaga, aby użytkownik był zalogowany w aplikacji, aby mógł zostać oszukany w celu zmiany pewnych informacji, atak XXS wymaga od złośliwego atakującego wprowadzenia kodu na stronie internetowej, zwykle w niektórych elementach strony, takich jak obraz. Gdy użytkownik uruchomi stronę internetową w swojej przeglądarce, zły kod zaczyna się pobierać i uruchamiać w przeglądarce. Na przykład złośliwy kod może przekierować użytkownika z wiarygodnej witryny na nielegalną.
Indeksowanie katalogów
Zazwyczaj serwery WWW opisują wszystkie zapisane na nich pliki w jednym katalogu. Gdy użytkownik chce zlokalizować określony plik w aplikacji internetowej, zwykle dodaje nazwę pliku w żądaniu. W przypadku, gdy plik jest niedostępny, aplikacja zaprezentuje użytkownikowi listę wszystkich zindeksowanych plików, dzięki czemu użytkownik ma możliwość wybrania czegoś innego.
Jednak pliki są automatycznie indeksowane przez serwery WWW. Gdy aplikacja przedstawia listę wszystkich przechowywanych plików, złośliwy atakujący wykorzystując luki w indeksie katalogów może uzyskać dostęp do danych, które mogą dostarczyć mu więcej informacji o systemie. Mogą na przykład poznać osobiste konta użytkowników lub konwencje nazewnictwa. Te dwa punkty danych można wykorzystać do przeprowadzania ataków polegających na kradzieży poświadczeń lub odkrywania poufnych informacji.
Przeglądanie katalogów
Znana również jako atak wsteczny, kropka-kropka i wspinanie się po katalogach, luka w przechodzeniu katalogów wykorzystuje sposób, w jaki aplikacja otrzymuje dane z serwera WWW. Listy kontroli dostępu (ACL) ogólnie ograniczają dostęp użytkowników do określonych plików w katalogu głównym. Złośliwi napastnicy, którzy korzystają z trybu podatności na przechodzenie katalogów, dowiadują się o formacie adresu URL, którego aplikacja używa do żądania plików.
Kapsułkowanie
W odróżnieniu od niektórych innych powszechnych luk w aplikacjach internetowych na liście, luka enkapsulacji wykorzystuje luki w sposobie, w jaki programista zakodował aplikację. Enkapsulacja to termin programowania, który odnosi się do łączenia danych i działań, które można wykonać na tych danych w tylko jednej jednostce. Enkapsulacja zabezpiecza dane, ukrywając informacje o sposobie działania kodu, co zapewnia lepszy interfejs użytkownika. Użytkownicy nie muszą wiedzieć, w jaki sposób aplikacja dostarcza im dane; wszystko, czego potrzebują, to dostęp do niego.
Na przykład programista aplikacji może włączyć kontrolę dostępu, taką jak uprawnienia do odczytu lub zapisu, do możliwości aplikacji do pobierania danych. Jeśli użytkownik zażąda informacji w aplikacji, dostarcza tylko te dane, do których uzyskał dostęp.
Ale jeśli programiści nie określą jasno określonych granic między danymi a działaniami wykonywanymi w różnych aspektach aplikacji, aplikacja ma lukę w hermetyzacji. Atakujący wykorzystują to, wysyłając żądanie do aplikacji, wiedząc, że takie działanie spowoduje wyświetlenie komunikatu o błędzie. Ten komunikat o błędzie dostarcza wtedy informacji dotyczących struktury aplikacji, wspomagając więcej strategii ataku, takich jak DOS – odmowa usługi.
Niezabezpieczone bezpośrednie odwołania do obiektów (IDOR)
Adresy URL aplikacji internetowych mogą ujawnić wzorzec lub format stosowany do kierowania użytkowników do lokalizacji pamięci masowej zaplecza. Na przykład adres URL może pokazywać wzorzec/format identyfikatora rekordu w systemie pamięci masowej, takim jak system plików lub baza danych.
Sam IDOR może być problemem niskiego ryzyka. Jednak, gdy IDOR jest połączony z nieudanym sprawdzeniem kontroli dostępu, atakujący mają szansę na pomyślne uderzenie.
Inne typowe luki w aplikacjach internetowych, o których powinieneś wiedzieć, to:
Podział odpowiedzi HTTP
Jest to rodzaj ataku wstrzykiwania CRLF. HTTP to proces, w którym przeglądarki wysyłają zapytania, a serwery odsyłają odpowiedzi. W tej luce aplikacji internetowej złośliwi atakujący wykorzystują notacje CR i LR w celu manipulowania sposobem komunikowania się przeglądarek i serwerów, które dostarczają żądanie, ale nakazują serwerowi „podzielić” odpowiedź na różne części. Podzielenie odpowiedzi na dwie różne części umożliwia złośliwemu podmiotowi przejęcie kontroli nad informacjami dostarczanymi przez serwer w odpowiedzi na drugą część żądania. Gdy takie żądane dane są danymi ID użytkownika lub informacjami poufnymi, złośliwy gracz pomyślnie przeprowadził atak.
Wada wtrysku
Wada wstrzyknięcia umożliwia mnóstwo różnych technik ataku. Każda aplikacja, która pozwala użytkownikom aktualizować polecenie powłoki, wywołanie systemu operacyjnego lub bazę danych, może mieć wadę wstrzyknięcia. Złośliwi atakujący wykorzystują wady wstrzyknięć, aby zmienić polecenia, które rozwijają się w nowe i nieoczekiwane działania w aplikacji. Wykorzystując te luki, złośliwi aktorzy mogą tworzyć, aktualizować, odczytywać, a nawet usuwać dane.
Niebezpieczna luka w zabezpieczeniach wiadomości
Jest to luka kryptograficzna, która ogranicza skuteczność szyfrowania. Skrót wiadomości powinien zawierać kryptograficzną funkcję skrótu. W przeciwieństwie do szyfrowania, funkcje skrótu nie wymagają od nadawcy i użytkowników używania kluczy.
W ten sposób złośliwi napastnicy wykorzystują luki w zabezpieczeniach funkcji digest, aby utrwalać „atak z kolizjami haszowymi”. Celem ataku jest sprawdzenie, czy wysłanie danych wejściowych prowadzi do wygenerowania zduplikowanego skrótu. Jeśli złośliwe działanie wymusza wygenerowanie udostępnionego skrótu, może użyć tego skrótu do przedstawienia złośliwego pliku do pobrania. To z kolei pozostawia użytkownikowi końcowemu założenie, że plik jest zgodny z prawem.
Niewystarczająca ochrona warstwy transportowej
Transport Layer Security (TLS) odnosi się do procesu, dzięki któremu aplikacje komputerowe są w stanie bezpiecznie „komunikować się” ze sobą w Internecie. Wiele aplikacji wykorzystuje TLS tylko podczas procesu uwierzytelniania, co naraża dane i informacje o sesji ID, gdy dana osoba korzysta z aplikacji.
Atakujący mogą wykorzystać tę lukę w zabezpieczeniach do przekierowywania danych przesyłanych przez Internet między urządzeniem użytkownika a serwerem aplikacji.
Zdalne wykonanie kodu (RCE)
Luki w zabezpieczeniach umożliwiające zdalne wykonanie kodu to błędy kodowania w aplikacjach internetowych, które umożliwiają złośliwym napastnikom wstawienie kodu niezależnie od ich lokalizacji geograficznej. RCE należą do szerszej kategorii podatności na wstrzykiwanie aplikacji internetowych, w których atakujący wprowadzają własny kod do aplikacji, która nie potwierdzi danych wprowadzonych przez użytkownika, przez co serwer postrzega go jako prawdziwy kod aplikacji. Zazwyczaj złośliwi atakujący wykorzystują niezałatane powszechnie znane luki w zabezpieczeniach i wstawiają swój kod do aplikacji.
Zdalne włączanie plików (RFI)
Aby połączyć wspólne katalogi z aplikacją, programiści dodają w swoim kodzie instrukcje „include”. Na przykład aplikacja może być zmuszona do pobierania danych z bazy danych. Zamiast kodować go ręcznie, aby pobrać każdy plik, instrukcja „include” pomaga połączyć cały katalog źródłowy, aby można było użyć wszystkiego, co tam przechowywane.
Gdy w aplikacji internetowej występuje luka w zabezpieczeniach RFI, osoby atakujące mogą manipulować nią w celu przesłania złośliwego kodu lub złośliwego oprogramowania do bazy danych, serwera lub witryny internetowej.
Błędna konfiguracja zabezpieczeń
Prawdopodobieństwo błędnej konfiguracji zabezpieczeń jest rzeczywiście jedną z najczęstszych luk w aplikacjach internetowych . Ta luka występuje zazwyczaj z powodu niezmodyfikowania przez organizację domyślnych ustawień zabezpieczeń. Typowe błędy konfiguracji zabezpieczeń to:
- Korzystanie z domyślnych haseł lub kont
- Oprogramowanie bez łatek
- Brak szyfrowania
- Nieodpowiednie zasady dotyczące zapory
- Zaniedbywanie nieużywanych, zasobów, funkcji i innych komponentów
Wstrzyknięcie SQL
SQL, co oznacza Structured Query Language, to język programowania używany w bazach danych. Pozwala na pobieranie i manipulowanie danymi dla relacyjnych baz danych. Podatność na wstrzyknięcie SQL znajduje się w większej grupie niezweryfikowanych danych wejściowych użytkownika. Gdy złośliwi aktorzy celowo wysyłają fałszywe żądania, aplikacja internetowa odpowiada komunikatem o błędzie, który dostarcza im informacji o strukturze i ochronie bazy danych.
Niezatwierdzona automatyczna aktywacja biblioteki
Aby zaoszczędzić czas podczas kodowania, programiści zwykle korzystają z bibliotek innych firm. W większości przypadków pozwala im to na wykorzystanie wstępnie przetestowanego kodu, który przyspiesza proces tworzenia aplikacji. Korzystanie z publicznie dostępnego kodu o otwartym kodzie źródłowym zwiększa jednak zagrożenia bezpieczeństwa, w tym:
- Brak udokumentowanego prawa własności zwiększa ryzyko dodania złośliwego kodu
- Zaniedbane projekty, które nie są już aktualizowane
Ta szczególna luka jest coraz bardziej powszechna, biorąc pod uwagę, że kilka aplikacji korzysta z zależności bibliotecznych innych firm.
Mamy nadzieję, że treść tego wpisu na blogu rzeczywiście była dla Ciebie użyteczna i wnikliwa. Upewnienie się, że znajdziesz rozwiązanie każdej luki w zabezpieczeniach aplikacji internetowej, która ma zastosowanie w Twoim przypadku, będzie przełomem w doświadczeniach pracowników i klientów.