Czy możliwe jest wykorzystanie przez XSS odpowiedzi JSON z poprawnym JavaScript string escaping
Odpowiedzi JSON mogą być wykorzystane przez nadpisujące konstruktory tablicy lub jeśli wrogie wartości nie są JavaScript string-Escape.
Załóżmy, że oba te wektory są adresowane w sposób normalny. Google słynnie pułapki JSON response direct sourcing poprzez prefiks wszystkie JSON z coś w rodzaju:
throw 1; < don't be evil' >
A potem następuje reszta JSON. Więc Dr. Evil nie może, używając rodzaju exploita omawianego tutaj http://sla.ckers.org/forum/read.php?2 / align = "left" / 25788 (zakładając, że jesteś zalogowany) umieszczając na swojej stronie:
<script src="http://yourbank.com/accountStatus.json">
Jeśli chodzi o reguły interpretacji ciągów znaków, cóż, jeśli używamy podwójnych cudzysłowów, musimy poprzedzić każdy z odwrotnym ukośnikiem, a każdy z innym ukośnikiem itp.
Ale moje pytanie brzmi, co jeśli robisz to wszystko?Burpsuite (zautomatyzowane narzędzie zabezpieczające) wykrywa osadzone próby XSS, które są zwracane w odpowiedzi JSON z uniknięciem unhtml i zgłasza je jako lukę XSS. Mam raport, że moja aplikacja zawiera tego typu luki, ale nie jestem przekonany. Próbowałem i nie mogę zrobić exploita.
Więc nie sądzę, że to jest poprawne, ale proszę społeczność StackOverflow, ważyć.
Jest jeden konkretny przypadek, taki jak sniffing typu MIME, który moim zdaniem może skutkować exploitem. W końcu IE 7 nadal miał "funkcję", że znaczniki skryptów osadzone w komentarzach do obrazów były wykonywane niezależnie od nagłówka Content-Type. Zostawmy też takie na początku wyraźnie głupie zachowanie.
Z pewnością JSON byłby parsowany przez natywny parser JavaScript (Window.JSON w Firefoksie) lub przez eval() zgodnie ze starym domyślnym zachowaniem jQuery. W żadnym wypadku następujące wyrażenie nie spowoduje wykonania alertu:
{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}
4 answers
Tę potencjalną lukę xss można uniknąć, używając poprawnej Content-Type. Na podstawie RFC-4627 wszystkie odpowiedzi JSON powinny używać Typu application/json. Poniższy kod jest nie narażony na XSS, śmiało przetestuj 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 sniffingu zawartości w starych wersjach programu Internet Explorer. Inny wariant 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 przeglądany przez przeglądarkę, użytkownik został poproszony o pobranie pliku JSON, JavaScript nie był uruchamiany na nowoczesnych wersjach Chrome, FireFox i Internet Explorer.To byłoby naruszenie RFC.
Jeśli używasz JavaScript do eval() JSON powyżej lub piszesz odpowiedź na stronę, to staje się DOM oparty XSS . Bazujący na DOM XSS jest łatany na kliencie przez dezynfekcję JSON przed działaniem na tych danych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-01-19 00:44:45
Burpsuite (zautomatyzowane narzędzie bezpieczeństwa) wykrywa próby osadzenia XSS które są zwracane unHTML-escaped w odpowiedzi JSON i zgłasza to jako podatność na XSS.
Być może próbuje zapobiec podatności opisanej w reguła 3.1 ściągawki OWASP XSS .
Podają następujący przykład kodu wrażliwego:
<script>
var initData = <%= data.to_json %>;
</script>
Nawet jeśli podwójne cudzysłowy, ukośniki i nowe linie są odpowiednio unikane, możesz wyłamać się z JSON, jeśli jest osadzony w HTML:
<script>
var initData = {"foo":"</script><script>alert('XSS')</script>"};
</script>
JsFiddle .
to_json() funkcja może zapobiec temu problemowi poprzez prefiks każdego ukośnika z odwrotnym ukośnikiem. Jeśli w atrybucie HTML używany jest JSON, cały łańcuch JSON musi być HTML-Escape. Jeśli jest używany w atrybucie href="javascript:", musi być unikany przez URL.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-01-19 00:10:22
Jeśli ograniczymy nasz zakres do IE( wszystkie wersje), Załóżmy, że prowadzisz stronę opartą na PHP lub ASP.NET, i zignorować filtr IE anty - XSS, to jesteś w błędzie: użytkownicy są podatne. Ustawienie 'Content-type: application / json' również nie pomoże.
Jest to spowodowane (jak wspominasz) zachowaniem IE w zakresie wykrywania treści, które wykracza poza sniffing dla znaczników HTML w ciele odpowiedzi, aby uwzględnić analizę URI.
Ten wpis na blogu wyjaśnia to bardzo cóż:
Http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-03-28 23:40:06
Dla przypomnienia, chociaż zaakceptowałem odpowiedź, na dokładnie dosłowne pytanie, które zadaję, miałem rację i nie było luki z powodu obecności nie-HTML-escaped, ale poprawnie JSON-escaped HTML wewnątrz wartości JSON. Nie może być błąd tam, jeśli ta wartość została wstawiona do DOM bez ucieczki po stronie klienta, ale Burpsuite ma małe szanse wiedzieć, czy to się stanie tylko patrząc na ruch sieciowy.
W ogólnym przypadku ustalenia, co jest zabezpieczeniem luka w tych okolicznościach, to jest pouczające, aby rozpoznać, że chociaż może nie czuć się jak dobry projekt, treść odpowiedzi wartości JSON może być legalnie wiadomo, że z pewnością nie zawierają żadnych danych wejściowych użytkownika i być przeznaczone do już renderowane HTML, aby być bezpiecznie wstawione w DOM bez sklejenia. Jak wspomniałem w innym komentarzu, będzie to błąd (niezwiązany z bezpieczeństwem).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-09-21 03:13:09