J'ai récemment commencé à chercher dans la construction d'applications Web à l'aide de .NET MVC et je suis tombé sur ce blog post de Phil Haack: JSON Dijacking . Pour ceux d'entre vous qui ne sont pas au courant de cette vulnérabilité lors de l'utilisation de JSON pour transférer des données sensibles, c'est vraiment un must.
Il semble qu'il y ait trois façons de gérer cette vulnérabilité.
La troisième alternative n'est pas vraiment une option car elle limite vraiment l'utilisation de JSON.
Alors lequel préférez-vous?
L'aperçu de .NET MVC 2 nécessite un poste pour les réponses JSON par défaut, je pense que c'est un excellent moyen de protéger tout développeur qui ne connaît pas encore ce problème. Mais pour moi, cela ressent un petit "hacky" pour casser le repos de cette manière. Sauf si quelqu'un m'en parle, je m'envoie d'envelopper mes matrices dans un autre objet et de débrancher le côté client.
3 Réponses :
Je saisis personnellement toutes mes réponses dans un commentaire:
/* {
"foo": 3,
"bar": "string with *\x2F sequence in"
} */
L'article E4X Vous mentionnez des discussions sur les risques de sécurité dans la direction opposée: que consommateurs de données E4X doit se méfier de l'exécuter sans analyse. Si vous produisent des données E4X, quelle est l'inquiétude?
La page aborde l'injection dans les deux sens. Auparavant (et toujours dans les plus âgés de Firefoxen), vous pouvez modifier le prototype XML pour accéder à des objets nouvellement créés-script-script-script, et il existe toujours des dangers potentiels pour le contenu JavaScript imbriqué dans E4X pour invoquer des rappels d'attaquant. Ceci est particulièrement le cas pour les pages qui incluent un contenu fourni par attaqueur, même convenablement échappés.
Comme il s'agit essentiellement d'une attaque CSRF, vous pouvez mettre un jeton (par exemple Hash of Session ID et Secret) dans chacun de vos appels JSON et vérifiez la validité de ce jeton sur le serveur. C'est la même chose que vous devriez faire pour les demandes postales ordinaires de toute façon.
Cela n'empêche que des données d'affichage de la part de quelqu'un d'autre. Cela n'arrête pas le méchant de voler des informations sensibles auxservies par un service Get JSON.
Le méchant a besoin de connaître le jeton, mais je ne pense pas qu'il y a un moyen de l'obtenir. S'il vous plaît prouver moi mal.
@stefanw L'article relié dans la question mentionne que les données pourraient être mises en cache, de sorte que la vérification des en-têtes n'aident donc pas. Je pense que la même chose s'applique à la vérification d'un jeton CSRF.
Il s'agit d'un CSRF classique (Falsification de la demande croisée).
Voici une solution: