Les principales failles de sécurité des applications web actuelles, telles que recensées par l'OWASP: principes, parades et bonnes pratiques de développement

5. BONNES PRATIQUES

5.1 Règles de développement

Il est possible de se protéger de la plupart des attaques expliquées précédemment en suivant les règles de développement suivantes.

Toutes les données doivent être vérifiées. Les valeurs saisies dans un formulaire doivent être validées au niveau du navigateur avec du code JavaScript, car le client n'est pas une source fiable. Il n'est pas certain que ce soit l'utilisateur de l'application qui envoie la requête http. Les valeurs doivent également être contrôlées au niveau du serveur au moment de la récupération des paramètres, tout comme les paramètres de requête. Ainsi pour chaque valeur :

· La longueur de la valeur saisie doit être contrainte avec une taille minimale et une taille maximale ;

· Seules les lettres de l'alphabet et/ou les chiffres doivent être acceptés par défaut, tous les autres caractères devant être refusés. Dans le cas où d'autres caractères doivent être autorisés, ils doivent être limités à une liste prédéfinie ou être remplacés par les codes HTML.

Il faut privilégier l'utilisation des requêtes POST. Cela permet de ne pas prendre en compte des paramètres frauduleux dans les adresses.

Les requêtes SQL ne doivent pas être construites dynamiquement. Il faut utiliser les requêtes paramétrées. Ainsi, les requêtes SQL ne peuvent pas être parasitées comme c'est le cas dans le cas de l'injection SQL (voir paragraphe 3.1).

Dans la mesure du possible, il est préférable d'utiliser des outils existants plutôt que de développer des fonctionnalités souvent présentes dans les applications.

Toutes les pages d'une application Web doivent s'assurer que l'utilisateur s'est authentifié préalablement. Pour les fonctionnalités manipulant des données sensibles, l'application doit demander à l'utilisateur de s'authentifier à nouveau avant de les afficher. Cela permet de s'assurer qu'il n'y a pas eu usurpation d'identité. Les messages d'erreur renvoyés doivent être générique pour ne pas aiguillé les attaquants potentiels.

Les données sensibles doivent être chiffrées dans les bases de données.

La protection des mots de passe, des identifiants de session et des cookies permet de se prémunir contre l'usurpation d'identité. Pour cela, le mot de passe doit avoir au moins six caractères, voire même huit pour les accès aux données sensibles. Il doit également contenir au moins trois types de caractères, tels que des chiffres, des lettres minuscules, des lettres majuscules ou des caractères spéciaux. Il doit avoir une période de validité de maximum quatre-vingt-dix jours. Au-delà, il doit être changé. Le compte de l'utilisateur doit être verrouillé, au moins temporairement, si cinq tentatives de connexions consécutives ont échoué. Le mot de passe doit être chiffré. Seule sa valeur chiffrée sera comparée lors de l'authentification de l'utilisateur.

Les identifiants de session doivent avoir une durée de vie limitée au-delà de laquelle il n'est plus utilisable. De même, après une période d'inactivité prédéfinie, l'identifiant de session soit être invalidé. En cas de fermeture du navigateur, l'identifiant de session doit être supprimé. Ces actions sont équivalentes à un système de déconnexion automatique.

Les cookies doivent être protégés en positionnant deux attributs. « Secure » permet d'interdire l'envoie du cookie sur un canal non chiffré. « HTTPonly » permet d'en interdire l'accès à JavaScript.