Profile data are retrieved from ID token without verifying the token
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Bug
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- objective-c
- Bereich
- authentication, mobile-dev, security
Rechercherichtung
Beginne bei GoogleSignIn/Sources/GIDSignIn.m ungefähr in Zeile 803 und vergleiche die aktuelle Behandlung von ID-token mit den verlinkten backend-auth-Richtlinien. Prüfe die PKCE-Referenz und bestimme das erwartete Integritäts- und Vertrauensmodell für mobile und Desktop-Clients. Als abgeschlossen gilt die Aufgabe erst, wenn ein Verifizierungsansatz vereinbart wurde, bevor der Implementierungsumfang festgelegt werden kann.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Describe the bug
Bug location: https://github.com/google/GoogleSignIn-iOS/blob/7932d33686c1dc4d7df7a919aae47361d1cdfda4/GoogleSignIn/Sources/GIDSignIn.m#L803
Here, profile data (email, name, profile picture, etc.) are being retrieved from the ID Token without verifying the integrity of the token. Ideally, an ID Token would be sent over to the backend server, which first verifies the signature of the token before using the profile information from the payload.
But, in this case, since we are directly retrieving the sensitive profile information (from ID Token's payload) to sign in a user, should we not verify the token first? Especially for mobile or desktop apps (which is the case here) where intermediary-free TLS cannot always be guaranteed?
Additionally, we are not using any CSRF protection (e.g, PKCE), so I think it is critical to verify the integrity of the ID Token before accepting the profile information from it.
- Vorherrschende Sprache
- Objective-C
- Sterne
- 756
- Forks
- 283
- Ø Merge
- 3 T. 1 Std.
- Gemergte PRs (30 T.)
- 2
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus google/GoogleSignIn-iOS
-
Revoke request uses GET instead of POSTEvtl. wieder frei Ein Pull Request dazu wurde ohne Merge geschlossen. Offenenhancement triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
google/GoogleSignIn-iOS#621 ·
-
enhancement triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
google/GoogleSignIn-iOS#620 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
google/GoogleSignIn-iOS#440 · 4 Kommentare · 2 Reaktionen ·
-
bug triage
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
google/GoogleSignIn-iOS#647 ·
-
enhancement triage
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
google/GoogleSignIn-iOS#611 ·
Alle Issues in google/GoogleSignIn-iOS
Ähnliche Issues
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
sparkle-project/Sparkle#2932 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Typo in installer: “addition protections” → “additional protections”Evtl. vergeben @Jah-yee hat das heute übernommen. Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 94/100
objective-see/BlockBlock#111 ·
-
s: need triage
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
Tencent-TDS/KuiklyUI#1786 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
DataDog/dd-sdk-ios#3293 ·
Maintainer antworten meist innerhalb von 3 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
callstackincubator/voltra#340 ·
Maintainer antworten meist innerhalb von 4 Tagen