JSON meilleures pratiques de sécurité?

Question

Alors que des recherches sur la question de JSON vs XML, je suis tombé sur cette question. Maintenant, l'une des raisons de préférer JSON a été répertorié comme la facilité de la conversion en Javascript, c'est à dire avec l' eval(). Maintenant, cela m'a immédiatement frappé comme potentiellement problématique dans une perspective de sécurité.

J'ai donc commencé à faire quelques recherches sur les aspects de sécurité de JSON et à travers ce blog à propos de la façon dont JSON n'est pas aussi sûr que les gens pensent qu'il est. Cette partie a frappé:

Mise à jour: Si vous faites JSON 100% correctement, alors vous aurez seulement les objets au plus haut niveau. Des tableaux, Chaînes de caractères, Nombres, etc seront tous enveloppé. Un objet JSON va échouer à eval() parce que le JavaScript interprète pense que c'est en regardant un bloc plutôt que d'un objet. Cette va un long chemin pour la protection contre les ces attaques, cependant, c'est encore meilleur pour protéger vos données avec onu-prévisible Url.

Ok, donc c'est une bonne règle pour commencer: objets JSON au plus haut niveau doit toujours être objets et de ne jamais les tableaux, les nombres ou de chaînes de caractères. Sonne comme une bonne règle pour moi.

Est-il rien d'autre à faire ou à éviter quand il s'agit de JSON et AJAX liées à la sécurité?

La dernière partie de la citation ci-dessus mentionne imprévisible Url. Quelqu'un aurait-il plus d'informations sur ce point, notamment, sur la façon de le faire en PHP? Je suis beaucoup plus d'expérience en Java qu'en PHP et en Java, il est facile (que vous pouvez mapper un ensemble d'Url à une seule servlet), tandis que tout le PHP, j'ai fait avez mappé à une URL unique pour le script PHP.

Aussi, comment utilisez-vous imprévisible Url d'augmenter la sécurité?

Answer 1

Il y a un certain nombre d'attaques de sécurité contre JSON, surtout XSRF.

Le problème se produit lorsqu'un service web utilise des cookies à des fins d'authentification, et répond avec un tableau JSON contenant des données sensibles en réponse à une requête GET.

Si un attaquant peut tromper l'utilisateur qui est connecté à un service, naive-webapp.com en visitant leur site (ou tout autre site qui incorpore une IFRAME ils contrôlent, par exemple, via les publicités intégrées) alors ils peuvent insérer un <script> balise avec un CRS à l'naive-webapp.com et potentiellement voler les données de l'utilisateur. Cela dépend d'un javascript caprice avec le JavaScript Array constructeur comme ceci:

 <script>
   // Overload the Array constructor so we can intercept data
   var stolenArrays = [];
   var RealArray = Array;
   Array = function () {
     var arr = RealArray.apply(arguments);
     stolenArrays.push(arr);
     return arr;
   }
 </script>
 <!-- even though the attacker can't access the cookies,
   - he can cause the browser to send them to naive-webapp.com -->
 <script src="//naive-webapp.com/..."></script>
 <script>
   // now stolenArrays contains any data from the parsed JSON
 </script>

EcmaScript 5 a fixé la confusion de comportement qui a causé [] pour rechercher Array sur l'objet global et beaucoup de navigateurs modernes sont plus sensibles à ce type d'attaque.

D'ailleurs, le Pétrole est mal à propos imprévisible Url. Cryptographique sécurisé aléatoire des identificateurs dans les Url sont une excellente façon de protéger les ressources. L'identité de base de la sécurité n'est pas une panacée car l'Huile suggère. Voir http://waterken.sourceforge.net/ pour un exemple d'une application distribuée schéma basé sur cryptographique sécurisé identificateurs dans les Url qui ne nécessite pas un concept de l'identité.

EDIT:

Lors de l'examen JSON vs XML, vous devez être conscient de XML spécifique des vecteurs d'attaque.

XXE, XML entités Externes attaques, utiliser XML conçu pour l'accès du système de fichiers et ressources réseau à travers le pare-feu.

<!DOCTYPE root 
[
<!ENTITY foo SYSTEM "file:///c:/winnt/win.ini">
]>
...
<in>&foo;</in>

L'Application intègre l'entrée (paramètre "in", qui contient la victoire.fichier ini) à la réponse du service web.

Answer 2

La principale faille de sécurité du blog (CSRF), n'est pas JSON spécifiques. C'est juste un grand trou à l'aide de XML à la place. En effet, il est tout aussi mauvais avec aucun des appels asynchrones à tous; des liaisons régulières sont tout aussi vulnérables.

Quand les gens parlent d'Url uniques, ils sont généralement de NE PAS dire http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement. Au lieu de cela, il est plus courant de faire quelque chose d'autre au sujet de la demande unique, à savoir une valeur sous la FORME d'un poste ou d'un paramètre de l'URL.

Habituellement, cela implique un hasard jeton inséré dans le FORMULAIRE sur le côté serveur, et ensuite vérifiée lorsqu'une demande est faite.

Le tableau/objet sont des nouvelles de moi:

Script-Tags: L'attaquant peut incorporer un balise de script pointant sur un serveur distant et le navigateur va efficacement eval() la réponse pour vous, mais il jette la réponse et depuis JSON est toute réponse, vous êtes en sécurité.

Dans ce cas, votre site n'a pas besoin d'utiliser JSON à tous d'être vulnérables. Mais ouais, si un attaquant peut insérer aléatoire HTML dans votre site, vous êtes grillé.

Answer 3

c'est toujours mieux pour protéger vos données avec onu-prévisible Url.

C'est moi qui souligne. Quel non-sens! C'est mieux pour protéger vos données avec une bonne authentification et, éventuellement, certains de chiffrement sur le dessus de cela. JSON échanges pouvez toujours utiliser les techniques d'authentification (par exemple, des sessions par les témoins) et SSL.

En s'appuyant sur quelqu'un de ne pas deviner l'URL (ce qu'ils sont effectivement en parler) seront seulement être raisonnable de la technique (et même alors, seulement) lorsque vous êtes en utilisant JSON pour exporter les données vers un anonyme, un tiers (par exemple, un service web). Un exemple est Google différentes API de service web où les utilisateurs anonymes accès Google-données par d'autres sites web. Ils utilisent de domaine référent et de l'API clés assurez-vous que le man-in-the-middle site web est autorisé à fournir Gooogle de données.

Si vous êtes juste en utilisant JSON pour envoyer des données privées de et de un direct, connu de l'agent utilisateur, utilisez un certain réel d'authentification et de chiffrement. Si vous êtes en essayant de fournir un service web, puis cela dépend vraiment de comment "sécuriser" ces données va être. Si c'est juste des données publiques, et vous n'avez pas l'esprit qui peut le lire, je ne vois pas l'intérêt de faire un hashy URL.

---

Edit: pour démontrer ce qu'ils signifient, considérez ceci. Imaginez que votre banque a fourni une API JSON pour obtenir des instructions. Si seulement je pouvais type http://yourbank.com/json-api/your-name/statement, vous ne serait probablement pas meilleur plaisir.

Ils pourraient générer une chaîne unique pour votre compte qui a été nécessaire dans toute JSON demande si, par exemple: http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement

J'aurais beaucoup moins de chance d'être en mesure de deviner qui. Mais vous voulez vraiment que le fait d'être le seul intermédiaire entre votre véritablement sécuriser les données et les potentiels voleurs d'identité? Pas de.