Meilleures pratiques de sécurité JSON?
En recherchant le problème de JSON vs XML , je suis tombé sur cette question . Maintenant, l'une des raisons de préférer JSON a été répertoriée comme la facilité de conversion en Javascript, à savoir avec la eval(). Maintenant, cela m'a immédiatement semblé potentiellement problématique du point de vue de la sécurité.
J'ai donc commencé à faire des recherches sur les aspects de sécurité de JSON et à travers ce billet de blog sur la façon dont JSON n'est pas aussi sûr que les gens le pensent . Cette partie ressortait:
Mise à jour: Si vous faites JSON à 100% correctement, alors vous n'aurez que des objets au niveau supérieur. Les tableaux, les chaînes, les nombres, etc. seront tous enveloppés. Un objet JSON échouera alors à eval () car l'interpréteur JavaScript pensera qu'il regarde un bloc plutôt qu'un objet. Cela contribue grandement à la protection contre ces attaques, mais il est toujours préférable de protéger vos données sécurisées avec des URL imprévisibles.
Ok, c'est donc une bonne règle pour commencer: les objets JSON au niveau supérieur doivent toujours être des objets et jamais des tableaux, des nombres ou des chaînes. Cela me semble être une bonne règle.
Y a-t-il autre chose à faire ou à éviter en ce qui concerne JSON et la sécurité associée à AJAX?
La dernière partie de la citation ci-dessus mentionne des URL imprévisibles. Quelqu'un at-il plus d'informations à ce sujet, en particulier comment vous le faites en PHP? Je suis beaucoup plus expérimenté en Java que PHP et en Java c'est facile (en ce que vous pouvez mapper un ensemble) plage d'URL à un seul servlet) alors que tous les PHP que j'ai fait) ont mappé une URL unique au script PHP.
De plus, comment utilisez-vous exactement les URL imprévisibles pour augmenter la sécurité?
Le principal trou de sécurité du blog (CSRF) n'est pas spécifique à JSON. C'est tout aussi gros un trou en utilisant XML à la place. En effet, c'est tout aussi mauvais sans aucun appel asynchrone; les liens réguliers sont tout aussi vulnérables.
Lorsque les gens parlent d'URL uniques, cela ne signifie généralement PAS http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement . Au lieu de cela, il est plus courant de rendre quelque chose d'autre sur la demande unique; à savoir une valeur dans le post FORM, ou un paramètre URL.
Habituellement, cela implique un jeton aléatoire inséré dans le FORMULAIRE côté serveur, puis vérifié lorsqu'une demande est effectuée.
La chose tableau/objet est nouvelle pour moi:
Balises de script: l'attaquant peut incorporer une balise de script pointant vers un serveur distant et le navigateur évaluera efficacement la réponse pour vous, mais il jette la réponse et puisque JSON est une réponse complète, vous êtes en sécurité.
Dans ce cas, votre site n'a pas du tout besoin d'utiliser JSON pour être vulnérable. Mais oui, si un attaquant peut insérer du HTML aléatoire dans votre site, vous portez un toast.
Il existe un certain nombre d'attaques de sécurité contre JSON, en particulier XSRF.
La vulnérabilité se produit lorsqu'un service Web utilise des cookies pour l'authentification et répond avec un tableau JSON contenant des données sensibles en réponse à une demande GET.
Si un attaquant peut inciter un utilisateur connecté à un service, naive-webapp.com, à visiter son site (ou tout site intégrant un IFRAME qu'il contrôle, par exemple via des publicités intégrées), il peut insérer un <script> tag avec un SRC sur naive-webapp.com, et potentiellement voler les données de l'utilisateur. Cela dépend d'une bizarrerie javascript avec le constructeur JavaScript Array 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 corrigé le comportement déroutant qui provoquait [] pour rechercher Array sur l'objet global et de nombreux navigateurs modernes ne sont plus sensibles à cette attaque.
Soit dit en passant, Oil a tort au sujet des URL imprévisibles. Les identifiants aléatoires cryptographiquement sécurisés dans les URL sont un bon moyen de protéger les ressources. La sécurité basée sur l'identité n'est pas une panacée comme le suggère Oil. Voir http://waterken.sourceforge.net/ pour un exemple de schéma d'application répartie sécurisée basé sur des identifiants cryptographiquement sécurisés dans des URL qui ne nécessite pas de concept d'identité.
MODIFIER:
Lorsque vous envisagez JSON vs XML, vous devez également être conscient des vecteurs d'attaque spécifiques à XML.
XXE , XML Entités externes attaques, utilisez XML spécialement conçu pour accéder au système de fichiers et aux ressources réseau via le pare-feu.
<!DOCTYPE root [ <!ENTITY foo SYSTEM "file:///c:/winnt/win.ini"> ]> ... <in>&foo;</in>L'application incorpore l'entrée (paramètre "in", qui contient le fichier win.ini) à la réponse du service Web.
c'est toujours le meilleur pour protéger vos données sécurisées avec des URL imprévisibles.
Je souligne. Quelle absurdité! C'est mieux pour protéger vos données sécurisées avec une authentification appropriée et éventuellement un chiffrement en plus de cela. Les échanges JSON peuvent toujours utiliser les techniques d'authentification existantes (par exemple des sessions via des cookies) et SSL.
S'appuyer sur quelqu'un qui ne devine pas une URL (ce dont ils parlent effectivement) ne sera une technique raisonnable (et même alors, que juste) lorsque vous utilisez JSON pour exporter des données vers un tiers anonyme (par exemple, un service Web) . Un exemple est les diverses API de service Web de Google où des utilisateurs anonymes accèdent aux données Google via d'autres sites Web. Ils utilisent le référent de domaine et les clés d'API pour s'assurer que le site Web de l'homme du milieu est autorisé à fournir des données Gooogle.
Si vous utilisez simplement JSON pour envoyer des données privées vers et depuis un agent utilisateur direct et connu, utilisez une authentification et un chiffrement réels. Si vous essayez de fournir un service Web, cela dépend vraiment de la façon dont "sécurise" ces données vont être. Si ce ne sont que des données publiques et que cela ne vous dérange pas de savoir qui peut les lire, je ne vois pas l'intérêt de créer une URL de hachage.
Edit: pour démontrer ce qu'ils signifient, considérez ceci. Imaginez que votre banque fournisse une API JSON pour obtenir des relevés. Si je pouvais simplement taper http://yourbank.com/json-api/your-name/statement, vous ne seriez probablement pas plus satisfaits.
Ils pourraient cependant générer une chaîne unique pour votre compte, qui était requise dans toute demande JSON, par exemple: http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement
J'aurais bien moins de chance de pouvoir le deviner. Mais voudriez-vous vraiment que ce soit le seul tampon entre vos données véritablement sécurisées et les voleurs d'identité potentiels? Non.