Formation PUB040 : JavaScript et autres bibliothèques côté client, 2020 jQuery.ajax()

9.5 La sécurité avec AJAX


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

Same Origin Policy (SOP)

À 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 :

  • d'un même nom de domaine (et sous-domaine), 
  • d'un même protocole,
  • d'un même port. 

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.

Techniques pour sécuriser les sites utilisant AJAX

Malgré le Same Origin Policy, les applications utilisant AJAX demeurent vulnérables. Voici quelques pistes de solution permettant de limiter les risques.

Effectuer des envois via POST plutôt que GET

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.

Ne jamais envoyer d'informations sensibles du serveur au client via AJAX

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.

Utiliser les nonces

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.

Nettoyer les informations avant l'affichage et avant l'utilisation dans une requête SQL

Dans tout traitement Web, avec ou sans AJAX, les informations provenant de l'usager peuvent comporter des risques.

  • Celles destinées à l'affichage doivent être nettoyées afin d'assurer qu'elles soient exemptes de tout code pouvant provoquer une attaque XSS (ex : balise <script>).
  • Les requêtes SQL utilisant des données provenant de l'usager doivent être protégées à l'aide d'un mécanisme comme les requêtes préparées, aussi appelées requêtes paramétrables.

Vérifier si l'usager possède les droits requis pour l'opération à effectuer

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.

Toujours valider les informations côté serveur en plus des validations client

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é.

Utiliser un certificat numérique SSL

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.

Pour plus d'information

« 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/

Veuillez noter que le contenu de cette fiche vous est partagé à titre gracieux, au meilleur de mes connaissances et sans aucune garantie.
Par Christiane Lagacé
Dernière révision le 18 août 2017
Merci de partager !

Site fièrement hébergé chez A2 Hosting.

Soumettre