Auth0 does not validate email addresses for non-social logins; VCell never checks the email_verified claim
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- Mezza giornata
- Idoneità per principianti
- 68/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- java
- Ambito
- authentication, security
Direzione di ricerca
Start at vcell-rest/src/main/java/org/vcell/restq/handlers/UsersResource.java around lines 197-203, where the JWT email claim is read and passed to UserRestService.createUserIdentity. Trace how the email flows into UserRestService.java:188 and how requestRecoveryEmail (UsersResource.java:98-148) consumes userInfo.email, then add an email_verified check before registration writes the address. Done looks like: registration rejects or restricts unverified claims, existing behavior is covered by the project's REST tests, and the Auth0 tenant configuration gap (item 1) is documented as an ops task outside the repo.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
For non-social logins (the Auth0 Username-Password-Authentication database connection), email addresses are never validated. A user can register with an email address they do not control, and VCell will accept it and store it as the account's contact address.
Social logins (Google, etc.) are not affected in the same way, because the upstream identity provider has already verified the address before issuing the claim.
Two separate gaps
1. Auth0 tenant configuration — the database connection does not require email verification, so no verification email is sent and an unverified account is fully usable.
2. VCell does not check the email_verified claim — even if Auth0 did mark the address unverified, VCell would not notice. email_verified does not appear anywhere in this repository:
$ grep -rn "email_verified\|emailVerified" --include="*.java" --include="*.ts" --include="*.properties" .
(no matches)
The email claim is taken from the JWT and written straight into the new user's record, with no verification check:
vcell-rest/src/main/java/org/vcell/restq/handlers/UsersResource.java:197—String email = jwt.getClaim("email");vcell-rest/src/main/java/org/vcell/restq/handlers/UsersResource.java:203—userRestService.createUserIdentity(subject, issuer, email, name, userRegistrationInfo);vcell-rest/src/main/java/org/vcell/restq/services/UserRestService.java:188—newUserInfo.email = email;
Why it matters
The stored email is not cosmetic — it is used as an account-recovery channel. requestRecoveryEmail (UsersResource.java:98-148) matches a supplied address against userInfo.email and, on a match, mails a magic link that links an Auth0 identity to a legacy VCell account. An unverified address in that field weakens the recovery path, and it also means support/notification mail can be directed at an address the account holder never proved they own.
Suggested fix
- Turn on email verification for the Auth0 database connection (tenant config).
- Reject or restrict registration in
UsersResourcewhen the JWT'semail_verifiedclaim is absent or false, rather than trustingemailunconditionally. - Decide what to do about existing accounts created with unverified addresses.
Notes
Gap 2 is confirmed by inspection of this repository. Gap 1 is as reported and should be confirmed against the live Auth0 tenant settings.
- Lingua principale
- Java
- Stelle
- 140
- Fork
- 35
- Merge medio
- 17h 39m
- PR unite (30g)
- 19
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di virtualcell/vcell
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
virtualcell/vcell#2193 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Accessibility Requirement Java-based User Interface
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
virtualcell/vcell#2138 ·
I maintainer di solito rispondono entro 1 giorno
-
Accessibility Requirement Java-based
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
virtualcell/vcell#2137 ·
I maintainer di solito rispondono entro 1 giorno
-
Accessibility Requirement User Interface
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
virtualcell/vcell#2135 ·
I maintainer di solito rispondono entro 1 giorno
-
Accessibility Requirement Java-based User Interface
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
virtualcell/vcell#2134 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di virtualcell/vcell
Issue simili
-
Mend: dependency security vulnerability
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
needs-area-label
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 2 giorni
-
critical
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement Java macOS
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
freerouting/freerouting#1079 ·
I maintainer di solito rispondono entro 4 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno