Puisque AJAX est basé sur des technologies existantes qui comportent des vulnérabilités, les appels AJAX sont sujets à ces mêmes vulnérabilités : attaques XSS (Cross Site Scripting), attaques CSRF (Cross Site Request Forgery), injections SQL, etc.
Cet article vous présente les protections de base que vous devriez mettre en place dans votre code utilisant AJAX.
▼Publicité Le texte se poursuit plus bas
À la base, les requêtes AJAX bénéficient d'une sécurité nommée Same Origin Policy. Ceci signifie qu'elles permettent de communiquer des informations entre le client et le serveur à l'intérieur :
Il n'est donc pas possible d'appeler par AJAX du code serveur disponible à l'adresse http://domainex.com pour générer une action sur le site Web http://domainey.com. Si tel était le besoin, il faudrait plutôt que http://domainex.com publie un service Web qui pourrait être utilisé à partir d'autres sites Web.
Il y a donc moins de risques qu'on pourrait le croire que notre code serveur puisse être appelé par un programme indésirable.
Malgré le Same Origin Policy, les applications utilisant AJAX demeurent vulnérables. Voici quelques pistes de solution permettant de limiter les risques.
Lors d'une requête AJAX, les données échangées entre le client et le serveur peuvent être de type GET (données encodées directement dans l'URL) ou de type POST (données envoyées au serveur à l'aide d'un mécanisme invisible pour l'usager).
Les requêtes GET sont plus rapides. Mais pour des raisons de sécurité, on réservera leur utilisation pour les appels qui n'ont pas besoin de paramètres.
Dans tous les autres cas, on préférera l'utilisation de POST.
Les informations qui transitent entre le client et le serveur peuvent être interceptées. C'est la réalité du Web.
Parfois, quand un développeur utilise AJAX, il oublie que les informations retournées par le code serveur sont destinées directement au client, donc vulnérables. Ce genre d'oubli ouvre une large porte de sécurité.
Pour cette raison, on évitera l'utilisation d'AJAX pour manipuler des informations sur les usagers, sur les comptes bancaires, etc.
Les nonces (Number used ONCE, c'est-à-dire numéro utilisé une seule fois) sont un mécanisme permettant de valider l'origine d'une requête HTTP.
Ils permettent d'assurer, avant d'effectuer un traitement, que l'envoi du formulaire ou le clic sur le lien ayant déclenché l'action provient bel et bien de votre site et non d'un script ou d'un lien malicieux. Ceci permet notamment de prévenir les attaques CSRF (Cross Site Request Forgery).
L'implémentation d'un nonce dans le code serveur appelé par AJAX constitue donc une mesure de sécurité intéressante, voire même indispensable.
Dans tout traitement Web, avec ou sans AJAX, les informations provenant de l'usager peuvent comporter des risques.
Avant d'effectuer une opération dans le code serveur, il est nécessaire de s'assurer que l'usager authentifié détient les droits requis.
Selon les règles que vous avez mises en place pour votre application, cette vérification peut être très simple (ex : l'opération est permise pour l'usager s'il est authentifié) ou plus complexe (ex : l'usager a le droit de modifier l'enregistrement à condition que ce soit lui qui l'ait ajouté ou l'usager X a le droit d'ajouter un produit seulement dans la catégorie Y).
Comme n'importe quel code serveur, le code appelé par AJAX pourra utiliser une variable de session pour retrouver l'identifiant de l'usager authentifié et ainsi effectuer les vérifications requises.
La validation JavaScript est certainement intéressante puisqu'elle permet de fournir une rétroaction à l'usager très rapidement, avant-même qu'il appuie sur le bouton de soumission. Cependant, elle n'est pas sécuritaire puisque l'usager peut désactiver JavaScript dans son navigateur. Il faut toujours l'accompagner d'une validation côté serveur qui, elle, assure que les données sont valides et ne risquent pas de causer un problème de sécurité.
Les sites Web dont l'URL débute par https sont protégés par un certificat SSL (Secure Socket Layer). Les données qui transigent entre le client et le serveur sont cryptées donc mieux protégées contre le reniflage.
L'utilisation d'un certificat numérique SSL est donc une sécurité supplémentaire pour les sites Web, avec ou sans AJAX.
« Sécurité des applications AJAX ». Cert IST. http://www.cert-ist.com/public/fr/SO_detail?code=securite_ajax
« Ajax Security Issues ». Infosec institute. http://resources.infosecinstitute.com/ajax-security-issues/
« Comment pallier l'insécurité d'Ajax ». Journal du net. http://www.journaldunet.com/developpeur/tutoriel/dht/070625-ajax-in-securite.shtml
« Le B.A.BA de la sécurité oublié par les développeurs Ajax ». 01 Business. http://pro.01net.com/editorial/353852/le-b-a-ba-de-la-securite-oublie-par-les-developpeurs-ajax/
« OWASP AJAX Security Project ». The Open Web Application Security Project (OWASP). https://www.owasp.org/index.php/Ajax
« Quand utiliser GET et quand utiliser POST avec XMLHttpRequest? ». XUL. http://www.xul.fr/scripts/get-ou-post.php
« Javascript and AJAX Security – How to Make Your Website Safe ». Max Kiesler. http://www.maxkiesler.com/2007/11/08/javascript-and-ajax-security-how-to-make-your-website-safe/
« Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet ». The Open Web Application Security Project (OWASP). https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
« Ajax Patterns and Best Practices ». Aperçu Google Livres. https://books.google.ca/books?id=qNzBbUWhGM0C&printsec=frontcover&hl=fr#v=onepage&q&f=false
« Web Security : Using crumbs to protect your PHP API (Ajax) call from Cross-site request forgery (CSRF/XSRF) and other vulnerabilities ». Code with music. http://abhinavsingh.com/web-security-using-crumbs-to-protect-your-php-api-ajax-call-from-cross-site-request-forgery-csrfxsrf-and-other-vulnerabilities/
Site fièrement hébergé chez A2 Hosting.
