19. CSRF : déclenchement d’une action sous une identité

Comprendre le mécanisme

Une attaque CSRF cherche à faire exécuter une action par le navigateur d’un utilisateur dans un contexte que le serveur reconnaît. Un cookie peut être joint automatiquement selon sa politique. L’attaquant n’a pas nécessairement besoin de lire la réponse pour produire l’effet. Les défenses courantes combinent un jeton lié au contexte pertinent, une vérification de provenance lorsque adaptée et une politique de cookies cohérente.

Raisonner et vérifier

Le contrôle CSRF ne remplace ni validation du contenu ni autorisation de la ressource. Un utilisateur légitime muni d’un jeton ne gagne pas le droit d’annuler la réservation d’un autre acteur. SameSite réduit certains chemins mais ne doit pas être présenté comme une solution universelle à tous les scénarios. Une XSS dans l’origine de confiance peut aussi compromettre les hypothèses de la protection.

Identité ambiante

CSRF exploite notamment l’envoi automatique d’une identité. Un effet peut être déclenché sans lecture du résultat. Une page hostile peut provoquer une demande que le navigateur accompagne de cookies selon leur politique. L’attaquant n’a pas nécessairement besoin de lire le cookie ni la réponse pour produire un effet.

Jeton contextualisé

Le serveur doit vérifier un jeton selon son contexte. Le contrôle exige une relation valide avec la session et l’usage. Le serveur vérifie un token lié au contexte prévu avant la mutation. Définissez sa liaison, son transport et sa validation ; la seule présence d’un champ nommé _token ne démontre aucun contrôle.

Défense complémentaire

SameSite peut compléter une défense CSRF. Ses garanties dépendent du contexte et du parcours. SameSite réduit certains envois inter-sites mais ne remplace pas automatiquement le mécanisme CSRF de votre parcours. Les contextes same-site et les règles de navigation doivent être analysés concrètement.

Méthode sûre

Une mutation ne doit pas être demandée par GET. La lecture peut être déclenchée automatiquement. GET ne doit pas annuler ou modifier une réservation. Les lectures automatiques et liens peuvent être déclenchés sans intention de mutation ; utilisez un parcours explicite et les contrôles serveur nécessaires.

CORS

CORS n’est pas un substitut général au contrôle CSRF. Le navigateur peut masquer une réponse après l’effet. Bloquer une lecture cross-origin n’empêche pas toute demande ni tout effet. Conservez une protection d’intention pour les opérations avec identité automatique au lieu d’attribuer cette propriété à CORS.

Ordre du refus

Un token invalide doit être refusé avant mutation. Le refus tardif ne prévient pas l’effet interdit. Validez le token avant save, appel prestataire ou émission de message. Un 403 après annulation est trop tardif ; les tests doivent vérifier la base et les frontières externes.

Droit sur l’objet

Le contrôle de droit sur l’objet reste nécessaire. Il ne prouve pas la propriété de la ressource. Un token CSRF correct peut accompagner la réservation d’un autre utilisateur. Appliquez également l’autorisation sur le sujet ; les deux contrôles répondent à des scénarios de menace différents.

Hypothèse XSS

Une XSS peut compromettre les hypothèses du modèle CSRF. Le script peut agir dans un contexte de confiance compromis. Un script hostile déjà exécuté dans la page peut obtenir des tokens ou déclencher les actions. Prévenir XSS reste nécessaire ; la défense CSRF ne constitue pas une protection générale contre ce script.

Cas négatifs

Les tests doivent couvrir absence et mauvaise valeur. Les cas négatifs vérifient réellement le contrôle. Testez token absent, incorrect et provenant d’un autre contexte selon le contrat. Vérifiez refus et non-effet dans chacun, puis un cas nominal afin de ne pas valider une protection qui bloque tout.

Valeurs sensibles

Les jetons ne doivent pas être publiés dans les logs ordinaires. La corrélation peut être obtenue sans exposer ces valeurs. Évitez de copier les jetons dans les logs et URLs non nécessaires. Les traces peuvent élargir leur distribution ; conservez plutôt catégorie de refus et corrélation non exploitable.

Atelier guidé : lire, expliquer et vérifier le code

// Pseudocode volontairement incorrect :
cancelReservation(id)
if (!validCsrfToken(request.token)) {
    return response(403)
}

Le pseudocode annule avant de vérifier le token. Déplacez la vérification et l’autorisation avant l’effet, puis placez une assertion sur l’état de réservation et les appels aval. Le statut de refus seul ne suffit pas à détecter ce défaut d’ordre.

Retirer la défense ne protège pas la mutation. Le nom du champ ne change pas la validation. Le refus arrive trop tard pour éviter l’effet montré. Le statut ne corrige pas une action interdite.

Travail pratique : Préparez quatre tests : jeton absent, jeton d’un autre contexte, jeton correct sans permission, et parcours légitime complet.

Critères de correction : Vérifiez l’absence de mutation dans les trois refus. Testez depuis une seconde origine de laboratoire et incluez la politique SameSite réelle. Gardez une preuve des contrôles serveur au lieu de seulement observer la console.

Changement d’IBAN : protéger intention et autorisation

Un formulaire cross-site peut envoyer une demande application/x-www-form-urlencoded dans des conditions où le navigateur joint une identité ambiante. Le site hostile n’a pas besoin de lire la réponse pour que le changement d’IBAN produise un effet. SOP et CORS ne constituent donc pas une preuve d’intention légitime.

Vérifiez un token anti-CSRF lié au contexte prévu, ainsi que la provenance selon une politique stricte adaptée au parcours. Les cookies sécurisés et SameSite complètent cette défense, sans être assimilés à une autorisation générale. Une opération aussi sensible peut aussi demander une confirmation ou une réauthentification selon les exigences métier.

Le contrôle doit précéder l’écriture et tout appel externe. Testez token absent, incorrect et bon token sur l’objet d’un tiers : ce dernier cas exige encore un refus d’autorisation. Après chaque rejet, vérifiez que l’IBAN enregistré et les événements aval n’ont pas changé. Un statut d’erreur seul peut cacher une mutation trop tôt exécutée.

Points de vigilance : HttpOnly limite l’accès JavaScript au cookie, pas son envoi automatique. CORS n’empêche pas à lui seul l’envoi d’un formulaire cross-origin simple. Le jeton et les contrôles de provenance visent l’intention cross-site non autorisée ; ils complètent la défense. Connaître un identifiant ne prouve pas l’intention du titulaire de la session.