co to jest CRLF?

gdy przeglądarka wysyła żądanie do serwera sieci web, serwer sieci Web odpowie z odpowiedzią zawierającą zarówno nagłówki odpowiedzi HTTP, jak i rzeczywistą zawartość witryny, tj. treść odpowiedzi. Nagłówki HTTP i odpowiedź HTML (zawartość witryny) są oddzielone specjalną kombinacją znaków specjalnych, a mianowicie zwrot karetki i kanał liniowy. W skrócie są one również znane jako CRLF.

serwer WWW używa CRLF do zrozumienia, kiedy zaczyna się nowy nagłówek HTTP, a kończy kolejny. CRLF może również powiedzieć aplikacji internetowej lub użytkownikowi, że nowa linia zaczyna się w pliku lub w bloku tekstowym. Znaki CRLF są standardowym Komunikatem HTTP / 1.1, więc jest używany przez każdy typ serwera www, w tym Apache, Microsoft IIS i wszystkie inne.

co to jest luka CRLF Injection?

w ataku na lukę CRLF injection atakujący wstawia zarówno znak powrotu karetki, jak i znak linefeed do danych wejściowych użytkownika, aby nakłonić serwer, aplikację internetową lub użytkownika do myślenia, że obiekt został zakończony, a inny uruchomiony. Jako takie sekwencje CRLF nie są złośliwymi znakami, jednak mogą być używane do złośliwych intencji, do dzielenia odpowiedzi HTTP itp.

Wtrysk CRLF w aplikacjach internetowych

w aplikacjach internetowych Wtrysk CRLF może mieć poważne skutki, w zależności od tego, co aplikacja robi z pojedynczymi elementami. Wpływ może sięgać od ujawnienia informacji po wykonanie kodu, co bezpośrednio wpływa na luki w zabezpieczeniach aplikacji internetowych. W rzeczywistości atak wtrysku CRLF może mieć bardzo poważne konsekwencje dla aplikacji internetowej, mimo że nigdy nie był wymieniony na liście OWASP Top 10. Na przykład możliwe jest również manipulowanie plikami dziennika w panelu administracyjnym, jak wyjaśniono w poniższym przykładzie.

przykład wtrysku CRLF w pliku dziennika

wyobraź sobie plik dziennika w panelu administracyjnym z wzorem strumienia wyjściowego ścieżki IP – Time-Visited, taki jak poniżej:

123.123.123.123 - 08:15 - /index.php?page=home

Jeśli atakujący jest w stanie wprowadzić znaki CRLF do żądania HTTP, jest w stanie zmienić strumień wyjściowy i sfałszować wpisy dziennika. Może zmienić odpowiedź z aplikacji webs na coś takiego jak poniżej:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

%0D i %0a są zakodowanymi URL formami CR i LF. Dlatego wpisy dziennika będą wyglądać tak po tym, jak atakujący wstawił te znaki, a aplikacja je wyświetli:

Ip – Time-Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

dlatego wykorzystując lukę CRLF injection, atakujący może sfałszować wpisy w pliku dziennika, aby ukryć swoje złośliwe działania. Atakujący dosłownie porywa stronę i modyfikuje odpowiedź. Na przykład wyobraź sobie scenariusz, w którym atakujący ma hasło administratora i wykonuje parametr restrictedaction, który może być używany tylko przez administratora.

problem polega na tym, że jeśli administrator zauważy, że Nieznany IP użył parametru restrictedaction, zauważy, że coś jest nie tak. Jednak, ponieważ teraz wygląda na to, że polecenie zostało wydane przez localhost (a zatem prawdopodobnie przez kogoś, kto ma dostęp do serwera, jak admin), nie wygląda to podejrzanie.

cała część zapytania zaczynająca się od %0d%0a będzie obsługiwana przez serwer jako jeden parametr. Następnie znajduje się inny & z parametrem restrictedactionktóry będzie parsowany przez serwer jako kolejny parametr. W praktyce byłoby to takie samo zapytanie jak:

/index.php?page=home&restrictedaction=edit

podział odpowiedzi HTTP

opis

ponieważ nagłówek odpowiedzi HTTP i jej treść są oddzielone znakami CRLF, atakujący może spróbować je wstrzyknąć. Kombinacja CRLFCRLF poinformuje przeglądarkę, że nagłówek się kończy i zaczyna się treść. Oznacza to, że jest on teraz w stanie zapisywać dane wewnątrz ciała odpowiedzi, w którym przechowywany jest kod html. Może to prowadzić do luki w skryptach między witrynami.

przykład podziału odpowiedzi HTTP prowadzącego do XSS

wyobraź sobie aplikację, która ustawia niestandardowy nagłówek, na przykład:

X-Your-Name: Bob

wartość nagłówka jest ustawiana za pomocą parametru get o nazwie „name”. Jeśli nie ma kodowania URL i wartość jest bezpośrednio odzwierciedlona w nagłówku, atakujący może wstawić wyżej wspomnianą kombinację CRLFCRLF, aby poinformować przeglądarkę, że zaczyna się treść żądania. W ten sposób jest w stanie wstawić dane takie jak XSS payload, na przykład:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

powyższe wyświetli okno alertu w kontekście zaatakowanej domeny.

HTTP Header Injection

opis

wykorzystując wstrzyknięcie CRLF, atakujący może również wstawić nagłówki HTTP, które mogą być użyte do pokonania mechanizmów bezpieczeństwa, takich jak filtr XSS przeglądarki lub zasady tego samego pochodzenia. Pozwala to atakującemu uzyskać poufne informacje, takie jak tokeny CSRF. Może również ustawić pliki cookie, które można wykorzystać, logując ofiarę na koncie atakującego lub wykorzystując w inny sposób niewykorzystywalne luki w zabezpieczeniach cross-Site scripting (XSS).

przykład wtrysku nagłówka HTTP w celu wyodrębnienia poufnych danych

Jeśli atakujący jest w stanie wstrzyknąć nagłówki HTTP, które aktywują CORS (Cross Origin Resource Sharing), może użyć javascript, aby uzyskać dostęp do zasobów, które są w inny sposób chronione przez SOP (Same Origin Policy), co uniemożliwia stronom z różnych źródeł dostęp do siebie.

wpływ luki w wstrzykiwaniu CRLF

wpływ wstrzyknięć CRLF jest różny, a także obejmuje wszystkie skutki skryptów Cross-site do ujawnienia informacji. Może również dezaktywować pewne ograniczenia bezpieczeństwa, takie jak filtry XSS i te same zasady pochodzenia w przeglądarkach ofiary, pozostawiając je podatne na złośliwe ataki.

jak zapobiegać wstrzykiwaniu nagłówków CRLF / HTTP w aplikacjach internetowych

najlepszą techniką zapobiegania jest nieużywanie danych wejściowych użytkowników bezpośrednio w nagłówkach odpowiedzi. Jeśli nie jest to możliwe, zawsze należy używać funkcji do kodowania znaków specjalnych CRLF. Kolejną dobrą praktyką w zakresie bezpieczeństwa aplikacji internetowych jest aktualizacja języka programowania do wersji, która nie pozwala na wstrzykiwanie CR i LF wewnątrz funkcji ustawiających nagłówki HTTP.

Klasyfikacja podatności I Tabela ciężkości