9 popularnych typów ataków polegających na wstrzykiwaniu aplikacji internetowych

Problem z aplikacjami internetowymi polega na tym, że są one otwarcie narażone na kontakt z miliardami użytkowników Internetu, z których wielu będzie chciało złamać zabezpieczenia – z jakichkolwiek powodów.

We wczesnych latach Internetu jedną z najczęstszych metod ataku była prosta, prosta siła. Boty zwykle przeprowadzały te ataki – lub osoby mające dużo wolnego czasu – które wypróbowywały miliony kombinacji nazw użytkowników i haseł, aż znalazły takie, które zapewniało dostęp do docelowej aplikacji.

Ataki siłowe nie stanowią już zagrożenia dzięki polityce haseł, ograniczonym próbom logowania i captchas. Ale cyberprzestępcy uwielbiają odkrywać nowe exploity i wykorzystywać je do przeprowadzania nowych typów ataków. Dawno temu odkryli, że pola tekstowe w aplikacjach lub na stronach internetowych można wykorzystać, wprowadzając do nich – lub wstrzykując – nieoczekiwany tekst, który zmusi aplikację do zrobienia czegoś, czego nie powinna. W ten sposób na scenę wkroczyły tak zwane ataki iniekcyjne.

Ataki typu „injection” mogą służyć nie tylko do logowania się do aplikacji bez znajomości nazwy użytkownika i hasła, ale także do ujawnienia prywatnych, poufnych lub wrażliwych informacji, a nawet do przejęcia kontroli nad całym serwerem. Dlatego te ataki stanowią zagrożenie nie tylko dla aplikacji internetowych, ale także dla użytkowników, których dane znajdują się w tych aplikacjach, aw najgorszych przypadkach dla innych połączonych aplikacji i usług.

Wstrzyknięcie kodu

Wstrzykiwanie kodu jest jednym z najczęstszych rodzajów ataków polegających na wstrzykiwaniu kodu. Jeśli atakujący znają język programowania, strukturę, bazę danych lub system operacyjny używany przez aplikację internetową, mogą wstrzyknąć kod za pomocą pól tekstowych, aby zmusić serwer WWW do wykonania tego, co chcą.

Tego typu ataki polegające na wstrzykiwaniu są możliwe w przypadku aplikacji, które nie mają możliwości sprawdzania poprawności danych wejściowych. Jeśli pole wprowadzania tekstu pozwala użytkownikom na wprowadzanie dowolnych treści, aplikacja może być potencjalnie wykorzystana. Aby zapobiec tym atakom, aplikacja musi maksymalnie ograniczyć dostęp użytkowników do danych wejściowych.

Na przykład musi ograniczyć ilość oczekiwanych danych, sprawdzić format danych przed ich zaakceptowaniem i ograniczyć zestaw dozwolonych znaków.

Luki w zabezpieczeniach związane z wstrzyknięciem kodu można łatwo znaleźć, po prostu testując wprowadzanie tekstu w aplikacji internetowej z różnymi typami treści. Po znalezieniu luki w zabezpieczeniach są średnio trudne do wykorzystania. Jednak gdy atakującemu uda się wykorzystać jedną z tych luk, wpływ może obejmować utratę poufności, integralności, dostępności lub funkcjonalności aplikacji.

wstrzyknięcie SQL

W sposób podobny do wstrzyknięcia kodu atak ten polega na wstawieniu skryptu SQL — języka używanego przez większość baz danych do wykonywania operacji zapytań — w polu wprowadzania tekstu. Skrypt jest wysyłany do aplikacji, która wykonuje go bezpośrednio w swojej bazie danych. W rezultacie osoba atakująca może przejść przez ekran logowania lub wykonać bardziej niebezpieczne czynności, takie jak odczyt poufnych danych bezpośrednio z bazy danych, zmodyfikowanie lub zniszczenie danych bazy danych lub wykonanie operacji administracyjnych na bazie danych.

Aplikacje PHP i ASP są podatne na ataki typu SQL injection ze względu na starsze interfejsy funkcjonalne. Aplikacje J2EE i ASP.Net są zwykle lepiej chronione przed tymi atakami. Gdy zostanie wykryta luka umożliwiająca wstrzyknięcie kodu SQL — a można je łatwo znaleźć — skala potencjalnych ataków będzie ograniczona jedynie umiejętnościami i wyobraźnią osoby atakującej. Zatem wpływ ataku typu SQL injection jest niewątpliwie duży.

