OAuth-sårbarheder og angrebsmønstre

OAuth-autorisationsservere skal validere redirect_uri-parametret strengt. Hvis serveren tillader præfiksmatchning eller jokertegnsmatchning (f.eks. at acceptere enhver URL, der begynder med "https://app.example.com"), kan en angriber udforme en autorisationsforespørgsel, der omdirigerer til "https://app.example.com.attacker.com/steal" eller til en åben omdirigering på det legitime domæne, og dermed stjæle autorisationskoden.

Uden CSRF-beskyttelse kan en angriber starte et OAuth-forløb og narre offerets browser til at fuldføre autorisationen. Offeret autoriserer utilsigtet angriberens klient. Parameteren "state" (RFC 6749) forhindrer dette: Klienten genererer en tilfældig state-værdi, inkluderer den i forespørgslen og kontrollerer, at den matcher i tilbagekaldet. Et uoverensstemmende svar afbryder forløbet.

På mobile platforme kan ondsindede apps registrere det samme brugerdefinerede URI-skema som en legitim OAuth-klient og opsnappe autorisationskoder, der omdirigeres efter brugerens autentificering. PKCE er det fuldstændige forsvar: Den opsnappede kode er ubrugelig uden kodeverifikatoren, som kun den legitime applikation genererede ved forløbets begyndelse.

Når et ID-token eller adgangstoken er inkluderet i et URL-fragment eller en forespørgselsparameter, inkluderer efterfølgende navigationer fra siden URL'en i Referer-headeren, hvilket potentielt lækker tokenet til tredjepartsanalyseskripter eller CDN-udbydere. Brug altid autorisationskodeflowet med tokenlevering via bagkanalen, så tokens ikke optræder i URL'er.

Når en klient understøtter flere OAuth-udbydere, narrer mix-up-angreb klienten til at sende en autorisationskode, der er hentet fra udbyder A, til udbyder B's tokenendepunkt. Klienten skal validere attributten "iss" i ID-tokens og knytte tilbagekaldet til den specifikke udbyder, der startede forløbet, ved hjælp af state-parametret eller JARM (JWT-Secured Authorization Response Mode).

Forfalskning af forespørgsler fra serveren (SSRF) rammer OAuth-implementeringer, der foretager serverbaserede HTTP-forespørgsler til redirect_uri. Hvis autorisationsserveren henter redirect_uri for at verificere den, kan en angriber angive en intern IP-adresse (f.eks. http://169.254.169.254/latest/meta-data/) for at få adgang til cloudinstansens metadata eller interne tjenester. Streng validering af redirect_uri baseret på en tilladelsesliste forhindrer dette.

Mange applikationer bruger e-mailattributten fra et OIDC-ID-token til at knytte konti sammen på tværs af udbydere. Hvis en angriber kontrollerer en e-mailadresse, der matcher offerets konto hos en anden udbyder, kan angriberen registrere sig hos en anden udbyder med den e-mailadresse og få adgang til offerets konto. Forsvar: Knyt kun konti sammen via parret (iss, sub), aldrig kun via e-mail.

JWT-algoritmeforvirring udnytter implementeringer, der stoler på "alg"-headeren til at vælge verificeringsalgoritmen. Angreb: Skift "alg" fra "RS256" til "HS256", og signer tokenet med serverens offentlige nøgle som HMAC-hemmelighed (fordi den offentlige nøgle er offentlig). Forsvar: Angiv altid den forventede algoritme eksplicit i verificeringskoden; stol aldrig på alg-attributten i tokenets header.

Angribere registrerer ondsindede OAuth-klienter med navne og logoer, der ser legitime ud, og sender derefter phishinglinks til mål. Offeret ser en ægte OAuth-samtykkeskærm (hostet af Google, Microsoft osv.) for en ondsindet applikation og giver adgang. Forsvar: Kontrollér, at client_id svarer til den forventede applikation. Google og Microsoft tilbyder klientverificeringsprogrammer til legitime apps.

Eskalering af omfang opstår, når en klient får tokens med bredere tilladelser, end brugeren autoriserede. Implementeringsfejl, der springer validering af omfang over på tokenendepunktet, cachelagrer tokens med sammenlagte omfang på tværs af forskellige forespørgsler eller undlader at kontrollere, at omfanget i det udstedte token ikke overskrider det autoriserede omfang, kan alle føre til rettighedseskalering via OAuth.

Forsvar OAuth-implementeringer ved at: bruge validering af redirect_uri med eksakt match, kræve PKCE for alle offentlige klienter, validere state-parametret som CSRF-beskyttelse, knytte ID-tokens via (iss, sub) og ikke via e-mail, angive forventede JWT-algoritmer eksplicit, anmode om minimale omfang, bruge kortlivede adgangstokens med rotation af fornyelsestokens og kontrollere samtykkeskærmens udseende for risiko for varemærkeefterligning.

Vigtige OAuth-angreb: åben omdirigering via lempelig validering af redirect_uri (brug eksakt match), CSRF via manglende state-parameter, opsnapning af kode på mobilen (afbødet af PKCE), tokenlækage i URL'er, mix-up i opsætninger med flere udbydere (valider iss), SSRF via serverhentet redirect_uri, sammenfald i e-mailattributter (brug iss+sub), JWT-algoritmeforvirring (fastsæt forventet alg) og phishing via falske samtykkeskærme.