Bonnes pratiques permettra de se prémunir contre la plupart des risques de sécurité dans le développement des applications Web

Le Web est devenu un lieu où on peut échanger des informations mais il est également devenu un marché à part entière pour la vente et l’achat de biens matériels. Les acteurs de ce nouveau marché ont besoin de sécurité sous tous ses aspects, tels que définis par l’ANSSI (Agence Nationale de Sécurité des Systèmes d'Information) « la protection de la confidentialité, de l’intégrité et de la disponibilité de l’information ».

Dans ce contexte, de nombreux organismes ont été constitués afin de lutter et de prévenir les risques liés à la sécurité des informations sur le Web.

1. Bonnes Pratiques

1.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 quelques règles de développement.

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

1.3 Privilégier l’utilisation des requêtes POST

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

1.3 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).

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

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