En banque, le détournement de session pose une question que le secteur a déjà tranchée en théorie : authentifier une connexion ne suffit pas à autoriser une opération. La DSP2 l'a inscrit dans le droit avec le lien dynamique. Le vol de session est précisément l'attaque qui exploite l'écart entre ce principe et sa mise en œuvre réelle, côté client comme côté collaborateur.
Deux périmètres, deux profils de risque
Côté client. Un jeton volé sur le poste d'un particulier ou d'une entreprise donne accès à l'espace bancaire : consultation des soldes, historique, bénéficiaires enregistrés, plafonds. Si un virement vers un bénéficiaire déjà enregistré ne demande pas de nouvelle validation, le préjudice est immédiat. Sinon, l'attaquant dispose du renseignement nécessaire pour une fraude au faux conseiller parfaitement calibrée.
Côté collaborateur. C'est le périmètre le plus lourd de conséquences et le moins souvent modélisé. Une session détournée sur un poste de back-office, de middle-office ou d'agence donne accès à des outils qui manipulent des flux, des habilitations ou des paramètres de contrôle. La fraude n'a alors plus besoin de franchir l'authentification forte du client : elle opère à l'intérieur.
Comment le jeton est obtenu, en environnement bancaire
| Vecteur | Cible privilégiée | Signal exploitable |
|---|---|---|
| Relais d'authentification (AiTM) | Espace client, portail collaborateur distant | Contexte d'usage différent du contexte d'émission |
| Dérobeur d'informations sur poste client | Particuliers, TPE-PME | Session bancaire depuis une origine d'hébergement |
| Extension de navigateur | Postes non maîtrisés, professionnels indépendants | Comportement de navigation automatisé |
| Poste de travail interne compromis | Back-office, agences | Horaires atypiques, actions hors périmètre du poste |
| Accès distant prestataire | Éditeurs, infogérants, TMA | Session longue, absence de réauthentification |
Le point commun avec les autres secteurs est technique ; la différence est la vitesse de monétisation. En banque, la fenêtre entre le vol du jeton et l'exploitation se compte en minutes.
Ce que la réglementation exige déjà, et ce qu'elle laisse ouvert
La directive DSP2 ((UE) 2015/2366) impose l'authentification forte du client — deux facteurs de catégories distinctes — et surtout le lien dynamique entre l'authentification, le montant et le bénéficiaire. Correctement appliqué, ce lien rend une session volée insuffisante pour émettre un virement vers un nouveau bénéficiaire : il faudrait produire une validation portant sur ce montant et ce bénéficiaire précis.
Deux zones restent ouvertes en pratique. Les exemptions légitimes, qui allègent le parcours dans certaines situations, et tout ce qui n'est pas un paiement : ajout de bénéficiaire, relèvement de plafond, changement de coordonnées de contact, souscription de service. Ces actions préparent la fraude, et sont parfois moins protégées que le virement lui-même.
Le règlement DORA ((UE) 2022/2554), applicable depuis janvier 2025, ajoute une exigence de résilience opérationnelle : gestion des risques liés aux tiers, notification des incidents majeurs, tests réalistes. Un scénario de détournement de session sur un accès prestataire relève exactement de ce cadre. À noter enfin que la DSP3 et le règlement sur les services de paiement demeurent en cours de processus législatif : ils ne créent pas d'obligation applicable aujourd'hui.
Parades : traiter la session comme un accès révocable
- Étendre le principe du lien dynamique au-delà du paiement. Ajout de bénéficiaire, hausse de plafond, modification de coordonnées : ces actes doivent exiger une validation contextualisée, distincte de la session. C'est la mesure qui prive le vol de session de sa rentabilité.
- Réauthentifier les opérations internes sensibles. Passage d'écriture, déblocage de compte, modification d'habilitation : la session d'un poste de back-office ne doit pas valoir autorisation permanente.
- Lier la session au poste lorsque la plateforme le permet, afin qu'un cookie copié ailleurs soit inutilisable.
- Réduire drastiquement la durée de vie des sessions sur les périmètres à fort impact, et tester la révocation, y compris sur les applications fédérées.
- Encadrer les accès prestataires : sessions nominatives, durée courte, ouverture à la demande, traçabilité complète. C'est aussi une attente explicite de DORA.
- Corréler authentification et usage. Une authentification réussie suivie d'un ajout de bénéficiaire puis d'un virement dans la même minute doit produire une alerte, même si chaque étape est individuellement conforme.
Ces mesures convergent vers une idée simple : la sécurité doit se rattacher à l'opération, pas à la porte d'entrée. C'est le principe de l'authentification cognitive, qui demande une preuve d'intention humaine au moment de l'acte, sans secret réutilisable, et qui peut se déployer en complément d'un dispositif existant.
FAQ
L'authentification forte DSP2 protège-t-elle du vol de session ?
Elle protège l'opération de paiement lorsqu'elle est correctement liée au montant et au bénéficiaire. Elle ne protège ni la consultation des données, ni les actions préparatoires, ni les opérations internes réalisées côté banque.
Comment détecter une session client détournée ?
Par la rupture de contexte : changement d'adresse ou d'empreinte de client au sein d'une session, géovélocité impossible, usage depuis une infrastructure d'hébergement, ou séquence d'actions inhabituelle par rapport au comportement historique du client.
Faut-il réduire la durée des sessions au risque de gêner les clients ?
La durée doit dépendre du périmètre. Une session de consultation peut rester confortable si toute action sensible exige une preuve fraîche. C'est le découplage consultation/action qui permet de ne pas dégrader l'expérience.
Un incident de vol de session est-il notifiable au titre de DORA ?
Selon sa qualification et son ampleur. Le point pratique est d'être capable de reconstituer rapidement la chronologie — émission du jeton, usage, opérations réalisées — car la notification suppose une caractérisation étayée dans des délais courts.
Aller plus loin : authentification cognitive : le pilier · vol de session : mécanismes et détection · DSP2 en banque · valider un virement avec un facteur cognitif