Posts Tagged ‘sécurité’

[Traduction] Points d’attaque : PHP et Ajax

19 octobre 2007 in Ajax, PHP
Étiquettes : , , ,

(titre d’origine : Points of Attack: PHP and Ajax)
publié le mardi 28 août 2008, à 16h28
par Matthew McCool
sur O’Reilly.net/OnLAMP

Il est facile d’être impressionné par le potentiel d’Ajax. Mais, en même temps que les nombreuses possibilités offertes, les risque sont accrus. Si la sécurité n’est pas une priorité, cela devrait l’être.

Imaginons un formulaire d’inscription traité par PHP. Chaque aspect de votre script qui accepte et manipule les données est un point d’attaque potentiel. Si vous ajoutez de l’Ajax, ce que vous faites revient à augmenter la complexité de l’application, et de fait, introduire une vulnérabilité plus grande. Plus de points d’entrée induit une plus grande surface d’attaque, et cela implique des problèmes potentiels pour votre application.

Imaginez le déroulement d’une inscription : un utilisateur essaye de choisir son nom d’utilisateur dans un formulaire standard PHP/MySQL. L’information est entrée dans les champs, les données sont envoyées au serveur qui vérifie l’existence ou l’absence d’un nom d’utilisateur dans la base de données et un message d’erreur est renvoyé à l’utilisateur. Il n’y a qu’un point d’attaque dans ce scénario : le traitement du formulaire. Mais que se passe-t-il si le formulaire est soumis par un validateur Ajax ?

Le processus de vérification Ajax est simplifié car les résultats sont retournés en temps réels. Bien que le formulaire soit encore soumis pour validation et les données confrontées à la base de données des utilisateurs existants, l’outil Ajax accélère le processus en donnant un retour immédiat sur la probabilité qu’un nom d’utilisateur soit disponible.Bien que l’implémentation Ajax soit plus ergonomique, la surface d’attaque a doublé – en regard du traitement originel de la validation du nom d’utilisateur. Il existe deux techniques utiles pour minimiser les points d’attaque.

Premièrement, vous devez garder tous les points d’entrée dans le même script. Si vous validez un formulaire inhabituellement long, essayez ensuite d’utiliser le même script PHP pour la validation complète.Vous ne devriez pas utiliser des scripts séparés pour valider les nombreux champs, bien que je ne voie pas pourquoi vous voudriez faire cela.

Ensuite, vous devriez envisager l’utilisation de fonctions standards pour traiter les entrées utilisateurs.Vous ne voulez sans doute pas de balises HTML dans votre base de données, donc c’est une bonne idée d’utiliser les fonctions natives. Cela fait plus de sens d’utiliser strip_tags() pour ôter les balises inutiles et ensuite d’utiliser mysql_real_escape_string() pour insérer dans la base.

Le principe de base est d’utiliser les fonctions natives de PHP parce qu’elles ont été testées rigoureusement par de nombreux développeurs.

• htmlentities: affiche littéralement les balises
• mysql_real_escape_string: protège des injections SQL et des erreurs SQL
• preg_quote: protection des expressions régulières
• preg_replace:enlève les caractères indésirables dans une chaîne
• strip_tags:enlève les balises HTML d’une chaîne