Restreint local-sign-in derrière des tokens par fournisseur (DP-1855) - #1693
Restreint local-sign-in derrière des tokens par fournisseur (DP-1855)#1693jbfeldis wants to merge 2 commits into
Conversation
Protège l'endpoint local-sign-in contre les abus (incident DP-1848) sur les environnements où des tokens sont configurés dans les credentials (staging, sandbox) ; production inchangée (route absente), dev/test ouverts par défaut. - Tokens = dictionnaire nommé par fournisseur de données (`local_sign_in_tokens`), révocables individuellement ; n'importe quel token valide déverrouille. - Sans token valide : 404 (mimique la prod). Token validé en temps constant (secure_compare) puis mémorisé dans un cookie signé (30 j). - Journalise le fournisseur utilisé (+ email, IP) sur les envs protégés. - Panneau « Connexion rapide » masqué tant que l'environnement n'est pas déverrouillé. Logique de décision isolée dans LocalSignInPolicy (PORO testé unitairement) ; glue HTTP dans le concern LocalSignInProtection.
…ironnements sensibles (DP-1855)
6ac316c to
3140be2
Compare
|
(@JeSuisUnCaillou je t'ai request vu que JB m'avait demandé de repasser dessus imo il devait pensé que j'étais le seul sur le pont) |
JeSuisUnCaillou
left a comment
JeSuisUnCaillou
left a comment
There was a problem hiding this comment.
Il reste un problème selon moi : Toute personne local-signed-in en tant qu'admin peut aller retirer des droits à des FD qui ont des tokens pour l'API Datapass en staging sur leurs comptes nominatif.
Plus quelques commentaires 👇
| #### Protection par token (staging & sandbox) | ||
|
|
||
| Sur **staging** et **sandbox**, `local-sign-in` est protégé par un token secret (défense contre les abus, | ||
| cf. DP-1855). Il faut ajouter `&token=<secret>` à l’URL. Les tokens vivent dans les credentials chiffrées de |
There was a problem hiding this comment.
Pour faciliter l'utilisation par les partenaires, faudrait mettre un input pour renseigner le token dans l'UI, plutôt que leur faire faire une manip d'url. Ou une alert avec input, quoi.
There was a problem hiding this comment.
Je vois ton point mais pour moi l'idée c'est d'enlever la surface d'attaque donc pour moi ils mettent à la rigueur le lien en favori. Si on garde une page alors on garde le fait qu'un robot peut tenter d'entrer
There was a problem hiding this comment.
Je ne pense pas que cacher la feature aide à sécuriser quoi que ce soit. Le code est open source, un attaquant qui a envie de tenter plein de tokens peut la trouver facilement.
Ca rend juste la vie plus complexe pour les vrais utilisateurs.
There was a problem hiding this comment.
Limite vois avec Eva et Natalya ce qu'elles en pensent, c'est une réflexion produit et pas technique, à ce niveau là.
3 participants
Contexte
Réponse à l'incident DP-1848 (abus sur staging : créations en masse et tentatives
d'injection via le compte démo, entrées par
local-sign-in).Ce que fait la PR
local-sign-inest protégé par un token secret sur les environnements où des tokenssont configurés dans les credentials (staging + sandbox).
(
local_sign_in_tokens: { dgfip: …, api_entreprise: … }) : chaque FD a le sien,révocable individuellement. N'importe quel token valide déverrouille.
[local-sign-in] accès via le token « <fd> » — email=… ip=…), uniquement sur les environnements protégés — brique de traçabilitélégère (prépare DP-1857).
404(mimique la production, muet pour un scanner).?token=…, validé en temps constant (secure_compare), puis mémorisédans un cookie signé (30 j) : les accès suivants n'ont plus besoin du token.
tokens aux credentials de l'environnement.
Une seule règle hors-prod : la protection s'active dès qu'au moins un token existe dans les
credentials — aucun code à toucher pour couvrir un nouvel environnement ou ajouter un FD.
Implémentation
LocalSignInPolicy(PORO) : décision pure +matched_provider, testé unitairement.LocalSignInProtection(concern) : lecture params/cookie, pose du cookie, log,head :not_found.Tests
spec/services/local_sign_in_policy_spec.rb— matrice tokens × cookie +matched_provider+ cas prod.spec/requests/local_sign_in_spec.rb— bout-en-bout HTTP + aller-retour cookie + log FD + panneau masqué.