Aplikacje internetowe, z racji swojej dostępności dla szerokiego grona internautów, są ciągle narażone na działania osób o nieuczciwych zamiarach. Wielu użytkowników sieci próbuje wykorzystać luki w zabezpieczeniach z różnych pobudek.
W początkowych latach istnienia Internetu najpopularniejszą metodą ataków było tzw. „brute-force”, czyli siłowe przełamywanie zabezpieczeń. Zazwyczaj boty lub osoby z dużą ilością wolnego czasu testowały miliony kombinacji nazw użytkowników i haseł, aż znalazły te, które umożliwiały dostęp do docelowej aplikacji.
Dzięki wprowadzeniu polityki silnych haseł, ograniczeniu liczby prób logowania oraz mechanizmom captcha, ataki siłowe straciły na znaczeniu. Jednak cyberprzestępcy nieustannie poszukują nowych sposobów na wykorzystanie luk w systemach. Szybko odkryli, że pola tekstowe w aplikacjach i na stronach internetowych mogą posłużyć do wprowadzenia nieoczekiwanego tekstu. Ten złośliwy wkład, zwany iniekcją, może spowodować, że aplikacja wykona działania, do których nie została zaprojektowana. W ten sposób narodziły się ataki iniekcyjne.
Ataki iniekcyjne mogą służyć nie tylko do uzyskania nieautoryzowanego dostępu do aplikacji, lecz także do ujawnienia prywatnych danych, przejęcia kontroli nad serwerem, a w konsekwencji mogą mieć wpływ na inne powiązane usługi i aplikacje. Stanowią więc poważne zagrożenie zarówno dla aplikacji, jak i dla jej użytkowników.
Wstrzykiwanie kodu
Wstrzykiwanie kodu jest często stosowaną formą ataku iniekcyjnego. Atakujący, znając język programowania, strukturę, bazę danych lub system operacyjny aplikacji, może wprowadzić złośliwy kod za pośrednictwem pól tekstowych. W efekcie serwer internetowy zostaje zmuszony do wykonania nieautoryzowanych działań.
Ten typ ataku jest możliwy w przypadku aplikacji, które nie weryfikują poprawności danych wprowadzanych przez użytkownika. Jeśli pole tekstowe akceptuje dowolne dane, aplikacja staje się podatna na ataki. Aby im zapobiec, aplikacja musi ograniczyć możliwości wprowadzania danych przez użytkownika.
Przykładowo, konieczne jest ograniczenie ilości oczekiwanych danych, sprawdzenie ich formatu przed akceptacją oraz ograniczenie zestawu dozwolonych znaków.
Luki związane z wstrzykiwaniem kodu są stosunkowo łatwe do zidentyfikowania poprzez testowanie różnych typów danych wprowadzanych do aplikacji. Ich wykorzystanie bywa bardziej skomplikowane. Jednak, gdy atakującemu uda się wykorzystać taką lukę, skutki mogą obejmować utratę poufności, integralności, dostępności lub funkcjonalności aplikacji.
Wstrzykiwanie SQL
Atak ten, podobnie jak wstrzykiwanie kodu, polega na wstawieniu skryptu SQL – języka używanego przez większość baz danych – w polu tekstowym. Skrypt jest wysyłany do aplikacji, która wykonuje go bezpośrednio w bazie danych. W efekcie atakujący może obejść zabezpieczenia logowania lub wykonać niebezpieczne operacje, takie jak odczyt, modyfikacja lub zniszczenie danych, a nawet wykonanie operacji administracyjnych na bazie danych.
Aplikacje oparte na PHP i ASP są bardziej podatne na ataki SQL injection ze względu na starsze interfejsy funkcyjne. Aplikacje J2EE i ASP.Net są zazwyczaj lepiej zabezpieczone przed tymi zagrożeniami. Potencjalne skutki ataku SQL injection, raz wykrytej luki, są ograniczone tylko umiejętnościami i wyobraźnią osoby atakującej. Niewątpliwie jest to zagrożenie o dużym potencjale destrukcyjnym.
Wstrzykiwanie poleceń
Ataki te, podobnie jak poprzednie, są możliwe z powodu niewystarczającej weryfikacji wprowadzanych danych. Różnią się od wstrzykiwania kodu tym, że atakujący wprowadza polecenia systemowe zamiast fragmentów kodu programistycznego. Atakujący nie musi znać języka programowania ani języka bazy danych, ale musi znać system operacyjny serwera.
Wstawione polecenia są wykonywane przez system operacyjny z uprawnieniami aplikacji, co może skutkować ujawnieniem zawartości plików, struktury katalogów serwera, a nawet zmianą haseł użytkowników.
Administrator systemu może zapobiec tym atakom poprzez ograniczenie poziomu dostępu aplikacji internetowych działających na serwerze.
Skrypty między witrynami (XSS)
Aplikacja, która wstawia dane wprowadzone przez użytkownika do generowanych przez siebie danych wyjściowych bez ich weryfikacji, stwarza możliwość ataku XSS (Cross-Site Scripting). W ten sposób atakujący może wstrzyknąć złośliwy kod na zaufaną stronę internetową, który następnie trafia do innych użytkowników.
Przeglądarka ofiary wykonuje złośliwy skrypt, nie zdając sobie sprawy z zagrożenia. W konsekwencji skrypt uzyskuje dostęp do tokenów sesji, plików cookie lub innych poufnych informacji. Odpowiednio zaprogramowany skrypt może nawet zmodyfikować zawartość pliku HTML.
Ataki XSS dzielą się na dwie kategorie: przechowywane i odbijane.
W przypadku przechowywanych ataków XSS złośliwy skrypt jest trwale umieszczony na serwerze docelowym, na przykład na forum dyskusyjnym. Ofiara otrzymuje go w momencie, gdy przeglądarka zażąda tych informacji. W odbitych atakach XSS skrypt jest „odbijany” w odpowiedzi serwera, np. w komunikacie o błędzie.
Wstrzykiwanie XPath
Ten typ ataku jest możliwy, gdy aplikacja internetowa wykorzystuje dane wprowadzone przez użytkownika do budowy zapytania XPath dla danych XML. Atakujący wprowadza zniekształcone dane, aby poznać strukturę danych XML, a następnie uzyskuje do nich nieautoryzowany dostęp.
XPath jest językiem, w którym, podobnie jak w SQL, można określić atrybuty, które chcemy znaleźć. Aplikacje internetowe wykorzystują dane wprowadzone przez użytkownika do ustawienia wzorca, do którego powinny pasować dane XML. Poprzez wprowadzenie zniekształconych danych wzorzec może przekształcić się w operację, którą atakujący chce wykonać.
W przeciwieństwie do SQL, nie ma różnych wersji XPath, co oznacza, że wstrzykiwanie XPath można wykonać w każdej aplikacji korzystającej z danych XML, niezależnie od implementacji. Atak taki można łatwo zautomatyzować.
Wstrzykiwanie poleceń poczty
Ten rodzaj ataku wykorzystuje serwery poczty e-mail oraz aplikacje, które budują instrukcje IMAP lub SMTP przy użyciu niezweryfikowanych danych. Serwery IMAP i SMTP bywają mniej chronione niż serwery internetowe, co czyni je bardziej podatnymi na ataki. Atakujący, wykorzystując serwer pocztowy, mogą ominąć różne zabezpieczenia.
Do przeprowadzenia ataku za pośrednictwem serwera SMTP atakujący potrzebuje ważnego konta e-mail. Jeśli serwer jest podatny, odpowie na żądania atakujących, pozwalając im wykorzystać jego usługi, na przykład do wysyłania spamu.
Wstrzykiwanie IMAP najczęściej odbywa się w aplikacjach poczty internetowej, wykorzystując funkcję odczytu wiadomości. Atak można przeprowadzić, wprowadzając adres URL z wstrzykniętymi poleceniami w pasku adresu przeglądarki.
Wstrzykiwanie CRLF
Wprowadzenie kombinacji znaków powrotu karetki i nowego wiersza (CRLF) w polach wejściowych formularza internetowego jest metodą ataku zwaną iniekcją CRLF. Znaki te wskazują koniec linii lub polecenia w protokołach internetowych, takich jak HTTP.
Na przykład wprowadzenie CRLF do żądania HTTP, a następnie określonego kodu HTML, może spowodować wyświetlenie nieautoryzowanej strony internetowej.
Atak ten jest możliwy w przypadku aplikacji, które nie filtrują poprawnie danych wprowadzanych przez użytkownika. Luka ta otwiera drogę do innych ataków, takich jak XSS i wstrzykiwanie kodu.
Wstrzykiwanie nagłówka hosta
W przypadku serwerów obsługujących wiele stron internetowych nagłówek hosta jest niezbędny do określenia, która witryna lub aplikacja ma obsłużyć przychodzące żądanie. Wartość nagłówka informuje serwer, do którego hosta wirtualnego przesłać żądanie. Nieprawidłowy nagłówek hosta często jest kierowany do pierwszego hosta wirtualnego na liście, co stanowi lukę, którą atakujący mogą wykorzystać.
Manipulacja nagłówkiem hosta jest częsta w aplikacjach PHP, choć można ją przeprowadzić również w innych technologiach. Ataki nagłówka hosta mogą prowadzić do innych rodzajów ataków, takich jak zatruwanie pamięci podręcznej sieci i mogą umożliwiać nieautoryzowane działania, np. resetowanie hasła.
Wstrzykiwanie LDAP
LDAP jest protokołem ułatwiającym wyszukiwanie zasobów w sieci. Jest on przydatny w intranetach i systemach pojedynczego logowania do przechowywania nazw użytkowników i haseł. Zapytania LDAP wymagają użycia specjalnych znaków sterujących. Atakujący może zmienić zachowanie zapytania LDAP, wstawiając do niego takie znaki.
Podstawowym problemem umożliwiającym ataki LDAP jest nieprawidłowa weryfikacja danych wprowadzanych przez użytkownika. Jeśli tekst wysłany przez użytkownika jest używany jako część zapytania LDAP bez odpowiedniego oczyszczenia, zapytanie może skutkować np. wyświetleniem listy wszystkich użytkowników.
Zapobieganie atakom iniekcyjnym
Jak omówiono w tym artykule, ataki iniekcyjne są skierowane przeciwko serwerom i aplikacjom dostępnym publicznie w Internecie. Odpowiedzialność za zapobieganie tym atakom spoczywa na deweloperach aplikacji i administratorach serwerów.
Programiści muszą być świadomi ryzyka związanego z nieprawidłową weryfikacją danych wejściowych i stosować najlepsze praktyki w zakresie ich oczyszczania. Administratorzy serwerów powinni regularnie przeprowadzać audyty systemów w celu wykrywania i naprawiania luk w zabezpieczeniach. Istnieje wiele narzędzi wspomagających te działania, zarówno na żądanie, jak i automatycznie.
newsblog.pl