Corriger mes propres constatations : un plan de remédiation, classé par risque

Dans mon modèle de menace de ce formulaire de contact, j'ai terminé avec quatre faiblesses que j'avais trouvées dans ma propre conception. Trouver des problèmes est la partie facile. La partie plus difficile est de décider ce que corriger en premier, comment et ce qu'il ne faut pas corriger du tout.

Ce billet est cette deuxième partie : un petit plan de remédiation réel.

Comment je les ai classées

Un moyen simple de comparer les risques est de poser deux questions sur chacun :

• Probabilité : quelle est la probabilité que cette faiblesse soit réellement exploitée, ou cause des dommages ?
• Impact : si cela se produit, à quel point est-ce grave, et pour qui ?

La matrice ci-dessus est mon propre jugement, et non une mesure. C'est normal : la plupart des évaluations de risques réelles sont des jugements éclairés, écrits pour que les autres puissent les remettre en question. La valeur réside dans la mise en évidence de la logique.

1. Messages conservés à jamais : corriger en premier

Le risque. Chaque message envoyé via le formulaire reste dans la base de données indéfiniment. Chacun contient un nom, une adresse e-mail et tout ce que la personne a choisi de me dire. Si la base de données était jamais exposée, par le biais d'une information d'identification divulguée ou d'une erreur de ma part, tout ce qui a été envoyé serait exposé avec elle.

Pourquoi il est classé premier. L'impact touche les autres personnes, qui m'ont fait confiance pour leurs coordonnées. Et la probabilité qu'un magasin de données, quelque part, soit finalement exposé au fil des ans n'est pas faible. Les données que vous ne conservez pas ne peuvent pas fuir.

La correction. Un travail planifié qui supprime les messages plus anciens qu'une période fixe. Les Cloudflare Workers prennent en charge les déclencheurs cron, donc le même Worker qui reçoit les messages peut exécuter une requête quotidienne DELETE FROM messages WHERE created_at < …. Douze mois me semblent appropriés : suffisamment long pour suivre une conversation, suffisamment court pour limiter ce qu'une faille pourrait révéler. Cela rapproche également le site du principe de limitation de stockage de la loi sur la protection des données du Ghana, 2012 (loi 843).

2. 'unsafe-inline' dans la politique de script

Le risque. La politique de sécurité du contenu du site permet les scripts intégrés. La CSP est un filet de sécurité contre les scripts intersites (XSS) : si un attaquant parvenait à injecter un script dans une page, une politique stricte l'empêcherait de s'exécuter. Avec 'unsafe-inline', le filet a un trou à l'endroit exact où il ne faut pas.

Pourquoi il est classé deuxième. La probabilité est faible : le site est statique et n'affiche pas de contenu soumis par l'utilisateur, il n'y a donc pas de point d'injection évident aujourd'hui. Mais l'impact d'un XSS réussi sur chaque visiteur serait élevé, et la défense en profondeur signifie ne pas se fier à « il n'y a pas de bogue aujourd'hui ».

La correction. Remplacer 'unsafe-inline' par un hachage pour chaque script intégré. Au moment de la construction, calculer le hachage SHA-256 de chaque script intégré et lister ces hachages dans la politique. Le navigateur exécute alors uniquement les scripts dont le contenu exact j'ai approuvé. Puisque le site est statique, les hachages ne changent que lorsque je modifie un script, cela peut donc être automatisé dans la construction.

3. Une limite de débit qui peut être concurrencée

Le risque. La limite de cinq messages par heure par IP est stockée dans Cloudflare KV, qui est éventuellement cohérent, et le code lit le compteur puis l'écrit en deux étapes distinctes. Un flux de requêtes envoyées en parallèle peut toutes lire le même ancien décompte et dépasser légèrement la limite.

Pourquoi il se classe troisième. Il est facile de déclencher mais l'impact est faible : quelques messages de spam supplémentaires qui doivent encore passer la vérification du bot Turnstile. Pour un formulaire de contact, une limite approximative est acceptable. Ce ne serait pas acceptable pour quelque chose comme les tentatives de connexion.

La solution. Déplacer le compteur vers quelque chose avec des mises à jour atomiques : soit la limitation de débit intégrée de Cloudflare pour les Workers, soit un objet durable, qui traite les requêtes pour une clé donnée une à la fois. L'un ou l'autre supprime la course.

4. Les IPs partagées partagent une limite : accepter, documenter, surveiller

Le risque. De nombreux réseaux mobiles placent un grand nombre d'utilisateurs derrière un petit pool d'adresses IP publiques partagées. Sur un tel réseau, un utilisateur abusive pourrait utiliser la limite horaire pour des personnes innocentes qui partagent leur adresse.

Pourquoi j’accepte cela. Chaque alternative a un coût. Limiter par adresse e-mail est facile à éviter avec des adresses fictives. Supprimer la limite d'IP affaiblirait la protection contre les inondations. Augmenter la limite considérablement laisserait passer plus de spam. Étant donné qu'un visiteur bloqué peut simplement essayer à nouveau plus tard ou m'envoyer un e-mail directement, le préjudice est faible.

Ce que signifie « accepter ». Accepter un risque est une décision légitime, mais seulement lorsqu'il est conscient et enregistré. Je l'écris donc ici, avec le raisonnement, et je le réexaminerai si je vois jamais des visiteurs réels être bloqués. Si cela était un service pour des milliers d'utilisateurs mobiles, plutôt que pour un formulaire de contact personnel, je le classerais beaucoup plus haut.

Ce que cet exercice m'a enseigné

Deux leçons :

• Pas chaque constatation est urgente. Le classement par probabilité et impact m'a empêché de passer mon temps sur la solution technique la plus intéressante (la course de limitation de débit) avant celle qui protège réellement les gens (la suppression des anciennes données).
• « Corriger », « atténuer » et « accepter » sont tous des résultats valides, tant que le choix est délibéré. Un plan de sécurité qui prétend tout corriger est généralement celui qui n'a pas regardé suffisamment de près.

Je mettrai à jour cet article à mesure que chaque correction sera publiée.

Êtes-vous en désaccord avec mon classement ? J’aimerais entendre pourquoi.