Wstrzyknięcie polecenia

Ataki te są również możliwe, głównie ze względu na niewystarczającą weryfikację danych wejściowych. Różnią się one od ataków polegających na wstrzykiwaniu kodu tym, że osoba atakująca wstawia polecenia systemowe zamiast fragmentów kodu programistycznego lub skryptów. Dlatego haker nie musi znać języka programowania, w którym oparta jest aplikacja ani języka używanego przez bazę danych. Muszą jednak znać system operacyjny używany przez serwer hostingowy.

Wstawione polecenia systemowe są wykonywane przez system operacyjny hosta z uprawnieniami aplikacji, co może pozwolić m.in. na ujawnienie zawartości dowolnych plików rezydujących na serwerze, pokazanie struktury katalogów serwera, zmianę haseł użytkowników .

Atakom tym może zapobiec administrator systemu, ograniczając poziom dostępu do systemu aplikacji internetowych działających na serwerze.

Skrypty między witrynami

Za każdym razem, gdy aplikacja wstawia dane wejściowe od użytkownika do generowanych przez siebie danych wyjściowych, bez ich sprawdzania poprawności lub kodowania, daje atakującemu możliwość wysłania złośliwego kodu do innego użytkownika końcowego. Ataki Cross-Site Scripting (XSS) wykorzystują te możliwości do wstrzykiwania złośliwych skryptów do zaufanych stron internetowych, które ostatecznie są wysyłane do innych użytkowników aplikacji, którzy stają się ofiarami atakującego.

Przeglądarka ofiary wykona złośliwy skrypt, nie wiedząc, że nie należy mu ufać. W związku z tym przeglądarka umożliwi jej dostęp do tokenów sesji, plików cookie lub poufnych informacji przechowywanych przez przeglądarkę. Odpowiednio zaprogramowane skrypty mogłyby nawet przepisać zawartość pliku HTML.

Ataki XSS można ogólnie podzielić na dwie różne kategorie: przechowywane i odbijane.

W przypadku ataków XSS z przechowywanymi plikami złośliwy skrypt rezyduje na stałe na docelowym serwerze, na forum dyskusyjnym, w bazie danych, w dzienniku odwiedzin itp. Ofiara otrzymuje go, gdy jej przeglądarka zażąda przechowywanych informacji. W odbitych atakach XSS złośliwy skrypt jest odzwierciedlany w odpowiedzi zawierającej dane wejściowe wysyłane do serwera. Może to być na przykład komunikat o błędzie lub wynik wyszukiwania.

Wstrzyknięcie XPath

Ten typ ataku jest możliwy, gdy aplikacja internetowa wykorzystuje informacje dostarczone przez użytkownika do zbudowania zapytania XPath dla danych XML. Sposób działania tego ataku jest podobny do iniekcji SQL: atakujący wysyłają zniekształcone informacje do aplikacji, aby dowiedzieć się, jaka jest struktura danych XML, a następnie atakują ponownie, aby uzyskać dostęp do tych danych.

XPath to standardowy język, w którym, podobnie jak SQL, możesz określić atrybuty, które chcesz znaleźć. Aby wykonać zapytanie dotyczące danych XML, aplikacje internetowe używają danych wprowadzonych przez użytkownika do ustawienia wzorca, do którego dane powinny pasować. Wysyłając zniekształcone dane wejściowe, wzorzec może przekształcić się w operację, którą atakujący chce zastosować do danych.

W przeciwieństwie do tego, co dzieje się z SQL, w XPath nie ma różnych wersji. Oznacza to, że wstrzykiwanie XPath można wykonać w dowolnej aplikacji internetowej korzystającej z danych XML, niezależnie od implementacji. Oznacza to również, że atak można zautomatyzować; dlatego, w przeciwieństwie do wstrzykiwania SQL, może zostać wystrzelony przeciwko dowolnej liczbie celów.

Wstrzykiwanie poleceń poczty

Ta metoda ataku może zostać wykorzystana do wykorzystania serwerów poczty e-mail i aplikacji, które budują instrukcje IMAP lub SMTP przy użyciu niewłaściwie zweryfikowanych danych wprowadzonych przez użytkownika. Czasami serwery IMAP i SMTP nie mają silnej ochrony przed atakami, jak ma to miejsce w przypadku większości serwerów internetowych, i dlatego mogą być bardziej podatne na ataki. Wchodząc przez serwer pocztowy, osoby atakujące mogą ominąć ograniczenia, takie jak captchas, ograniczona liczba żądań itp.

