Ce qui entre dans le périmètre
- Projets personnels
- Projets open source
- Travaux et POC d’analyse de vulnérabilités sur des bibliothèques bancaires open source
Sur quoi je fais de la sécurité offensive, et sur quoi jamais
Mes tests d’intrusion portent sur mes propres projets et sur des projets open source uniquement. Jamais sur un système client.
Le périmètre s’écrit avant tout le reste
Ce qui n’y entre jamais
- Systèmes clients
Où je m’entraîne
Des attaques réelles, observées sans exposer personne
3étapes, du trafic capté à l’issue ouverte
Honeypots
Des honeypots maison tournent sur un petit VPS et enregistrent tout le trafic.
Analyse des journaux
Les journaux sont compilés et analysés par IA pour dégager des patterns d’attaque et proposer des correctifs.
Remontée aux projets
Des issues sont ensuite ouvertes sur les projets concernés.
Ce que ces travaux ont produit, en divulgation responsable
Un prestataire de services de paiement
Une faille de sécurité lui a été remontée en divulgation responsable. Le signalement a été accusé réception et la faille a été corrigée. Ni le tiers ni le détail technique ne sont publiés ici.
I2P
Identification de moyens d’accélérer le protocole : certaines méthodes de chiffrement employées sont dépassées ou moins performantes que les alternatives disponibles. Signalement également d’erreurs d’inattention dans des conditions du TunnelDispatcher.
colibri
Optimisation de la lecture MoE en streaming depuis le disque, pour accélérer l’inférence. Le détail des issues et des correctifs figure dans les contributions open source.
Ce que ça change quand j’écris du cache
La performance et la sécurité se décident au même moment
Sur un catalogue, la performance et la sécurité se décident au même moment. Mettre une réponse en cache, c’est accepter qu’elle soit resservie à quelqu’un d’autre : décider ce qu’on met en cache revient donc à décider ce qu’on accepte de montrer, et à qui.
D’où vient cette lecture
Cette lecture vient de deux endroits qui se répondent : le terrain, et les tests d’intrusion que je mène par ailleurs. Chercher comment on entre quelque part change la façon dont on écrit ce qui sort.
Quelles routes doivent être authentifiées, et lesquelles n’ont pas à l’être ?
- Règle La question se tranche route par route, et avant toute décision de cache. Tant qu’elle n’est pas tranchée, aucune règle de cache n’est écrite dessus.
Deux utilisateurs différents peuvent-ils recevoir la même réponse ?
- Règle Le cache est segmenté selon le jeton d’authentification. Sans cette segmentation, une réponse calculée pour un utilisateur finit par être resservie à un autre.
Un prix et un titre de produit ont-ils la même durée de cache ?
- Règle Non. Un titre de produit bouge rarement, un prix peut bouger à tout moment. Leur donner la même durée de vie, c’est retenir la plus mauvaise des deux : soit on affiche un prix faux, soit on recalcule un titre pour rien.
Le stock et le prix sont-ils des données publiques ?
- Règle Non : ils varient selon le groupe tarifaire de l’utilisateur. Ils ne peuvent donc pas être mis en cache comme une donnée publique, et c’est ce qui distingue une page produit rapide d’une page produit qui fuit.
La grille de référence
Les types d’attaque sont repris de la grille OWASP, qui sert de liste de contrôle plutôt que de garantie.
Ce qui reste en dette
Il reste des endroits dont on sait qu’ils portent de la dette. Les nommer précisément n’aurait pas sa place sur une page publique ; les connaître et les tenir à jour vaut mieux que de prétendre qu’il n’y en a pas.