Czy jest możliwe, aby XSS wykorzystywał odpowiedzi JSON z poprawnym łańcuchem JavaScript uciekającym

Odpowiedzi JSON mogą być wykorzystywane przez nadpisywanie konstruktorów Array lub jeśli wartości wrogie nie są znakami napisowymi JavaScript.Czy jest możliwe, aby XSS wykorzystywał odpowiedzi JSON z poprawnym łańcuchem JavaScript uciekającym

Załóżmy, że oba te wektory są adresowane w normalny sposób. Google znakomicie zatrzymuje odpowiedzi JSON bezpośredniego pozyskiwania poprzedzając cały JSON z czymś takim:

throw 1; < don't be evil' >

a potem reszta JSON obserwuje. Więc Dr Zło nie może, używając rodzaju exploit omawiane tutaj http://sla.ckers.org/forum/read.php?2,25788 uzyskać plik cookie (zakładając jesteś zalogowany) poprzez wprowadzenie następujących na swojej stronie:

<script src="http://yourbank.com/accountStatus.json">

Jak dla uciekającego reguły łańcucha, dobrze jeśli my” Ponownie używając podwójnych cudzysłowów, musimy poprzedzić każdym znakiem odwróconego ukośnika i każdego ukośnika odwrotnego kolejnym odwrotnym ukośnikiem itp.

Ale moje pytanie brzmi: co, jeśli robisz to wszystko?

Burpsuite (narzędzie do automatycznego wykrywania zabezpieczeń) wykrywa osadzone próby XSS, które są zwracane bez znaku UNHTML w odpowiedzi JSON, i zgłasza to jako lukę XSS. Mam raport, że moja aplikacja zawiera luki tego rodzaju, ale nie jestem przekonany. Próbowałem go i nie mogę zrobić exploita działa.

Więc nie sądzę, że to jest poprawne, ale pytam was StackOverflow społeczności, aby zważyć.

Jest jeden szczególny przypadek, że IE MIME typu wąchania, że myślę, że może doprowadzić do exploita . W końcu IE 7 wciąż miał "cechę", że tagi skryptów osadzone w komentarzach do obrazu zostały wykonane niezależnie od nagłówka Content-Type. Na początku zostawmy też na boku tak wyraźnie głupie zachowanie.

Z pewnością JSON byłby analizowany przez natywny parser JavaScript (Window.JSON w Firefox) lub przez eval() zgodnie ze starym domyślnym zachowaniem jQuery. W żadnym przypadku następujące wyrażenie nie spowoduje wykonania alertu:

{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}

Czy mam rację, czy też się mylę?

Źródło

2010-06-30 Chris Mountford

Tej potencjalnej luki xss można uniknąć, używając poprawnej Content-Type. Oparte na RFC-4627 wszystkie odpowiedzi JSON powinny używać typu application/json. Poniższy kod nie jest podatny na XSS, śmiało przetestować go:

<?php 
header('Content-type: application/json'); 
header("x-content-type-options: nosniff"); 
print $_GET['json']; 
?>

Nagłówek nosniff służy do wyłączania treści wąchania na starych wersjach programu Internet Explorer. Innym wariantem jest następujący:

<?php 
header("Content-Type: application/json"); 
header("x-content-type-options: nosniff"); 
print('{"someKey":"<body onload=alert(\'alert(/ThisIsNotXSS/)\')>"}'); 
?>

gdy powyższy kod jest wyświetlany przez przeglądarkę użytkownik został poproszony, aby pobrać plik JSON, JavaScript, nie został wykonany w nowoczesnych wersjach Chrome, Firefox i Internet Explorer. To byłoby naruszenie RFC.

Jeśli używasz JavaScript do eval() powyższego JSON lub zapiszesz odpowiedź na stronę, to stanie się ona DOM Based XSS. XSS oparty na DOM jest załatany na kliencie przez odkażenie JSON przed działaniem na tych danych.

Źródło

2010-06-30 05:09:07 rook

OK, więc przypuszczam, że mogłem uczynić go jaśniejszym, ale odpowiedź JSON, o której mówię, jest określona przez obecność nagłówka Content-Type mającego wartość "application/json". Wygląda na to, że potwierdzasz, że nie ma żadnego exploita. Czy Twój kod nie może zostać wykorzystany przez bezpośrednie pozyskiwanie w wrogiej domenie, czyli za pomocą znacznika script i parametryzowanie źródła w celu uwzględnienia kodu, który następnie zostanie wykonany w kontekście domeny, z której pochodzi? W takim przypadku pliki cookie tej domeny byłyby dostępne i mogłyby zostać przechwycone przez stronę wywołującą za pomocą document.write. Dobrze? –

@Chris Mountford wstrzyknięty JavaScript nie jest wykonywany, ponieważ serwer nie informuje przeglądarki. Pomyśl o tym w ten sposób, co jeśli masz JavaScript w .exe? To * może prowadzić * Dom Based XSS, ale tak samo jak inne projekty. Domowe XSS wykonuje się z tymi samymi zasadami, z których jest wykonywane. Jedynym sposobem, który może być dla ciebie problemem, jest "eval()" wpisanie kodu w twojej własnej witrynie. – rook

