CRLF (%0D%0A) Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Bug bounty tip: zarejestruj się w Intigriti, premium platformie bug bounty stworzonej przez hackerów, dla hackerów! Dołącz do nas na https://go.intigriti.com/hacktricks już dziś i zacznij zarabiać nagrody do 100 000 USD!
Carriage Return (CR) i Line Feed (LF), znane łącznie jako CRLF, to specjalne sekwencje znaków używane w protokole HTTP do oznaczania końca linii lub początku nowej. Serwery internetowe i przeglądarki używają CRLF do rozróżniania między nagłówkami HTTP a treścią odpowiedzi. Te znaki są powszechnie stosowane w komunikacji HTTP/1.1 w różnych typach serwerów internetowych, takich jak Apache i Microsoft IIS.
CRLF injection polega na wstawieniu znaków CR i LF do danych wejściowych dostarczonych przez użytkownika. Działanie to wprowadza w błąd serwer, aplikację lub użytkownika, sprawiając, że interpretują wstrzykniętą sekwencję jako koniec jednej odpowiedzi i początek innej. Chociaż te znaki nie są z natury szkodliwe, ich niewłaściwe użycie może prowadzić do dzielenia odpowiedzi HTTP i innych złośliwych działań.
Rozważ plik dziennika w panelu administracyjnym, który ma format: IP - Czas - Odwiedzona Ścieżka. Typowy wpis może wyglądać następująco:
Atakujący może wykorzystać wstrzyknięcie CRLF do manipulacji tym logiem. Wstrzykując znaki CRLF do żądania HTTP, atakujący może zmienić strumień wyjściowy i sfałszować wpisy w logu. Na przykład, wstrzyknięta sekwencja może przekształcić wpis w logu w:
Tutaj %0d i %0a reprezentują zakodowane w URL formy CR i LF. Po ataku, log wprowadzi w błąd, wyświetlając:
The attacker thus cloaks their malicious activities by making it appear as if the localhost (an entity typically trusted within the server environment) performed the actions. The server interprets the part of the query starting with %0d%0a as a single parameter, while the restrictedaction parameter is parsed as another, separate input. The manipulated query effectively mimics a legitimate administrative command: /index.php?page=home&restrictedaction=edit
HTTP Response Splitting to luka bezpieczeństwa, która powstaje, gdy atakujący wykorzystuje strukturę odpowiedzi HTTP. Ta struktura oddziela nagłówki od treści za pomocą określonej sekwencji znaków, Carriage Return (CR) i Line Feed (LF), zbiorczo określanej jako CRLF. Jeśli atakujący zdoła wstawić sekwencję CRLF do nagłówka odpowiedzi, może skutecznie manipulować dalszą treścią odpowiedzi. Tego rodzaju manipulacja może prowadzić do poważnych problemów z bezpieczeństwem, w szczególności Cross-site Scripting (XSS).
Aplikacja ustawia niestandardowy nagłówek, taki jak: X-Custom-Header: UserInput
Aplikacja pobiera wartość dla UserInput z parametru zapytania, powiedzmy "user_input". W scenariuszach, w których brakuje odpowiedniej walidacji i kodowania wejścia, atakujący może stworzyć ładunek, który zawiera sekwencję CRLF, a następnie złośliwą treść.
Atakujący tworzy URL z specjalnie przygotowanym 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
W tym URL, %0d%0a%0d%0a to URL-encoded forma CRLFCRLF. Oszukuje to serwer, aby wstawić sekwencję CRLF, sprawiając, że serwer traktuje dalszą część jako treść odpowiedzi.
Serwer odzwierciedla dane wejściowe atakującego w nagłówku odpowiedzi, prowadząc do niezamierzonej struktury odpowiedzi, w której złośliwy skrypt jest interpretowany przez przeglądarkę jako część treści odpowiedzi.
Browser to:
A serwer odpowiada nagłówkiem:
Inny przykład: (z https://www.acunetix.com/websitesecurity/crlf-injection/)
Możesz wysłać ładunek wewnątrz ścieżki URL, aby kontrolować odpowiedź z serwera (przykład z tutaj):
Check more examples in:
Wstrzykiwanie nagłówków HTTP, często wykorzystywane poprzez wstrzykiwanie CRLF (Carriage Return and Line Feed), pozwala atakującym na wstawianie nagłówków HTTP. Może to podważyć mechanizmy bezpieczeństwa, takie jak filtry XSS (Cross-Site Scripting) lub SOP (Same-Origin Policy), co potencjalnie prowadzi do nieautoryzowanego dostępu do wrażliwych danych, takich jak tokeny CSRF, lub manipulacji sesjami użytkowników poprzez osadzanie ciasteczek.
Atakujący może wstrzykiwać nagłówki HTTP, aby włączyć CORS (Cross-Origin Resource Sharing), omijając ograniczenia nałożone przez SOP. To naruszenie pozwala skryptom z złośliwych źródeł na interakcję z zasobami z innego źródła, potencjalnie uzyskując dostęp do chronionych danych.
Wstrzykiwanie CRLF może być wykorzystane do stworzenia i wstrzyknięcia całkowicie nowego żądania HTTP. Znaczącym przykładem jest luka w klasie SoapClient w PHP, szczególnie w parametrze user_agent. Manipulując tym parametrem, atakujący może wstawić dodatkowe nagłówki i treść ciała, a nawet wstrzyknąć całkowicie nowe żądanie HTTP. Poniżej znajduje się przykład PHP demonstrujący to wykorzystanie:
Aby uzyskać więcej informacji na temat tej techniki i potencjalnych problemów sprawdź oryginalne źródło.
Możesz wstrzykiwać istotne nagłówki, aby zapewnić, że zaplecze utrzymuje połączenie otwarte po odpowiedzi na początkowe żądanie:
Po tym można określić drugie żądanie. Ten scenariusz zazwyczaj obejmuje HTTP request smuggling, technikę, w której dodatkowe nagłówki lub elementy ciała dodane przez serwer po wstrzyknięciu mogą prowadzić do różnych exploitów bezpieczeństwa.
Eksploatacja:
Wstrzyknięcie złośliwego prefiksu: Ta metoda polega na zanieczyszczeniu żądania następnego użytkownika lub pamięci podręcznej sieci przez określenie złośliwego prefiksu. Przykład tego to:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1
Tworzenie prefiksu do zanieczyszczenia kolejki odpowiedzi: To podejście polega na stworzeniu prefiksu, który, w połączeniu z końcowymi śmieciami, tworzy pełne drugie żądanie. Może to wywołać zanieczyszczenie kolejki odpowiedzi. Przykład to:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1
Memcache to magazyn klucz-wartość, który używa protokołu tekstowego. Więcej informacji w:
11211 - Pentesting MemcacheAby uzyskać pełne informacje, przeczytaj oryginalny artykuł
Jeśli platforma pobiera dane z żądania HTTP i używa ich bez sanitizacji do wykonywania żądań do serwera memcache, atakujący może wykorzystać to zachowanie do wstrzyknięcia nowych poleceń memcache.
Na przykład, w pierwotnie odkrytej luce, klucze pamięci podręcznej były używane do zwracania adresu IP i portu, do którego użytkownik powinien się połączyć, a atakujący byli w stanie wstrzyknąć polecenia memcache, które zanieczyszczały pamięć podręczną, aby wysłać szczegóły ofiar (w tym nazwy użytkowników i hasła) do serwerów atakującego:
Co więcej, badacze odkryli również, że mogą desynchronizować odpowiedzi memcache, aby wysłać adresy IP i porty atakującego do użytkowników, których e-mail atakujący nie znał:
Aby zminimalizować ryzyko wstrzyknięć CRLF (Carriage Return i Line Feed) lub nagłówków HTTP w aplikacjach internetowych, zaleca się następujące strategie:
Unikaj bezpośredniego wprowadzania danych od użytkownika w nagłówkach odpowiedzi: Najbezpieczniejszym podejściem jest powstrzymanie się od włączania danych dostarczonych przez użytkownika bezpośrednio do nagłówków odpowiedzi.
Koduj znaki specjalne: Jeśli unikanie bezpośredniego wprowadzania danych od użytkownika nie jest możliwe, upewnij się, że używasz funkcji dedykowanej do kodowania znaków specjalnych, takich jak CR (Carriage Return) i LF (Line Feed). Ta praktyka zapobiega możliwości wstrzyknięcia CRLF.
Aktualizuj język programowania: Regularnie aktualizuj język programowania używany w swoich aplikacjach internetowych do najnowszej wersji. Wybierz wersję, która z zasady nie pozwala na wstrzykiwanie znaków CR i LF w funkcjach odpowiedzialnych za ustawianie nagłówków HTTP.
Wskazówka dotycząca bug bounty: zarejestruj się w Intigriti, premium platformie bug bounty stworzonej przez hackerów, dla hackerów! Dołącz do nas na https://go.intigriti.com/hacktricks już dziś i zacznij zarabiać nagrody do 100 000 $!
Ucz się i ćwicz hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
