CRLF jest akronimem używanym w odniesieniu do powrotu karetki (\r) podawanie linii (\n). Jak można zauważyć z symboli w nawiasach, „powrót karetki „odnosi się do końca linii, a” podawanie linii ” odnosi się do nowej linii. W związku z tym zarówno CR, jak i LF są używane do oznaczania punktu końcowego linii. Gdy użytkownik żąda zawartości w witrynie, serwer zwraca zawartość witryny wraz z nagłówkami HTTP. Nagłówki i zawartość są oddzielone określoną kombinacją CR i LF. To z powodu CRLF serwer wie, gdzie zaczyna się lub kończy nowy nagłówek. Luka wtrysku carriage Return Line Feed (CRLF) jest rodzajem wtrysku po stronie serwera, który występuje, gdy atakujący wstawia znaki CRLF w polu wejściowym, aby oszukać serwer, sprawiając, że myśli, że obiekt został zakończony i rozpoczął się nowy. Dzieje się tak, gdy aplikacja internetowa nie dezynfekuje wprowadzania znaków CRLF przez użytkownika. Ma średni stopień ciężkości (P3 według VRT Bugcrowda).

atak wtrysku CRLF ma dwa najważniejsze przypadki użycia:

• podział logów: Atakujący wstawia znak końca linii i dodatkową linię, aby sfałszować wpisy w pliku dziennika, aby oszukać administratorów systemu, ukrywając inne ataki.
• podział odpowiedzi HTTP: Wtrysk CRLF służy do dodawania nagłówków HTTP do odpowiedzi HTTP i, na przykład, do wykonania ataku XSS, który prowadzi do ujawnienia informacji.

przykład:

proste żądanie GET może być wykonane w następujący sposób:

GET /%0d%0aSet-Cookie:CRLFInjection=PreritPathak HTTP/1.1

Uwaga: %0d i %0a są odpowiednio zakodowanymi formami \R i \N. Jeśli aplikacja internetowa jest podatna na zagrożenia, atakujący będzie mógł ustawić plik cookie na stronie internetowej.

skutki CRLF injection

CRLF Injection pozwala atakującemu ustawić fałszywe pliki cookie, ukraść tokeny CSRF, ujawnić informacje o użytkowniku poprzez wstrzyknięcie skryptu (XSS) i wykonać wiele innych ataków. Umożliwia również atakującym dezaktywację & ominięcie środków bezpieczeństwa, takich jak filtry XSS & tej samej polityki pochodzenia (SOP), co czyni ich podatnymi na następujące ataki:

1. XSS lub Cross Site Scripting
XSS lub Cross Site Scripting to luka w zabezpieczeniach, która umożliwia atakującemu wstrzyknięcie złośliwego kodu JavaScript do aplikacji internetowej. Poniższe żądania GET są tworzone przy próbie wtrysku CRLF za pomocą XSS.
wyświetlając alert zawierający poufne informacje użytkownika

www.target.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

wyłączając ochronę XSS

www.target.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23

2. Cookie Injection
podział odpowiedzi HTTP pozwala atakującemu ustawić złośliwe pliki cookie w przeglądarce ofiary. W większości przypadków poniższe żądanie GET spowoduje przekierowanie 307, a zatem ofiara zostanie przekierowana do target.com & URL nie będzie zawierał parametru Set-Cookie. W tle zostanie jednak ustawiony plik cookie.

www.target.com/%0d%0aSet-Cookie:CRLFInjection=MaliciousCookieSet

3. Ataki phishingowe
atakujący może ustawić nagłówek lokalizacji, który przekierowałby ofiarę na złą stronę internetową. Ta strona internetowa może wyglądać tak, jak strona docelowa, a gdy ofiara wprowadzi swoje dane uwierzytelniające, zostaną wysłane do atakującego. Nagłówek lokalizacji można ustawić jako:

GET /%0d%0aLocation:%20https://evil.com HTTP/1.1

4. Utrwalenie sesji
podobnie jak w przypadku ataku typu cookie Injection, tutaj atakujący ustawia identyfikator sesji użytkownika na określoną wartość. Ten link jest wysyłany do ofiary, a gdy ofiara loguje się za pomocą tej sesji, atakujący może również zalogować się za pomocą tego samego identyfikatora sesji.

www.target.com/%0d%0aSet-Cookie:session_id=942....

5. HTTP Header Injection
atakujący może wykorzystać Wtrysk CRLF do wstrzykiwania nagłówków HTTP w aplikacji w celu pokonania mechanizmów bezpieczeństwa, takich jak filtry XSS lub zasady tego samego pochodzenia.

www.target.com/%0d%0aHackersHeader:NewHeader

Cors (Cross Origin Resource Sharing) aktywujące nagłówki mogą być wstrzykiwane & atakujący może używać JavaScript, aby uzyskać dostęp do poufnych zasobów, które są w inny sposób chronione przez SOP (Same Origin Policy), który zapobiega dostępowi witryn z różnych źródeł do siebie.
6. Zatrucie Web Cache
zatrucie Web-cache jest techniką, dzięki której atakujący może podawać zatrute treści poprzez manipulowanie Web cache. Aby skutecznie wykorzystać ten problem, atakujący musiałby zatruć buforujące proxy, syndykatory, sieci dostarczania treści (CDN) lub inne mechanizmy buforowania między Klientem a serwerem. Po udanym zatruciu pamięci podręcznej, ofiara nie będzie miała pojęcia o złośliwej zawartości, która jest im serwowana przez pamięć podręczną. Poniżej przedstawiono przykład, w jaki sposób atakujący może potencjalnie wykorzystać zastrzyk nagłówka hosta (przy użyciu CRLF) poprzez zatrucie pamięci podręcznej sieci web.

Dla poniższego zapytania:

$ telnet www.target.com 80Trying x.x.x.x...Connected to www.target.com.Escape character is '^]'.GET /%0d%0aX-Forwarded-Host:hacker.com HTTP/1.1 //or HostHost: target.com

:

HTTP/1.1 200 OK

różne przypadki użycia:

1. Wstrzyknięcie fałszywego nagłówka odpowiedzi HTTP:

Content-Length: 10

teraz przeglądarka internetowa przetwarza tylko następne 10 bajtów.
2. Wstrzyknięcie fałszywego nagłówka odpowiedzi HTTP:

Content-Length: 0

jest to traktowane jako zakończona odpowiedź& przeglądarki zaczynają analizować nową odpowiedź.

łagodzenia:

programista powinien pamiętać o następujących rzeczach, aby zapobiec wstrzyknięciu CRLF:

• dezynfekcja danych wejściowych użytkownika.
• koduje CR& znaki LF (\R, \n) tak, że nawet gdy są dostarczane, nie są rozpoznawane przez serwer.
• weryfikuje dane wejściowe użytkownika, zanim dotrze on do nagłówków odpowiedzi (np. za pomocą metod takich jak StringEscapeUtils.escapeJava ()).
• niepotrzebny nagłówek powinien być wyłączony.
  poniższa tabela podkreśla wagę wtrysku CRLF zgodnie z różnymi standardami branżowymi: