Sårbarheter i OAuth og angrepsmønstre

OAuth-autorisasjonsservere må validere parameteren redirect_uri strengt. Hvis serveren tillater prefiks- eller jokertegnsamsvar (for eksempel godtar en hvilken som helst URL som begynner med "https://app.example.com"), kan en angriper lage en autorisasjonsforespørsel som omdirigerer til "https://app.example.com.attacker.com/steal" eller til en åpen omdirigering på det legitime domenet, og stjele autorisasjonskoden.

Uten CSRF-beskyttelse kan en angriper starte en OAuth-flyt og lure offerets nettleser til å fullføre autorisasjonen. Offeret autoriserer dermed utilsiktet angriperens klient. Parameteren "state" (RFC 6749) forhindrer dette: Klienten genererer en tilfeldig state, inkluderer den i forespørselen og kontrollerer at den samsvarer i callbacken. Ved manglende samsvar avbrytes flyten.

På mobilplattformer kan ondsinnede apper registrere det samme egendefinerte URI-skjemaet som en legitim OAuth-klient og fange opp autorisasjonskoder som omdirigeres etter brukerautentisering. PKCE (RFC 7636) gir fullstendig beskyttelse: Den oppfangede koden er ubrukelig uten kodeverifikatoren som bare den legitime appen genererte i begynnelsen av flyten.

Når et ID-token eller access token er inkludert i et URL-fragment eller en spørringsparameter, inkluderer etterfølgende navigeringer fra siden URL-en i Referer-headeren. Dette kan lekke tokenet til tredjepartsskript for analyse eller CDN-leverandører. Bruk alltid authorization code flow med tokenlevering via back-channel for å unngå at tokener vises i URL-er.

Når en klient støtter flere OAuth-leverandører, kan mix-up-angrep lure klienten til å sende en autorisasjonskode som er hentet fra leverandør A, til token-endepunktet hos leverandør B. Klienten må validere "iss"-claimen i ID-tokener og knytte callbacken til den bestemte leverandøren som startet flyten, ved hjelp av state-parameteren eller JARM (JWT-Secured Authorization Response Mode).

Server-side request forgery (SSRF)-angrep retter seg mot OAuth-implementasjoner som utfører HTTP-forespørsler fra serveren til redirect_uri. Hvis autorisasjonsserveren henter redirect_uri for å kontrollere den, kan en angriper oppgi en intern IP-adresse (for eksempel http://169.254.169.254/latest/meta-data/) for å få tilgang til metadata for skyinstanser eller interne tjenester. Streng validering av redirect_uri basert på en eksplisitt tillatelsesliste forhindrer dette.

Mange applikasjoner bruker e-post-claimen fra et OIDC-ID-token til å koble kontoer på tvers av leverandører. Hvis en angriper kontrollerer en e-postadresse som samsvarer med offerets konto hos en annen leverandør, kan angriperen registrere seg hos en annen leverandør med denne e-postadressen og få tilgang til offerets konto. Beskyttelse: Koble kontoer bare ved hjelp av paret (iss, sub), aldri bare e-postadressen.

Angrep med forveksling av JWT-algoritmer utnytter implementasjoner som stoler på "alg"-headeren for å velge verifiseringsalgoritme. Angrepet utføres ved å endre "alg" fra "RS256" til "HS256" og signere tokenet med serverens offentlige nøkkel som HMAC-hemmelighet (siden den offentlige nøkkelen er offentlig). Beskyttelse: Angi alltid den forventede algoritmen eksplisitt i verifiseringskoden, og stol aldri på alg-claimen i token-headeren.

Angripere registrerer ondsinnede OAuth-klienter med navn og logoer som ser ekte ut, og sender deretter phishing-lenker til målpersoner. Offeret ser en ekte OAuth-samtykkeskjerm (fra Google, Microsoft eller lignende) for en ondsinnet applikasjon og gir den tilgang. Beskyttelse: Kontroller at client_id tilsvarer den forventede applikasjonen. Google og Microsoft tilbyr programmer for klientverifisering av legitime applikasjoner.

Scope-eskalering oppstår når en klient får tokener med bredere tillatelser enn det brukeren har godkjent. Implementasjonsfeil som hopper over scope-validering på token-endepunktet, mellomlagrer tokener med sammenslåtte scopes fra ulike forespørsler eller ikke kontrollerer at scopet i det utstedte tokenet ikke overskrider det godkjente scopet, kan føre til privilegieeskalering via OAuth.

Beskytt OAuth-implementasjoner ved å bruke nøyaktig samsvar ved validering av redirect_uri, kreve PKCE for alle offentlige klienter, validere state-parameteren for CSRF-beskyttelse, knytte ID-tokener til (iss, sub) og ikke e-post, angi forventede JWT-algoritmer eksplisitt, be om minst mulige scopes, bruke kortlivede access tokens med rotasjon av refresh tokens og kontrollere utformingen av samtykkeskjermer for å oppdage risiko for merkevareetterligning.

Viktige OAuth-angrep: åpen omdirigering via mangelfull validering av redirect_uri (bruk nøyaktig samsvar), CSRF på grunn av manglende state-parameter, oppfanging av koder på mobil (begrenses av PKCE), tokenlekkasje i URL-er, mix-up i oppsett med flere leverandører (valider iss), SSRF via serverhentet redirect_uri, kollisjon mellom e-post-claims (bruk iss+sub), forveksling av JWT-algoritmer (fastsett forventet alg) og phishing via falske samtykkeskjermer.