OAuth-sårbarheter och angreppsmönster

OAuth-auktoriseringsservrar måste validera parametern redirect_uri strikt. Om servern tillåter prefixmatchning eller jokerteckenmatchning (till exempel genom att acceptera alla URL:er som börjar med "https://app.example.com") kan en angripare skapa en auktoriseringsbegäran som omdirigerar till "https://app.example.com.attacker.com/steal" eller till en open redirect på den legitima domänen och på så sätt stjäla auktoriseringskoden.

Utan CSRF-skydd kan en angripare initiera ett OAuth-flöde och lura offrets webbläsare att slutföra auktoriseringen. Offret auktoriserar då angriparens klient utan att avse det. Parametern "state" (RFC 6749) förhindrar detta: klienten genererar ett slumpmässigt state, inkluderar det i begäran och verifierar att det matchar i callbacken. Vid en avvikelse avbryts flödet.

På mobila plattformar kan skadliga appar registrera samma anpassade URI-schema som en legitim OAuth-klient och fånga upp auktoriseringskoder som omdirigeras efter användarens autentisering. PKCE (RFC 7636) är det fullständiga försvaret: den uppfångade koden är oanvändbar utan den code verifier som endast den legitima appen genererade i början av flödet.

När en ID-token eller access token ingår i ett URL-fragment eller en frågeparameter innehåller efterföljande navigeringar från sidan URL:en i Referer-headern, vilket potentiellt kan läcka token till analyskript från tredje part eller CDN-leverantörer. Använd alltid auktoriseringskodflödet med tokenleverans via back channel för att undvika att tokens förekommer i URL:er.

När en klient stöder flera OAuth-providers kan mix-up-attacker lura klienten att skicka en auktoriseringskod som hämtats från Provider A till Provider B:s token-endpoint. Klienten måste validera claimen "iss" i ID-tokens och binda callbacken till den specifika providern som initierade flödet med hjälp av state-parametern eller JARM (JWT-Secured Authorization Response Mode).

Server-side request forgery (SSRF) riktar sig mot OAuth-implementationer som gör HTTP-anrop från servern till redirect_uri. Om auktoriseringsservern hämtar redirect_uri för att verifiera den kan en angripare ange en intern IP-adress (till exempel http://169.254.169.254/latest/meta-data/) för att komma åt metadata om molninstansen eller interna tjänster. Strikt validering av redirect_uri med en allowlist förhindrar detta.

Många applikationer använder email-claimen från en OIDC-ID-token för att koppla ihop konton mellan providers. Om en angripare kontrollerar en e-postadress som matchar offrets konto hos en annan provider kan angriparen registrera sig hos en annan provider med den adressen och få åtkomst till offrets konto. Försvar: koppla endast konton med paret (iss, sub), aldrig enbart med e-postadressen.

Attacker med JWT-algoritmförväxling utnyttjar implementationer som litar på headern "alg" för att välja verifieringsalgoritm. Attacken går ut på att ändra "alg" från "RS256" till "HS256" och signera token med serverns publika nyckel som HMAC-hemlighet (eftersom den publika nyckeln är offentlig). Försvar: ange alltid den förväntade algoritmen uttryckligen i verifieringskoden och lita aldrig på claimen alg i tokenheadern.

Angripare registrerar skadliga OAuth-klienter med namn och logotyper som ser legitima ut och skickar sedan nätfiskelänkar till sina mål. Offret ser en äkta OAuth-samtyckesskärm (som tillhandahålls av Google, Microsoft och andra) för en skadlig applikation och beviljar åtkomst. Försvar: verifiera att client_id motsvarar den förväntade applikationen. Google och Microsoft erbjuder klientverifieringsprogram för legitima appar.

Scope-eskalering inträffar när en klient får tokens med mer omfattande behörigheter än användaren har auktoriserat. Implementeringsfel som hoppar över scope-validering på token-endpointen, cachar tokens med sammanfogade scopes från olika begäranden eller inte validerar att scopet i den utfärdade token inte överskrider det auktoriserade scopet kan alla leda till behörighetseskalering via OAuth.

Skydda OAuth-implementationer genom att: använda validering av redirect_uri med exakt matchning, kräva PKCE för alla publika klienter, validera state-parametern som CSRF-skydd, binda ID-tokens med (iss, sub) och inte med e-postadress, uttryckligen ange de förväntade JWT-algoritmerna, begära minimala scopes, använda kortlivade access tokens med rotation av refresh tokens och granska samtyckesskärmens utformning med avseende på risken för varumärkesimitation.

Viktiga OAuth-attacker: open redirect genom bristfällig validering av redirect_uri (använd exakt matchning), CSRF på grund av en saknad state-parameter, auktoriseringskoder som fångas upp på mobila plattformar (motverkas av PKCE), tokenläckage i URL:er, mix-up-attacker i konfigurationer med flera providers (validera iss), SSRF genom serverhämtad redirect_uri, kollision mellan email-claims (använd iss+sub), JWT-algoritmförväxling (fastställ förväntad alg) och nätfiske via falska samtyckesskärmar.