OAuth-kwetsbaarheden en aanvalspatronen

OAuth-autorisatieservers moeten de parameter redirect_uri strikt valideren. Als de server validatie op basis van een prefix of jokertekens toestaat (bijvoorbeeld elke URL accepteert die begint met "https://app.example.com"), maakt een aanvaller een autorisatieverzoek dat doorstuurt naar "https://app.example.com.attacker.com/steal" of naar een open redirect op het legitieme domein, waardoor de autorisatiecode wordt gestolen.

Zonder CSRF-bescherming kan een aanvaller een OAuth-flow starten en de browser van een slachtoffer ertoe verleiden de autorisatie te voltooien. Het slachtoffer verleent zo onbedoeld autorisatie aan de client van de aanvaller. De parameter "state" (RFC 6749) voorkomt dit: de client genereert een willekeurige state, neemt die op in het verzoek en controleert of die overeenkomt in de callback. Bij een afwijking wordt de flow afgebroken.

Op mobiele platforms kunnen kwaadwillende apps hetzelfde aangepaste URI-schema registreren als een legitieme OAuth-client en autorisatiecodes onderscheppen die na gebruikersauthenticatie worden omgeleid. PKCE (RFC 7636) biedt volledige bescherming: de onderschepte code is onbruikbaar zonder de code verifier die alleen de legitieme app aan het begin van de flow heeft gegenereerd.

Wanneer een ID-token of toegangstoken in een URL-fragment of queryparameter staat, nemen volgende navigaties vanaf die pagina de URL op in de Referer-header. Daardoor kan het token uitlekken naar scripts voor analyse van derden of CDN-aanbieders. Gebruik altijd de autorisatiecodeflow met tokenaflevering via het backchannel om te voorkomen dat tokens in URL's verschijnen.

Wanneer een client meerdere OAuth-aanbieders ondersteunt, verleiden mix-upaanvallen de client ertoe een autorisatiecode die bij aanbieder A is verkregen naar het token-eindpunt van aanbieder B te sturen. De client moet de claim "iss" in ID-tokens valideren en de callback koppelen aan de specifieke aanbieder die de flow heeft gestart, met behulp van de state-parameter of JARM (JWT-Secured Authorization Response Mode).

Server-side request forgery (SSRF)-aanvallen richten zich op OAuth-implementaties die HTTP-verzoeken aan de serverzijde naar redirect_uri uitvoeren. Als de autorisatieserver redirect_uri ophaalt om die te verifiëren, levert een aanvaller een intern IP-adres aan (bijvoorbeeld http://169.254.169.254/latest/meta-data/) om metagegevens van een cloudinstantie of interne diensten te benaderen. Strikte validatie van redirect_uri op basis van een toelatingslijst voorkomt dit.

Veel applicaties gebruiken de e-mailclaim uit een OIDC-ID-token om accounts bij verschillende aanbieders aan elkaar te koppelen. Als een aanvaller een e-mailadres beheert dat overeenkomt met het account van een slachtoffer bij een andere aanbieder, kan die zich bij een andere aanbieder registreren met dat e-mailadres en toegang krijgen tot het account van het slachtoffer. Bescherming: koppel accounts uitsluitend op basis van het paar (iss, sub), nooit alleen op basis van e-mail.

JWT-algoritmeverwarringsaanvallen maken misbruik van implementaties die de header "alg" vertrouwen om het verificatiealgoritme te selecteren. Aanval: wijzig "alg" van "RS256" in "HS256" en onderteken het token met de openbare sleutel van de server als HMAC-geheim (de openbare sleutel is immers openbaar). Bescherming: geef in de verificatiecode altijd het verwachte algoritme expliciet op en vertrouw nooit op de alg-claim in de tokenheader.

Aanvallers registreren kwaadwillende OAuth-clients met geloofwaardig ogende namen en logo's en sturen vervolgens phishinglinks naar doelwitten. Het slachtoffer ziet een echt OAuth-toestemmingsscherm (gehost door Google, Microsoft enzovoort) voor een kwaadwillende applicatie en verleent toegang. Bescherming: controleer of client_id bij de verwachte applicatie hoort; Google en Microsoft bieden programma's voor clientverificatie voor legitieme apps.

Escalatie van machtigingsbereik treedt op wanneer een client tokens verkrijgt met ruimere machtigingen dan de gebruiker heeft geautoriseerd. Implementatiefouten waarbij validatie van het machtigingsbereik op het token-eindpunt wordt overgeslagen, tokens met samengevoegde machtigingsbereiken uit verschillende verzoeken worden gecachet of niet wordt gecontroleerd of het machtigingsbereik in het uitgegeven token het geautoriseerde bereik niet overschrijdt, kunnen allemaal leiden tot escalatie van bevoegdheden via OAuth.

Bescherm OAuth-implementaties door: validatie van redirect_uri op basis van exacte overeenkomst te gebruiken, PKCE voor alle openbare clients te vereisen, de state-parameter te valideren voor CSRF-bescherming, ID-tokens te koppelen op basis van (iss, sub) en niet van e-mail, verwachte JWT-algoritmen expliciet op te geven, minimale machtigingsbereiken aan te vragen, kortlevende toegangstokens met rotatie van refresh tokens te gebruiken en het uiterlijk van toestemmingsschermen te controleren op risico's van merkimitatie.

Belangrijke OAuth-aanvallen: een open redirect door lakse validatie van redirect_uri (gebruik een exacte overeenkomst), CSRF door een ontbrekende state-parameter, onderschepping van codes op mobiele apparaten (beperkt door PKCE), het lekken van tokens in URL's, mix-up in omgevingen met meerdere aanbieders (valideer iss), SSRF via een door de server opgehaalde redirect_uri, botsing van e-mailclaims (gebruik iss+sub) en verwarring over JWT-algoritmen (leg het verwachte alg vast), plus phishing via vervalste toestemmingsschermen.