Comment concevoir des formulaires Web sécurisés: valider, désinfecter et contrôler

Alors que la cybersécurité est souvent considérée en termes de bases de données et d'architecture, une bonne posture de sécurité repose sur des éléments du domaine du développeur front-end.

Pour certaines vulnérabilités potentiellement dévastatrices comme l'injection SQL et le Cross-Site Scripting (XSS), une interface utilisateur bien pensée est la première ligne de défense.

Voici quelques domaines d'intérêt pour les développeurs front-end qui veulent aider à combattre le bon combat.

Contrôler l'entrée utilisateur

Tout un tas de choses folles peuvent se produire lorsque les développeurs créent un formulaire qui ne parvient pas à contrôler l'entrée utilisateur. Pour lutter contre les vulnérabilités telles que l'injection, il est important de valider ou de nettoyer les entrées utilisateur.

Vous pouvez valider l'entrée en la contraignant à des valeurs connues, par exemple en utilisant des types d'entrée sémantique ou des attributs liés à la validation dans les formulaires. Des frameworks comme Django aident également en fournissant des types de champs à cet effet. La désinfection des données peut être effectuée en supprimant ou en remplaçant des caractères contextuellement dangereux, par exemple en utilisant une liste blanche ou en échappant les données d'entrée.

Bien que cela puisse ne pas être intuitif, même les données qu'un utilisateur soumet à sa propre zone sur un site doivent être validées. L'un des virus les plus rapides à proliférer était le ver Samy sur MySpace (oui, je suis vieux), grâce au code que Samy Kamkar a pu injecter dans sa propre page de profil. Ne renvoyez aucune entrée directement sur votre site sans validation ou désinfection approfondie.

Pour plus d'informations sur la lutte contre les attaques par injection, consultez la feuille de triche de prévention des injections OWASP.

Méfiez-vous des champs cachés

L'ajout type="hidden"est un moyen très pratique de masquer des données sensibles dans des pages et des formulaires, mais malheureusement pas efficace.

Avec des outils comme ZapProxy et même des outils d'inspection dans de simples navigateurs Web, les utilisateurs peuvent facilement cliquer pour révéler de savoureuses informations invisibles.

Le masquage des cases à cocher peut être un bon hack pour créer des commutateurs CSS uniquement, mais les champs cachés contribuent peu à la sécurité.

Considérez attentivement les champs de saisie automatique

Lorsqu'un utilisateur choisit de vous donner ses informations personnelles identifiables (PII), cela doit être un choix conscient. Les champs de formulaire de saisie automatique peuvent être pratiques, tant pour les utilisateurs que pour les attaquants. Les exploits utilisant des champs masqués peuvent récolter des informations personnelles précédemment capturées par un champ de saisie semi-automatique.

De nombreux utilisateurs ne savent même pas quelles informations la saisie automatique de leur navigateur a stockées. Utilisez ces champs avec parcimonie et désactivez les formulaires remplis automatiquement pour les données particulièrement sensibles.

Il est également important de comparer votre profil de risque à ses compromis. Si votre projet doit être conforme aux WCAG, la désactivation de la saisie semi-automatique peut interrompre votre saisie pour différentes modalités. Pour plus d'informations, voir 1.3.5: Identifier le but de l'entrée dans WCAG 2.1.

Gardez les erreurs génériques

S'il peut sembler utile de faire savoir aux utilisateurs si une donnée existe, c'est également très utile pour les attaquants. Lorsqu'il s'agit de comptes, d'e-mails et d'informations personnelles, il est plus sûr de se tromper (?) Du côté de moins. Au lieu de renvoyer «Votre mot de passe pour ce compte est incorrect», essayez le commentaire plus ambigu «Informations de connexion incorrectes» et évitez de révéler si le nom d'utilisateur ou l'adresse e-mail se trouve dans le système.

Afin d'être plus utile, fournissez un moyen bien visible de contacter un humain au cas où une erreur se produirait. Évitez de révéler des informations qui ne sont pas nécessaires. Si rien d'autre, pour l'amour du ciel, ne suggérez pas de données qui correspondent étroitement à l'entrée de l'utilisateur.

Soyez un méchant

En ce qui concerne la sécurité, il est utile de prendre du recul, d'observer les informations affichées et de se demander comment un attaquant malveillant pourrait les utiliser. Jouez l'avocat du diable. Si un méchant voyait cette page, quelles nouvelles informations gagnerait-il? La vue affiche-t-elle des informations personnelles?

Demandez-vous si tout sur la page est réellement nécessaire pour un utilisateur authentique. Sinon, biffez-le ou supprimez-le. Moins est plus sûr.

La sécurité commence à la porte d'entrée

Ces jours-ci, il y a beaucoup plus de chevauchement entre le codage sur le front-end et le back-end. Pour créer une application bien équilibrée et sécurisée, il est utile d'avoir une compréhension générale des moyens par lesquels les attaquants peuvent mettre le pied dans la porte d'entrée.