OAuth-haavoittuvuudet ja hyökkäysmallit

OAuth-valtuutuspalvelinten on validoitava redirect_uri-parametri tiukasti. Jos palvelin sallii etuliitteeseen perustuvan tai jokerimerkkitäsmäytyksen (esim. hyväksyy minkä tahansa URL-osoitteen, joka alkaa merkkijonolla "https://app.example.com"), hyökkääjä voi muodostaa valtuutuspyynnön, joka uudelleenohjaa osoitteeseen "https://app.example.com.attacker.com/steal", tai käyttää oikean verkkotunnuksen avointa uudelleenohjausta ja varastaa valtuutuskoodin.

Ilman CSRF-suojausta hyökkääjä voi käynnistää OAuth-virran ja huijata uhrin selaimen suorittamaan valtuutuksen loppuun. Uhri valtuuttaa tietämättään hyökkääjän clientin. "state"-parametri (RFC 6749) estää tämän: clientti luo satunnaisen state-arvon, sisällyttää sen pyyntöön ja tarkistaa, että callbackissa vastaanotettu arvo vastaa sitä. Jos arvot eivät täsmää, virta keskeytetään.

Mobiilialustoilla haitalliset sovellukset voivat rekisteröidä saman mukautetun URI-skeeman kuin oikea OAuth-clientti ja siepata käyttäjän todennuksen jälkeen uudelleenohjattavat valtuutuskoodit. PKCE tarjoaa kattavan suojan: siepatusta koodista ei ole hyötyä ilman code verifieriä, jonka vain oikea sovellus loi virran alussa.

Kun ID-token tai access token sisällytetään URL-fragmenttiin tai kyselyparametriin, kyseiseltä sivulta tehdyt myöhemmät siirtymät sisältävät URL-osoitteen Referer-otsakkeessa, mikä saattaa vuotaa tokenin kolmannen osapuolen analytiikkaskripteille tai CDN-palveluntarjoajille. On aina käytettävä valtuutuskoodivirtaa, jossa tokenit toimitetaan back-channelin kautta, jotta tokeneita ei näy URL-osoitteissa.

Kun clientti tukee useita OAuth-palveluntarjoajia, mix-up-hyökkäyksissä clientti huijataan lähettämään Provider A:lta saatu valtuutuskoodi Provider B:n token-päätepisteeseen. Clientin on tarkistettava ID-tokenien "iss"-claim ja sidottava callback tiettyyn palveluntarjoajaan, joka käynnisti virran, käyttämällä state-parametria tai JARM:ia (JWT-Secured Authorization Response Mode).

Server-side request forgery (SSRF) -hyökkäykset kohdistuvat OAuth-toteutuksiin, jotka tekevät palvelinpuolen HTTP-pyyntöjä redirect_uri-osoitteeseen. Jos valtuutuspalvelin hakee redirect_uri-osoitteen sen tarkistamiseksi, hyökkääjä voi antaa sisäisen IP-osoitteen (esim. http://169.254.169.254/latest/meta-data/) päästäkseen käsiksi pilvi-instanssin metatietoihin tai sisäisiin palveluihin. Tiukka sallittujen osoitteiden luetteloon perustuva redirect_uri-validointi estää tämän.

Monet sovellukset käyttävät OIDC:n ID-tokenin email-claimia tilien linkittämiseen palveluntarjoajien välillä. Jos hyökkääjä hallitsee sähköpostiosoitetta, joka vastaa uhrin toisen palveluntarjoajan tiliä, hän voi rekisteröityä eri palveluntarjoajalle samalla osoitteella ja saada pääsyn uhrin tiliin. Suojaus: tilit on linkitettävä ainoastaan (iss, sub)-parin perusteella, ei koskaan pelkän sähköpostiosoitteen perusteella.

JWT-algoritmien sekoitushyökkäykset hyödyntävät toteutuksia, jotka luottavat "alg"-otsakkeeseen valitessaan tarkistusalgoritmin. Hyökkäys: "alg" muutetaan arvosta "RS256" arvoon "HS256", ja token allekirjoitetaan palvelimen julkisella avaimella HMAC-salaisuutena (koska julkinen avain on julkinen). Suojaus: odotettu algoritmi on aina määritettävä nimenomaisesti tarkistuskoodissa; tokenin otsakkeen alg-claimiin ei saa koskaan luottaa.

Hyökkääjät rekisteröivät haitallisia OAuth-clientteja, joilla on uskottavalta vaikuttavat nimet ja logot, ja lähettävät sitten kohteille tietojenkalastelulinkkejä. Uhri näkee aidon OAuth-suostumusnäytön (Googlen, Microsoftin jne. isännöimänä) haitalliselle sovellukselle ja myöntää sille käyttöoikeudet. Suojauksena on varmistettava, että client_id vastaa odotettua sovellusta; Google ja Microsoft tarjoavat aidoille sovelluksille clientin varmennusohjelmia.

Scope-oikeuksien laajentuminen tapahtuu, kun clientti saa tokenit laajemmilla käyttöoikeuksilla kuin mitä käyttäjä valtuutti. Toteutusvirheet, joissa token-päätepisteen scope-validointi ohitetaan, eri pyyntöjen scopet yhdistetään tokenien välimuistissa tai ei tarkisteta, etteivät myönnetyn tokenin scopet ylitä valtuutettuja scopeja, voivat kaikki johtaa OAuthin kautta tapahtuvaan käyttöoikeuksien laajentamiseen.

OAuth-toteutuksia suojataan validoimalla redirect_uri täsmällisesti, edellyttämällä PKCE:tä kaikilta julkisilta clienteilta, validoimalla state-parametri CSRF-suojausta varten, sitomalla ID-tokenit (iss, sub)-pariin eikä sähköpostiin, määrittämällä odotetut JWT-algoritmit nimenomaisesti, pyytämällä vain vähimmäisscopeja, käyttämällä lyhytikäisiä access tokeneita refresh tokenien rotaation kanssa sekä tarkastamalla suostumusnäytön ulkoasu brändin jäljittelyn riskin varalta.

OAuthin keskeisiä hyökkäyksiä ovat: väljästä redirect_uri-validoinnista johtuva open redirect (on käytettävä täsmällistä vastaavuutta), puuttuvasta state-parametrista johtuva CSRF, mobiililaitteilla tapahtuva koodin sieppaus (PKCE lieventää sitä), tokenien vuotaminen URL-osoitteissa, usean palveluntarjoajan kokoonpanojen mix-up (iss on validoitava), palvelimen hakemasta redirect_uri-osoitteesta johtuva SSRF, sähköposti-claimin yhteentörmäys (on käytettävä iss+sub-yhdistelmää), JWT-algoritmien sekoittaminen (odotettu alg on määritettävä) sekä tietojenkalastelu väärennettyjen suostumusnäyttöjen avulla.