Sécurité : ce que j’apprends

La sécurité est la partie de l’ingénierie que j’apprends en ce moment. Je ne suis pas spécialiste en sécurité, et cette note ne prétend pas le contraire. Elle dit où j’en suis, avec des exemples tirés de mes projets plutôt que des intentions, et elle s’enrichira au fil du temps.

D’où je pars

Construire des applications web, mobiles et backend place du côté de la défense pour la plupart des problèmes de sécurité : authentification, entrées utilisateur, accès aux données, secrets, dépendances. Ce sont les endroits où une application rencontre le monde extérieur, donc ceux que je regarde en premier. Mon projet de licence, une plateforme d’orientation avec comptes et messagerie, m’a d’ailleurs fait lister la protection des données parmi ses limites.

Ce que j’applique déjà

Voici ce que je peux montrer, projet par projet.

Sur Minguili, une application publiée.

• Connexion sans mot de passe par un code à usage unique : valable dix minutes, stocké sous forme de condensat et non en clair, limité à cinq essais, avec un délai avant d’en redemander un.
• Jeton d’accès de quinze minutes gardé en mémoire seulement, jeton de renouvellement dans le stockage sécurisé du téléphone et renouvelé à chaque usage.
• Les prix ne viennent jamais de l’application : le serveur recalcule le devis, donc un client modifié ne peut pas payer moins.
• Webhook de paiement authentifié, état relu à la source, traitement idempotent.
• Au démarrage, le serveur refuse de tourner avec une configuration dangereuse en production.

Sur l’application de la ligue de basketball.

• Pas de page d’inscription : le premier compte administrateur se crée depuis un poste qui a accès à la base.
• Compteur anti-force-brute stocké en base, parce que sur un hébergement sans état la mémoire du serveur ne suffit pas.
• Logo téléversé contrôlé par ses octets et non par ce qu’il annonce, taille limitée, SVG contenant un script refusé.
• La lecture automatique des feuilles de match envoie la photo entière à un fournisseur : je l’ai écrit noir sur blanc dans la documentation, pour que la ligue décide en connaissance de cause.

Sur ce site.

• Le tableau de bord n’écoute que sur la machine locale, hache le mot de passe avec scrypt, exige un jeton CSRF et vérifie l’origine et l’en-tête de l’hôte.
• Les fichiers envoyés sont contrôlés par leur signature, servis avec une politique qui interdit tout script.
• En-têtes de sécurité, un fichier security.txt, et aucun script de suivi.
• Je ne copie jamais un fichier de secrets d’un projet à un autre. Un dépôt peut être lu, ses clés non.

Ce que je cherche à apprendre ensuite

Appliquer des bonnes pratiques n’est pas la même chose que penser comme quelqu’un qui attaque. C’est la partie que je veux travailler : modéliser les menaces d’un système avant de l’écrire, comprendre comment les failles courantes s’exploitent, et lire du code pour les y trouver.

Le plan est simple : pratiquer sur des labs volontairement vulnérables, puis appliquer chaque leçon au code que je livre. Je listerai ici les labs, cours et lectures quand je les aurai faits, avec ce que chacun m’a appris et ce que j’ai changé ensuite.

Ce que cette note ne dit pas

Elle ne dit pas que mes applications sont sûres. Je ne présente aucun audit indépendant de ces applications, et ce site, statique, expose très peu de choses. Ce que je défends ici, c’est une habitude : traiter la sécurité comme une partie du travail et écrire ce que je ne sais pas encore.