JSON Hijacking est-il toujours un problème dans les navigateurs modernes?

Question

Je suis à l'aide de Backbone.js et la Tornade serveur web. Le comportement standard pour la réception de collecte de données de la colonne vertébrale est à envoyer comme un Tableau JSON.

D'autre part, la Tornade du comportement standard est de ne pas permettre Tableau JSON est en raison de la vulnérabilité ci-dessous:

http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx

Un un rapport est: http://haacked.com/archive/2009/06/25/json-hijacking.aspx

Il se sent plus naturel pour moi de ne pas avoir à envelopper mon JSON dans un objet quand il est vraiment une liste d'objets.

J'ai été incapable de reproduire ces attaques dans les navigateurs modernes (c'est à dire actuelle de Chrome, Firefox, Safari, et IE9). Dans le même temps, j'ai été incapable de confirmer n'importe où que les navigateurs modernes avaient abordé ces questions.

Pour s'assurer que je ne suis pas induire en erreur par une éventuelle mauvaise programmation des compétences ni pauvre googler-compétences:

Ces JSON attaques par Détournement de toujours un problème aujourd'hui dans les navigateurs modernes?

(Note: Désolé pour le double possible: Est-il possible de faire "JSON détournement" sur navigateur moderne? mais depuis que l'on a accepté la réponse ne semble pas répondre à la question - j'ai pensé qu'il était temps de lui demander à nouveau et obtenir certaines des explications plus claires.)

Answer 1

Non, il n'est plus possible de saisir des valeurs transmises à l' [] ou {} constructeurs dans Firefox 21, Chrome 27, ou IE 10. Voici une petite page de test sur la base des principales attaques décrites dans http://www.thespanner.co.uk/2011/05/30/json-hijacking/:

http://jsfiddle.net/ph3Uv/2/

Il remplace window.Array et ajoute un setter pour Object.prototype.foo et de tests l'initialisation des tableaux et des objets via le court et le long des formes.

L' ES4 spec, dans la section 1.5, "exige l'échelle mondiale, la norme liaisons de l'Objet et du réseau à être utilisé pour construire de nouveaux objets pour l'objet et les initialiseurs de tableau", et les notes dans la mise en Œuvre de Précédent que "Internet Explorer 6, Opera 9.20, et Safari 3 ne respectent pas les locaux ou globaux rebindings de l'Objet et du Tableau, mais l'utilisation de l'Objet d'origine et Tableau des constructeurs." C'est conservée dans l' ES5, l'article 11.1.4.

Allen Wirfs-Brock a expliqué que ES5 précise également que l'initialisation de l'objet ne doit pas déclencher des poseurs, car il utilise DefineOwnProperty. MDN: Travailler avec des Objets note que "à Partir de JavaScript 1.8.1, les poseurs ne sont plus appelés lorsque vous définissez les propriétés de l'objet et les initialiseurs de tableau." Cela a été adressée en V8 question 1015.

Answer 2

Oui, navigateurs modernes sont vulnérables lorsque vous envoyez des données sensibles sans vérifier que la demande a été généré par un utilisateur légitime intention. Cette vulnérabilités décrites dans les messages liés ne sont rien de plus qu'un cas particulier de cross-site request forgery. Chaque demande pour les données sensibles doivent inclure un jeton temporaire qui n'est pas disponible pour les sites de tiers.

Je ne recommanderais pas simplement de commutation pour les requêtes POST, car cela ne permet pas de répondre à la question centrale (Postes sont encore vulnérables à CSRF en général), et c'est un (mineur) l'abus de la HTTP standard.

Answer 3

Qui se soucie si les navigateurs modernes permettent les attaques que vous avez mentionné. Il est tout aussi facile à assurez-vous que les attaques ne se produisent pas en vous assurant que votre côté serveur JSON services seulement répondre à des requêtes POST lors d'un retour de données sensibles. Juste parce que "Moderne", les navigateurs ne permettent pas de l'attaque, n'arrête pas le pauvre seul encore à l'aide de IE5.5 de visiter votre site et obtenir peu par une vulnérabilité. Et, comme dans tous les services de sécurité, votre sécurité est seulement aussi forte que le maillon faible de la chaîne.

Dire que l'on IE5.5 connexion de l'utilisateur credetials sont présentés de cette façon. Alors que le compte de l'utilisateur est utilisé pour obtenir des informations à partir d'autres utilisateurs, ou utilisés pour commettre un privalige escalade attaque, ou n'importe quel nombre de choses parce que l'attaquant est maintenant à l'intérieur et de confiance. C'est l'absolu pire des cas.

L'attaque décrite dans le cas des OP lié articles se réfère spécifiquement à une attaque du site induisant vos utilisateurs à charger leur page et à l'aide de la balise pour charger votre JSON ressource avec qui l'utilisateur des informations d'identification stockées. Cela génère une requête GET et donc, les articles vous conseille de ne pas répondre à l'exception des requêtes POST. Ce serait aussi fort, contre ce type d'attaque, de toute façon, pour répondre à des requêtes PUT et DELETE car ils ne pouvaient pas être émis par ce type d'attaque CSRF comme mentionné dans les commentaires.