accueilLogicielsDéveloppement et Qualité LogicielsFailles de sécurité des applications Web
 

Règles de développement

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


1. Toutes les données doivent être vérifiées
2. Privilégier l’utilisation des requêtes POST
3. Utiliser les requêtes paramétrées
4. Ne pas réinventer la roue
5. Sécuriser l’accès aux données

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. 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. Il n’est pas certain que ce soit l’utilisateur de l’application qui envoie la requête http. Ainsi pour chaque valeur :
- Vérifier que le type correspond à celui attendu
- Pour plus de sécurité, caster les données avant de les mettre dans des variables
- Coder les caractères spéciaux avec le code HTML correspondant
- Vérifier la présence de tous les arguments attendus
- Pour les nombres, contraindre la valeur entre deux bornes
- Pour les listes, vérifier que la valeur appartient à la liste des valeurs autorisées (select, radio, checkbox, …)
- Contraindre la longueur de la valeur saisie avec une taille minimale et une taille maximale
- Vérifier la valeur avec une expression régulière
- N’accepter que les lettres de l’alphabet et/ou les chiffres 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.
- Vérifier si la valeur nulle doit être acceptée
- Définir le jeu de caractère de la donnée.

 Même les données envoyées vers l’utilisateur doivent être vérifiées, avec au minimum les actions suivantes :
- Coder les caractères spéciaux avec le code HTML correspondant
- Définir le jeu de caractère de la page.

Privilégier l’utilisation des requêtes POST

 Cela permet de ne pas prendre en compte des paramètres frauduleux dans les adresses.

Utiliser les requêtes paramétrées

 Les requêtes SQL ne doivent pas être construites dynamiquement. 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.2).

Ne pas réinventer la roue

 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, comme les systèmes d’authentification ou de réinitialisation de mot de passe.

Sécuriser l’accès aux données

 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 huit caractères, voire même dix 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é ou haché avec un algorithme fort. 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.

 

Retour vers le haut de la page   PDF
Article précédent Page d'accueil Article suivant
< Bonnes pratiques Sommaire | Configuration des composants serveur >

 

Guillaume HARRY
Envoyer un courriel

 

Contenu sous licence Creative Commons CC-BY-NC-ND


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits