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

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ères 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ères de la page.

2. Privilégier l'utilisation des requêtes POST

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

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 III.B).

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.

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ériques pour ne pas aiguiller 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 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 connexion 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 doit ê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'envoi du cookie sur un canal non chiffré, « « HTTPonly » permet d'en interdire l'accès à JavaScript.

B. Configuration des composants serveur

Pour des raisons de capacité de calcul, la taille minimale des clés symétriques utilisées jusqu'en 2020 doit être de 100 bits et de 128 bits au-delà de 2020.

Si le caractère confidentiel des données nécessite la mise en place du chiffrement des flux, toutes les pages doivent être protégées et pas seulement celles manipulant ces données.

Les outils installés doivent être mis à jour avec le correctif le plus récent.

Les options inutilisées des outils installés doivent être supprimées ou désactivées. Les comptes créés lors de l'installation des outils doivent être au minimum verrouillés ; le plus sûr étant de les supprimer.

Le serveur HTTP ne doit pas afficher le contenu d'un répertoire.

C. Audit

Pendant la phase de développement, les tests unitaires permettent de vérifier le comportement d'une fonction de l'application. Ils peuvent être utilisés pour s'assurer que les règles de développement citées précédemment sont respectées. En complément, les outils d'intégration continue, tels que « Jenkins » ou « Hudson », permettent de vérifier à chaque modification de code qu'elle n'engendre pas de régression. L'utilisation conjointe de cette panoplie d'outils facilite les audits de code et permet même de les automatiser lors des phases de maintenance.

De plus, l'OWASP offre des outils de test du code et du comportement des applications Web. Ainsi, l'outil « Code Crawler » permet d'analyser le code d'applications .NET et Java. « WebScarab » agit comme un serveur proxy et permet à l'auditeur d'analyser les échanges HTTP pour chercher des failles de sécurité. « Zed Attack Proxy » est un scanner qui permet de détecter automatiquement certaines vulnérabilités. Quant au WASC, il ne fournit pas d'outil, mais un guide pour comparer les différentes offres commerciales ou non d'automatisation de détection des problèmes liés à la sécurité des applications Web.

Par ailleurs, en condition opérationnelle, les fichiers de journalisation des différents composants de l'architecture doivent faire l'objet d'un audit régulier afin de s'assurer que l'application ou le serveur n'a pas été victime de tentative d'attaque par la force brute.

Conclusion

Constat

Depuis la version de 2004, le classement de l'OWASP a peu évolué. En effet, sept problèmes répertoriés en 2010 étaient déjà présents en 2004 comme le montre le tableau ci-dessous.

Cela signifie que le Web 2.0 a apporté du confort à l'utilisateur mais n'a pas apporté des failles plus dangereuses que celles déjà présentes. En effet, AJAX permet d'étendre les possibilités des attaques. Ainsi, le vol d'informations par CSRF prend une nouvelle forme. Tout comme l'attaque CSRF classique expliquée dans le paragraphe 3.6, un utilisateur ouvre une page Web frauduleuse. Ensuite l'attaquant profite du mode asynchrone de la fonction « XMLHttpRequest » pour parcourir la page de l'application affichée, voler le cookie et envoyer les données à l'attaquant. Les protections contre CSRF restent efficaces, mais se protéger de la seconde phase de l'attaque est plus délicat. Par ailleurs AJAX permet d'outrepasser la protection interdomaines offerte par les navigateurs.

Bien que de nouvelles failles émergent avec le Web 2.0, les applications Web sont toujours vulnérables aux failles les plus anciennes. Cela démontre que le comportement des développeurs n'a pas changé. Pressés par des contraintes de temps, ils ne font pas l'effort d'appliquer quelques règles de base qui permettent de se défendre contre les attaques les plus dangereuses.

Perspectives

2012 va marquer l'arrivée de nouveaux standards : HTML 5 et CSS 3. Leur objectif est de combler les lacunes de leurs prédécesseurs utilisés depuis bientôt quinze ans. Les développeurs espèrent qu'avec ces nouvelles versions, l'utilisation de JavaScript diminue, allégeant ainsi le code des applications Web et diminuant par la même occasion le nombre des vulnérabilités. Le coût de mise à jour des applications Web actuelles risque de freiner l'adoption de ces nouvelles normes. Les organismes de sécurité devront également s'impliquer pour mettre à disposition des développeurs de nouvelles bonnes pratiques.