Vaubyn

Audit de sécurité / Tests d’intrusion / Développement sur mesure

On ne défend bienque ce que l’on saitattaquer.

Vaubyn éprouve la sécurité de vos applications web et de vos API, et développe du logiciel sur mesure. Deux métiers, un seul savoir.

Parler d’une mission

« Ville assiégée par Vauban, ville prise ; ville défendue par Vauban, ville imprenable. »

Dicton du temps de Louis XIV

Vauban prenait les places fortes et les bâtissait. Il excellait dans les deux pour une raison simple : c’est le même savoir. Vaubyn l’applique au logiciel : attaquer vos applications pour montrer où elles cèdent, et en développer qui tiennent.

Pl. I — L’attaque

Mieux vaut être attaquépar quelqu’un qui vousremettra un rapport.

  1. 01

    Tests d’intrusion d’applications web

    Votre application, attaquée comme elle le sera un jour : authentification, contrôle d’accès, logique métier, traitement des entrées. À la main, là où les outils automatiques ne voient rien.

  2. 02

    Tests d’intrusion d’API

    Une API expose vos données et vos règles métier sans interface pour faire écran. Tout ce qu’un compte peut lire ou faire au-delà de ses droits y est recherché, requête par requête.

  3. 03

    Revue de sécurité applicative

    La même application, vue de l’intérieur : conception, code, configuration. Pour trouver ce que les tests menés du dehors ne montrent pas.

  4. 04

    Rapport et recommandations

    Chaque faille est décrite, démontrée et classée par gravité, avec la correction qui la referme. Un document fait pour être appliqué, pas archivé.

Pl. II — Le siège

Un siège en règle.

  1. ICadrage

    Investir

    Avant toute chose, un périmètre et une autorisation écrite : ce qui sera testé, quand, depuis où, et jusqu’où aller. Rien ne se passe en dehors de cette ligne.

  2. IICartographie

    Reconnaître

    Relever la surface d’attaque comme on lève le plan d’une place : points d’entrée, rôles, flux de données, dépendances. On n’attaque bien que ce que l’on a compris.

  3. IIITests

    Approcher

    En 1673, devant Maastricht, Vauban fait creuser ses premières parallèles : avancer à couvert, méthodiquement. Ici, chaque hypothèse est vérifiée, chaque piste consignée.

  4. IVDémonstration

    Ouvrir la brèche

    Une faille ne compte que si elle est démontrée : preuve à l’appui, impact établi, et le souci constant de ne rien dégrader chez vous.

  5. VRapport

    Rendre le mémoire

    De chaque place, Vauban tirait un mémoire. Vous recevez le vôtre : les failles, leur gravité, et la manière de les corriger.

Pl. III — Le mémoire

Un rapport faitpour être appliqué.

C’est le seul livrable qui compte. Chaque constat y répond à quatre questions : qu’est-ce qui est cassé, comment le prouver, qu’est-ce que cela coûte, comment le réparer.

Spécimen — cible et données fictives

Constat n° 3

Contrôle d’accès défaillant sur les factures

GET, PUT /api/v2/invoices/{id}

Gravité
Élevée
CVSS 3.1
8.1
Vecteur
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Constat
L’API vérifie que l’appelant est authentifié, mais pas que la facture demandée lui appartient. En changeant l’identifiant dans l’adresse, un client lit les factures de tous les autres ; la même requête en PUT les modifie.
Preuve
GET /api/v2/invoices/10482 HTTP/1.1
Host: app.exemple.test
Authorization: Bearer <jeton du compte A>

HTTP/1.1 200 OK
{ "id": 10482, "client": "compte B", … }
Impact
Divulgation et altération des données de facturation de l’ensemble des clients, depuis n’importe quel compte.
Correction
Vérifier côté serveur, à chaque requête, que la ressource appartient au compte authentifié, et centraliser ce contrôle plutôt que le répéter route par route. Des identifiants imprévisibles ne le remplacent pas.

Pl. IV — L’ouvrage

Bâtir, en sachantcomment on attaque.

Du logiciel sur mesure, écrit par quelqu’un dont l’autre métier est de le casser. La sécurité n’y est pas une couche ajoutée à la fin : elle est dans le tracé.

Le tracé avant la pierre
Comprendre le besoin, dessiner l’architecture, puis seulement écrire. Les erreurs coûtent moins cher sur le plan.
Rien de superflu
Chaque ligne de code est une surface à défendre. Moins il y en a, mieux elle tient.
Fait pour être repris
Un code lisible, que vous pourrez faire évoluer sans Vaubyn.

Pl. V — Les faits

Trois faits,plutôt que des promesses.

  1. I

    Un seul interlocuteur

    Du premier échange à la remise du rapport, vous parlez à la même personne. Celui qui cadre la mission est celui qui teste, et celui qui signe. Aucun passage de relais : rien ne se perd en route.

  2. II

    Le terrain, en continu

    En dehors des missions, la recherche de failles se poursuit sur YesWeHack, plateforme de bug bounty : des systèmes réels, en production, que d’autres chercheurs examinent au même moment.

  3. III

    Ce site, pour commencer

    Aucun cookie, aucun traceur, aucune ressource tierce. Une politique de sécurité de contenu stricte, sans exception pour les scripts en ligne. Ne le croyez pas sur parole : ouvrez vos outils de développement.

    security.txt

Pl. VI — Correspondance

Décrivezla place.

Une application à éprouver, un logiciel à bâtir : quelques lignes suffisent pour commencer.

contact@vaubyn.fr