Accès, injection et authentification

Accès, injection et authentification

1. Contrôle d'accès défaillant (A01)

   C'est le premier risque du classement 2025. Il ne s'agit pas seulement d'oublier une vérification : c'est le cas classique où l'application vérifie l'accès sur l'écran mais pas sur l'API.

   Vérifier côté serveur, à chaque requête

   # FAIBLE : le controle est dans l'ecran, l'API reste ouverte
   @app.route("/api/tickets")
   def liste():
       return jsonify(Ticket.query.all())   # n'importe quel utilisateur voit tout
   
   # CORRECT : le controle est dans la couche d'acces
   @app.route("/api/tickets/<id>")
   @require_authenticated
   def detail(id):
       ticket = Ticket.query.get_or_404(id)
       if ticket.dossier_id != g.utilisateur.dossier_id:
           abort(403)          # on verifie la propriete, pas seulement l'identite
       return jsonify(ticket.serialize())

   La règle : une donnée appartient à quelqu'un. La question n'est jamais « l'utilisateur est-il connecté ? » mais « cette donnée lui appartient-elle ? ».

   Le test systématique

   Pour chaque point d'accès : lister ce que l'API expose, puis demander chaque ressource avec les identifiants d'un autre utilisateur. Ce contrôle, appelé test d'IDOR (référence directe non sécurisée), trouve plus de failles que l'analyse de code.

2. Injection (A05)

   Une injection survient quand une donnée utilisateur est concaténée dans une commande interpretée : requête SQL, commande système, expression régulière, requête NoSQL.

   Le principe

   # Vulnerable : la saisie est concatenee dans la requete
   cur.execute("SELECT * FROM users WHERE nom = '" + nom + "'")
   
   # Correct : la requete est preparee, la valeur est un parametre lie
   cur.execute("SELECT * FROM users WHERE nom = %s", (nom,))

   La requête préparée n'est pas « le SQL le plus sûr » : c'est une frontière. Le moteur reçoit la structure d'un côté, les données de l'autre, et ne les mélange jamais.

   Les autres vecteurs

   • Système : ne jamais passer une saisie à un shell ; utiliser un appel direct au programme avec une liste d'arguments.
   • NoSQL : un objet passé tel quel peut devenir un opérateur ; vérifier le type avant usage.
   • Expressions régulières : une entrée utilisateur dans un motif peut provoquer un accès inattendu aux données, voire un déni de service.
   • En-têtes et journaux : un retour à la ligne dans un journal permet d'y injecter une fausse entrée — c'est l'injection de journal.

   Priorité : la requête préparée d'abord, la validation en second. Valider en déniant des caractères spécifiques est fragile ; la requête préparée tient quelle que soit la donnée.

3. Défaillances d'authentification (A07)

   • Mots de passe : hachage avec un algorithme lent et salé (bcrypt, Argon2, scrypt). Un algorithme rapide est une catastrophe : il accélère aussi l'attaque par force brute.
   • Stockage des sessions : un jeton d'authentification doit être aléatoire, conservé côté serveur, invalidé à la déconnexion et à la réinitialisation du mot de passe.
   • Limitation : après quelques échecs, la tentative doit être ralentie ou bloquée, sans laisser d'information sur l'existence du compte.
   • Réinitialisation : le lien de réinitialisation doit être à usage unique et expirer rapidement.
   • Multi-facteurs : activé par défaut sur les comptes à privilèges.

   Deux erreurs classiques : un message d'erreur qui distingue « compte inconnu » de « mot de passe faux », et un mot de passe oublié qui ne change pas la session courante — l attaquant reste connecté.

4. Exercices

   1. Test d'IDOR : sur une application de votre atelier, listez les points d'accès qui exposent une ressource par identifiant et testez-les avec un autre compte.
   2. Correction d'injection : réécrivez une recherche qui concatène, en requête préparée. Ajoutez un caractère spécial en entrée pour vérifier que la correction tient.
   3. Revue d'authentification : relevez les messages d'erreur, la vitesse de réponse, la politique de mot de passe et la réinitialisation. Notez chaque écart.