41 votes

Est-il possible d'exploiter XSS les réponses JSON avec un échappement de chaîne JavaScript approprié

Réponses JSON peuvent être exploitées par des raisons impérieuses de la Matrice de constructeurs ou si hostile valeurs ne sont pas JavaScript chaîne de caractères d'échappement.

Supposons ces deux vecteurs sont adressées de la manière habituelle. Google célèbre les pièges réponse JSON à l'approvisionnement direct par la préfixation de tous JSON avec quelque chose comme:

throw 1; < don't be evil' >

Et puis le reste du JSON suit. Donc, M. le Mal ne peut pas, à l'aide de la sorte d'exploiter discuté ici http://sla.ckers.org/forum/read.php?2,25788 obtenir votre cookie (en supposant que vous êtes connecté) en mettant les suivantes sur son site:

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

Comme pour l'échappement de la chaîne règles, eh bien, si nous sommes à l'aide de guillemets doubles, nous avons besoin de préfixer chaque avec une barre oblique inverse et chaque barre oblique inverse avec une autre barre oblique inverse etc.

Mais ma question est, que faire si vous êtes en train de faire tout cela?

Burpsuite (l'outil de sécurité automatisé) détecte intégré XSS tentatives qui sont retournés unHTML échappé à une réponse JSON et il le signale comme une vulnérabilité XSS. J'ai un rapport que mon application contient des vulnérabilités de ce type mais je ne suis pas convaincu. Je l'ai essayé et je ne peux pas faire un exploit de travail.

Donc je ne pense pas que c'est correct, mais je vous demande StackOverflow de la communauté, à peser.

Il y a un cas spécifique, celui de IE type MIME reniflant que je pense pourrait entraîner un exploit. Après tout, c'est à dire 7 avait encore la "fonction" que les balises de script incorporé dans l'image, les commentaires ont été exécutés indépendamment de l'-tête Content-Type. Nous allons également laisser tel clairement stupide comportement de côté au début.

Sûrement le JSON serait analysée par le JavaScript natif de l'analyseur (Fenêtre.JSON dans Firefox) ou par un eval() que par l'ancienne valeur par défaut de jQuery comportement. Dans aucun de ces cas, l'expression suivante suite à l'alerte en cours d'exécution:

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

Ai-je raison ou je me trompe?

31voto

Rook Points 34698

Ce potentiel de vulnérabilité xss peut être évité en utilisant le bon Content-Type. Basé sur la RFC 4627 toutes les réponses JSON doit utiliser l' application/json type. Le code suivant est de ne pas être vulnérable aux attaques de type xss, aller de l'avant de la tester:

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

L' nosniff d'en-tête est utilisé pour désactiver le contenu renifleurs sur les anciennes versions d'Internet Explorer. Une autre variante est comme suit:

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

lorsque le code ci-dessus est affiché par un navigateur de l'utilisateur est invité à télécharger un fichier JSON, JavaScript n'a pas été exécutée par les nouvelles versions de Chrome, FireFox et Internet Explorer. Ce serait une violation de RFC.

Si vous utilisez JavaScript pour eval() le JSON ci-dessus ou écrire la réponse à la page, puis il devient DOM Basé XSS. DOM basé XSS est patché sur le client par l'assainissement du JSON avant d'agir sur ces données.

8voto

Alexey Lebedev Points 4778

Burpsuite (l'outil de sécurité automatisé) détecte intégré XSS tentatives qui sont retournés unHTML échappé à une réponse JSON et il le signale une vulnérabilité XSS.

Peut-être qu'il tente d'empêcher la vulnérabilité décrite dans l' article 3.1 de l'OWASP XSS Feuille de Triche.

Ils donnent l'exemple de code vulnérable:

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

Même si les guillemets doubles, les barres obliques et les retours à la ligne sont échappées, vous pouvez sortir de JSON si celui-ci est intégré dans le HTML:

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

jsFiddle.

to_json() fonction peut éviter ce problème en préfixant chaque slash avec une barre oblique inverse. Si JSON est utilisé dans l'attribut HTML, l'ensemble de la chaîne JSON doit être en HTML échappé. Si elle est utilisée dans un href="javascript:" d'attribut, il doit être URL-s'est échappé.

1voto

anon Points 17

Si nous limitons notre champ d'IE (toutes versions), supposons que vous exécutez un site basé sur PHP ou ASP.NET et ignorer l'IE anti-filtre xss, alors vous avez tort: vos utilisateurs sont vulnérables. Paramètre 'Content-type: application/json' ne va pas aider non plus.

Cela est dû (comme vous le mentionnez) IE contenu de détection de comportement, qui va au-delà de renifler pour les balises HTML dans le corps de la réponse à inclure URI de l'analyse.

Ce blog explique cela très bien:

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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X