Rozumiem, że JSON był eval() 'd bardzo często w przeszłości, przynajmniej domyślnie w jQuery (jak już wspomniałem). Jednak nie interesuje mnie iniekcja JavaScript, ale iniekcja HTML w JSON, która prowadzi do wykonania JavaScript. Czy możesz to skomentować? Ponadto, jak już powiedziałem, że IE tak niedawno, jak v7, które potwierdziłem, może IGNOROWAĆ nagłówek Content-Type w pewnych okolicznościach. Tak, jest to błąd w IE, ale Microsoft argumentował, że nie (niezależnie od RFC), a na koniec, ze względów bezpieczeństwa ma znaczenie tylko to, co przeglądarki nie robią, co mówi specyfikacja. –

Jeśli ograniczymy nasz zakres do IE (wszystkie wersje), zakładamy, że prowadzisz stronę opartą na PHP lub ASP.NET i ignorujesz filtr IE anti-xss, to jesteś w błędzie: twoi użytkownicy są podatni na atak. Ustawienie "Content-type: application/json" również nie pomoże.

Jest to spowodowane (jak wspominasz) zachowaniem polegającym na wykryciu zawartości IE, wykraczającym poza wykrywanie znaczników HTML w treści odpowiedzi w celu uwzględnienia analizy URI.

Ten blog wpis wyjaśnia to bardzo dobrze:

http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html

Źródło

2012-03-28 23:40:06 anon

OK, ale URI wciąż jest całkowicie pod kontrolą serwera. –

Widzę, że działanie podsłuchowe IE tworzy wiele wektorów ataku, ale modyfikowanie informacji o ścieżce nie jest możliwe w mojej aplikacji. Wreszcie mogę nałożyć ten problem z wąchaniem, ponieważ IE w wersji 8+ wyłączy MIME sniffując używając: X-Content-Type-Options: nosniff Dla każdego, kto to czyta, myślę, że ustaliłem, że JSON może bezpiecznie przenosić wartości ze skażonym wejściem użytkownika, o ile jest zakodowana wartość JSON i oczywiście nigdy nie powinien być dołączany do HTML DOM bez kodowania html po stronie klienta. –

Aby wyjaśnić, mam na myśli, że napastnik nie ma możliwości wyboru własnej informacji o ścieżce. Oznacza to, że moja aplikacja nie jest podatna na atak w tej kategorii. Ponadto, w moim pierwotnym pytaniu, stwierdziłem, że chciałem odłożyć na bok kwestię wąchania MIME IE, ponieważ chciałem skoncentrować się na innych kategoriach (miałem już obejście tego problemu dla IE's MIME sniffing). –

Burpsuite (zautomatyzowane narzędzie bezpieczeństwa) wykrywa osadzone XSS próbuje zwracanych unHTML-uciekł w odpowiedzi JSON i zgłasza go jako luka XSS.

Być może próbuje zapobiec luce opisanej w rule 3.1 of OWASP XSS Cheat Sheet.

Dają następujący przykład kodu wrażliwych:

<script> 
    var initData = <%= data.to_json %>; 
</script>

Nawet jeśli cudzysłowy, ukośniki i nowe linie są właściwie uciekł, można wyrwać się z JSON, jeśli jest osadzony w HTML:

<script> 
    var initData = {"foo":"</script><script>alert('XSS')</script>"}; 
</script>

jsFiddle.

Funkcja

to_json() może zapobiec temu problemowi, dodając przed każdym ukośnikiem ukośnik odwrotny. Jeśli JSON jest używany w atrybucie HTML, cały ciąg JSON musi być w języku HTML. Jeśli jest używany w atrybucie href="javascript:", musi mieć unikatowy URL.

Źródło

2014-01-19 00:05:11

To jest bardzo prosty błąd w php (zakładam, że to php). Nie możesz wstawiać skażonych danych do HTML bez przechodzenia HTML. Ale jak wskazałem w moim pytaniu, nie robię tego. Chociaż jest możliwe, że Burpsuite może próbować zapobiec temu problemowi, takie podejście jest błędne. –

Jakie podejście jest błędne? Nie rozumiem cię. Co do "Nie możesz wstawiać skażonych danych do HTML bez ucieczki HTML.", Zgadnij co, nie powinieneś wstawiać nawet niezainfekowanych danych bez ucieczki. –

Kwestia tego, co można wstawić, całkowicie wykracza poza zakres tego pytania. Z pewnością możesz wstawić niezainfekowane dane, jeśli dane te składają się z kodu HTML. W rzeczywistości, jeśli masz HTML i wstawiasz go Z WYCOFANIEM, otrzymasz podwójne wyjście z ucieczki, które, mimo że nie jest błędem bezpieczeństwa, nadal jest błędem. Podejście, które opisuję jako wprowadzające w błąd, to próba "zapobieżenia luce opisanej w regule 3.1 OWASP XSS Cheat Sheet", którą sugerujesz jako intencję Burpsuite. Jeśli twoja sugestia dotycząca Burpsuite jest prawdziwa, to są one błędne. –

Czy jest możliwe, aby XSS wykorzystywał odpowiedzi JSON z poprawnym łańcuchem JavaScript uciekającym

Odpowiedz

Powiązane problemy