Aby wykorzystać serwer SMTP, osoby atakujące potrzebują ważnego konta e-mail do wysyłania wiadomości z wprowadzonymi poleceniami. Jeśli serwer jest podatny na ataki, odpowie na żądania atakujących, umożliwiając im na przykład obejście ograniczeń serwera i wykorzystanie jego usług do wysyłania spamu.

Wstrzyknięcie IMAP można było wykonać głównie w aplikacjach poczty internetowej, wykorzystując funkcję odczytu wiadomości. W takich przypadkach atak można przeprowadzić po prostu wpisując w pasku adresu przeglądarki internetowej adres URL z wstrzykniętymi poleceniami.

Wstrzyknięcie CRLF

Wstawianie znaków powrotu karetki i nowego wiersza – kombinacji znanej jako CRLF – w polach wejściowych formularza internetowego reprezentuje metodę ataku zwaną wtryskiem CRLF. Te niewidoczne znaki wskazują koniec linii lub koniec polecenia w wielu tradycyjnych protokołach internetowych, takich jak HTTP, MIME lub NNTP.

Na przykład wstawienie CRLF do żądania HTTP, po którym następuje określony kod HTML, może spowodować wysłanie niestandardowych stron internetowych do odwiedzających witrynę.

Atak ten można przeprowadzić na wrażliwych aplikacjach internetowych, które nie stosują odpowiedniego filtrowania danych wejściowych użytkownika. Ta luka w zabezpieczeniach otwiera drzwi do innych typów ataków polegających na wstrzykiwaniu, takich jak XSS i wstrzykiwanie kodu, a także może wynikać z przejęcia witryny.

Wstrzyknięcie nagłówka hosta

Na serwerach obsługujących wiele stron internetowych lub aplikacji internetowych nagłówek hosta staje się niezbędny do określenia, które z rezydentnych witryn internetowych lub aplikacji internetowych — z których każda nazywana jest hostem wirtualnym — powinny przetworzyć przychodzące żądanie. Wartość nagłówka informuje serwer, do którego wirtualnego hosta wysłać żądanie. Gdy serwer otrzyma nieprawidłowy nagłówek hosta, zwykle przekazuje go do pierwszego hosta wirtualnego na liście. Stanowi to lukę, którą atakujący mogą wykorzystać do wysłania dowolnych nagłówków hosta do pierwszego hosta wirtualnego na serwerze.

Manipulowanie nagłówkiem hosta jest zwykle związane z aplikacjami PHP, chociaż można to również zrobić za pomocą innych technologii tworzenia stron internetowych. Ataki nagłówka hosta umożliwiają inne rodzaje ataków, takie jak zatruwanie pamięci podręcznej sieci. Jego konsekwencją może być wykonanie przez atakujących wrażliwych operacji, na przykład zresetowanie hasła.

wstrzyknięcie LDAP

LDAP to protokół zaprojektowany w celu ułatwienia wyszukiwania zasobów (urządzeń, plików, innych użytkowników) w sieci. Jest bardzo przydatny w intranetach, a gdy jest używany jako część systemu pojedynczego logowania, może służyć do przechowywania nazw użytkowników i haseł. Zapytania LDAP wymagają użycia specjalnych znaków sterujących, które wpływają na jego sterowanie. Osoby atakujące mogą potencjalnie zmienić zamierzone zachowanie zapytania LDAP, jeśli mogą wstawić do niego znaki kontrolne.

Ponownie głównym problemem, który pozwala na ataki polegające na wstrzykiwaniu LDAP, jest niewłaściwie zweryfikowane dane wprowadzane przez użytkownika. Jeśli tekst wysyłany przez użytkownika do aplikacji jest używany jako część zapytania LDAP bez jego oczyszczania, zapytanie może zakończyć się pobraniem listy wszystkich użytkowników i wyświetleniem jej atakującemu, po prostu za pomocą gwiazdki

we właściwym miejscu wewnątrz ciągu wejściowego.

Zapobieganie atakom iniekcyjnym

Jak widzieliśmy w tym artykule, wszystkie ataki polegające na wstrzyknięciu są skierowane na serwery i aplikacje z otwartym dostępem dla dowolnego użytkownika Internetu. Odpowiedzialność za zapobieganie tym atakom spoczywa na programistach aplikacji i administratorach serwerów.