Lyhyt OAuth-tietoturvakatsaus

Esittely#

Muutama päivä sitten tuli vastaan mielenkiintoinen OAuth-haavoittuvuusartikkeli. A-new-oauth-vulnerability-that-may-impact-hundreds-of-online-services SALT-laboratorion toimesta. Tämä erityinen julkaisu korostaa haavoittuvuutta, joka löydettiin Expo-ohjelmistosta, jota käytetään laajalti OAuth:n ja muiden toiminnallisuuksien toteuttamiseen. Se käsittelee erityisesti expo-auth-session -kirjaston haavoittuvuutta, joka on jo korjattu asianmukaisesti.

Jos olet kiinnostunut OAuth:sta tai työskentelet samanlaisen tuotteen parissa kuin me, suosittelemme lukemaan tämän artikkelin. Se on todella inspiroiva ja tarjoaa hyödyllisiä näkemyksiä. Nämä white-hat -raportit toimivat muistutuksena siitä, kuinka jopa yksinkertaisin ominaisuus voi aiheuttaa haavoittuvuuksia. Kyberturvallisuuden ja valtuutuksen kohdalla ei voi koskaan olla liian varovainen varmistaessaan käyttäjätietojen turvallisuuden ja yksityisyyden. Jos tämä artikkeli herättää mielenkiintosi, uskomme, että olet kanssamme vahvasti samaa mieltä.

Se muistuttaa minua ajasta, jolloin aloitimme ensimmäisen kerran. Käytimme paljon aikaa oppimiseen ja tutkimiseen OAuth ja OIDC-protokollien yksityiskohdista. Se oli kivuliasta ja tylsää, mutta hyöty oli valtava. Vaikka ehkä kaikki tiimimme jäsenet eivät ole OAuth-asiantuntijoita, kaikki ovat sitoutuneet jatkuvasti parantamaan turvallisuutta ja huolellisuutta. Näiden omistautuneiden ponnistelujen ansiosta Logto-tuote on kehittynyt siihen, mitä se on tänään.

Tämän hienon tilaisuuden ansiosta haluamme virkistää muistiamme OAuth:n turvallisuusasioista täällä.

Vilkaisu OAuth:n valtuutus- ja koodivirtaukseen#

OAuth 2.0 tarjoaa erilaisia valtuutusvirtoja eri asiakastyypeille ja -vaatimuksille. Näihin kuuluvat Implicit Flow, Client Credentials Flow, Resource Owner Password Credentials Flow ja Device Authorization Flow. Kuitenkin valtuutus- ja koodivirtaus erottuu turvallisimpana ja laajimmin käytettynä. Toisin kuin muut virtaukset, se erottaa käyttäjän todennuksen asiakassovelluksesta ja sisältää valtuutuskoodin vaihtamisen tunnuksiksi. Tämä lähestymistapa tarjoaa ylimääräisen suojauskerroksen, koska herkät tunnukset eivät ole koskaan kliin kaappauksen kohteena. Lisäksi valtuutus- ja koodivirtaus tukee palvelinpuolen token-hallintaa, mikä tekee siitä sopivan web-sovelluksiin, jotka vaativat vankkaa turvallisuutta ja parempaa käyttäjän pääsyn hallintaa.

Tässä on yksinkertaisin Authorization Code Flow -kaavio:

Tutkitaanpa kahta tärkeintä pyyntöä, jotka tehdään valtuutuskoodien myöntämisprosessissa, ja näennäisesti vähäpätöisiä osia niissä, mutta joissa on kriittinen tehtävä petosten torjumisessa.

Valtuutuksen päätepiste:

Tunnusten vaihto päätepiste:

Asiakaskunnistus#

OAuth:ssa Asiakaskunnistus viittaa valtuutukseen käytettäväksi asiakassovelluksessa, jotta sen avulla voidaan todennus- ja tunnistus palvelimen valtuutuspalvelimelle. Nämä valtuudet hankitaan asiakassovelluksen rekisteröintiprosessin aikana, ja niitä käytetään tunnistamaan asiakkaan oikeus tehdessään pyyntöjä valtuuspalvelimelle.(Logto tarjoaa sinulle asiakaskunnistuksesi hallintakonsolissaan, kun rekisteröit sovelluksesi ensimmäisen kerran.)

Asiakaskunnistus koostuu yleensä kahdesta osasta:

1. Asiakastunnus: Yksilöllinen tunniste, joka on valittu asiakassovellukselle valtuutuspalvelimen toimesta. Se on julkinen arvo, jota ei pidetä tyypillisesti arkaluontoisena.
2. Asiakassalaisuus: Luottamuksellinen ja turvallisesti säilytettävä arvo, joka on tiedossa ainoastaan asiakkaalle ja valtuutuspalvelimelle. Se toimii eräänlaisena todennuksena asiakassovellukselle ja käytetään varmistaakseen asiakkaan tunnistautuminen tehdessään pyyntöjä valtuutuspalvelimelle.

Kuten voitte huomata, Asiakastunnus ja Asiakassalaisuuden yhdistäminen käytetään tokenpyynnössä asiakastunnistuksen vahvistamiseksi ja pääsyn tunnusten saamiseksi.

Asiakaskunnistus on tärkeässä asemassa OAuth-virtauksen turvallisuuden varmistamisessa. Ne auttavat valtuutuspalvelinta varmistamaan asiakassovellusten aitouden ja hallitsemaan suojattujen resurssien pääsyä. On tärkeää käsitellä asiakaskunnistuksia turvallisesti ja suojella niitä luvattomalta käytöltä. Logto kategorisoi asiakassovellukset kahteen eri turvallisuustasoon:

• Luottamukselliset asiakkaat: Näitä ovat palvelinrendi-perustaiset verkkosovellukset ja koneista-koneisiin (M2M) sovellukset. Luottamuksellisten asiakkaiden tapauksessa kaikki valtuutukseen liittyvät tunnukset, mukaan lukien asiakastunnukset, ovat turvallisesti säilytetty palvelinpuolella. Lisäksi kaikki välivaihtopyynnöt ovat salattuja, jotta tiedon luottamuksellisuus säilyy. Luottamuksellisten asiakkaiden asiakaskunnistusten vuotoriski on äärimmäisen alhainen, mikä tekee niistä luonnostaan turvallisempia. Siksi luottamuksellisia asiakkaita käsitellään oletuksena korkeammalla turvallisuustasolla. Tokenpyynnössä Asiakassalaisuuden esittäminen on PAKOLLISTA.
• Julkiset asiakkaat: Näitä ovat yksisivuiset verkkosovellukset (SPA) ja alkuperäiset sovellukset. Julkisille asiakkaille asiakaskunnistukset on tyypillisesti koodattu asiakaspuolelle, kuten JavaScript-paketissa tai sovellettuna pakettina alkuperäisessä alustassa. Asiakassalaisuuksien vuotoriski on suurempi verrattuna luottamuksellisiin asiakkaisiin asiakkaalle ominaisten asiakaspuoleseen koodia koskevien asiakassalaisuuksien altistumisen vuoksi. Tokenpyynnössä Asiakassalaisuuden esittäminen on VAPAAEHTOISTA. Logto ei oletuksena luota julkisten asiakkaiden tunnuksiin.

Tila#

OAuth-virtauksessa tila (state) parametri on satunnaisesti luotu arvo, joka sisältyy valtuutuspyyntöön, jonka asiakas lähettää valtuutuspalvelimelle. Sen tarkoitus on ylläpitää asiakkaan pyynnön tila tai konteksti koko valtuutusprosessin ajan.

Tila parametri toimii turvallisuustoimenpiteenä estääkseen sivujen sisäinen tekopyyntöhämäys (CSRF) hyökkäykset. Kun valtuutuspalvelin uudelleensuuntaa käyttäjän takaisin asiakassovellukseen todennuksen ja valtuutuksen jälkeen, se liittää saman tilan arvon vastaukseen. Asiakassovelluksen tulee verrata tätä arvoa alkuperäiseen tila arvoon, jonka se lähetti valtuutuspyynnössä.

Tarkistamalla tilan parametri, asiakas voi varmistaa, että valtuutuspalvelimelta saatu vastaus vastaa alkuperäistä pyyntöä, jonka se teki. Tämä auttaa estämään hyökkäyksiä, joissa hyökkääjä yrittää huijata asiakasta hyväksymään vastauksen, joka on tarkoitettu toiselle käyttäjälle tai sovellukselle.

Tässä on esimerkki CSRF-hyökkäyksestä fiktiivisessä käyttötapauksessa:

CSRF-hyökkäys: Sosiaalitilin sitominen - ongelma

Oikean tilan varmennusmekanismin avulla asiakas pystyy havaitsemaan hyökkäyksen ja estämään käyttäjää ohjaamasta hyökkääjän sivustolle:

CSRF-hyökkäys: Sosiaalitilin sitominen - ratkaisu

PKCE#

Kuten aikaisemmin mainittiin, julkisilla asiakkailla, kuten SPA-verkkosovelluksilla ja alkuperäisillä sovelluksilla, on suurempi riski valtuutuksen tunnistevuodosta, mukaan lukien valtuutuspalvelimen myöntämä valtuutuskoodi.

PKCE tarkoittaa todisteavain koodin vaihtamista varten (Proof Key for Code Exchange). Se on OAuth 2.0 -protokollan valtuutuskoodivirtausta laajennus, joka parantaa julkisten asiakkaiden turvallisuutta.

PKCE otettiin käyttöön lieventämään hyökkäyksen riskiä, jossa hyökkääjä sieppaa valtuutuskoodin ja vaihtaa sen access_token:iksi ilman asiakkaan tietämystä. Tämän tyyppinen hyökkäys, joka tunnetaan valtuutuskoodin sieppauksen hyökkäyksenä, on yleisempää ympäristöissä, joissa asiakassovellus ei voi turvallisesti säilöä asiakassalaisuutta.

Palautaaksesi PKCE:n, asiakassovellus luo satunnainen koodin tarkistuslaskin (Code Verifier) ja johtaa siitä koodihaasteen (Code Challenge) käyttämällä tiettyä hajautusalgoritmia (tyypillisesti SHA-256). Koodihaaste sisältyy alkuperäiseen valtuuspyyntöön, joka lähetetään valtuutuspalvelimelle.

Kun valtuutuspalvelin myöntää valtuutuskoodin, asiakassovellus sisällyttää alkuperäisen koodin tarkistuksen tunnuksen vaihdossa. Palvelin varmistaa, että koodin tarkistus täsmää tallennetun koodihaasteen kanssa ja vasta sitten myöntää access_token:in.

PKCE:n avulla asiakassovellus varmistaa, että pelkkä valtuutuskoodi ei riitä saamaan access_token:ia. Tämä mekanismi lisää ylimääräisen suojauskerroksen valtuutusvirtaukseen, erityisesti julkisille asiakkaille, joissa asiakassalaisuuksien säilyttäminen on haastavaa.

Logto käyttää PKCE:ta AINOANA valtuutusvirtauksena kaikille julkisen asiakastyypin sovelluksille. PKCE voidaan kuitenkin jättää pois luottamuksellisten asiakkaiden kohdalla.

Uudelleenohjaus URI#

Uudelleenohjaus URI (Uniform Resource Identifier) on erityinen päätepiste tai URL-osoite, johon valtuutuspalvelin uudelleenohjaa käyttäjän todennuksen ja valtuutusprosessin jälkeen OAuth:ssa.

OAuth-virtauksen aikana asiakassovellus sisällyttää uudelleenohjaus URI:n osana alkuperäistä valtuutuspyyntöä. Tämä URI toimii palautus-URL:na, johon käyttäjä ohjataan takaisin onnistuneen todennuksen ja asiakassovellukselle annettujen oikeuksien jälkeen.

Kun käyttäjä suorittaa todennusprosessin, valtuutuspalvelin tuottaa vastauksen, joka sisältää valtuutuskoodin, ja ohjaa käyttäjän takaisin määritettyyn uudelleenohjaus URI:iin.

Uudelleenohjaus URI:n validointi on olennainen askel OAuth-virtauksen turvallisuuden ja eheyden varmistamisessa. Se sisältää varmistuksen siitä, että valtuutuspyynnössä ja sitä seuraavissa ohjauksissa käytetty uudelleenohjaus URI on voimassa ja luotettava.

Palataan alkuperäiseen OAuth-haavoittuvuusraporttiin. (Seuraava osio on lainattu alkuperäisestä julkaisusta)

Kun käyttäjä klikkaa “kirjaudu Facebookilla” Expo Go -sovelluksessa, se ohjaa käyttäjän seuraavaan linkkiin:

https://auth.expo.io/@moreisless3/me321/start?authUrl=https://www.facebook.com/v6.0/dialog/oauth?code_challenge=...&display=popup&auth_nonce=...&code_challenge_method=S256&redirect_uri=https://auth.expo.io/@moreisless3/me321&client_id=3287341734837076&response_type=code,token&state=gBpzi0quEg&scope=public_profile,email&returnUrl=exp://192.168.14.41:19000/--/expo-auth-session

Vastauksessa auth.expo.io asettaa seuraavan evästeen: ru=exp://192.168.14.41:19000/--/expo-auth-session. Arvo RU käytetään myöhemmin paluu-URL:na vaiheessa 5. Se näyttää sitten käyttäjälle vahvistusviestin, ja jos käyttäjä hyväksyy - se ohjaa hänet Facebook-kirjautumiseenj jatkaaksesi todennusta

...

Tämä sivu lukee kyselyparametrin “returnUrl” ja asettaa evästeen vastaavasti.

Muuttakaa returnUrl hTTps://attacker.com (https ei ole sallittua, joten yritin kirjoittaa isoja kirjaimia ja se toimi), mikä asettaa RU:n (Return Url) evästeeseen https://attacker.com.

...

Yllä olevassa tapauksessa vältettäessä alkuperäisiä redirect_uri -parametrejä, Expo esitteli uuden muuttujan nimeltä returnUrl ilman kunnollista validointia. Tämä laiminlyönti tarjosi hyökkääjille mahdollisuuden saada pääsy Facebookin palauttamaan valtuutuskoodiin. Lisätietoja löytyy alkuperäisestä julkaisusta.

Redirect URI:n validointi toimii useilla tärkeillä tavoilla:

1. Kalasteluvastausten estäminen: Varmistamalla Redirect URI:n avulla valtuutuspalvelin varmistaa, että käyttäjä uudelleenohjataan takaisin luotettuun ja valtuutettuun päätepisteeseen. Tämä auttaa estämään hyökkääjiä uudelleenohjaamasta käyttäjiä haitallisille tai valtuuttamattomille paikoille.
2. Avoimen uudelleenohjausten suojelu: Avoimet uudelleenohjauset ovat haavoittuvuuksia, joita voidaan käyttää käyttäjien uudelleenohjaamiseen haitallisille verkkosivuille. Vahvistamalla Redirect URI:n, valtuutuspalvelin voi varmistaa, että uudelleenohjaus pysyy valtuutettujen verkkotunnusten tai luotettujen verkkotunnusten rajoissa.
3. Valtuutusvastausten oikean reitityksen varmistaminen: Redirect URI:n validointi auttaa takaamaan, että valtuutuspalvelimelta annetut oikeudet suunnataan takaisin tarkoitetulle asiakassovellukselle. Se varmistaa, että vastaus, kuten valtuutuskoodi tai access_token, lähetetään oikeaan kohteeseen.

Logtossa redirect_uri -rekisteröinti on pakollista kaikille sovellustyypeille. Vertaamme ja vertaamme saamaasi arvoa niiden rekisteröityjen arvojen kanssa Logto-palvelimelta. Tämä koskee mitä tahansa mukautettua hakukyselyt. Jos valtuuspyyntö epäonnistuu validoinnissa puuttuvan, virheellisen tai epäsopivan redirect_uri -arvon vuoksi, palautetaan virheellinen Redirect URI -virhe rekisteröityyn redirect_uri:iin tiedostossa.

Yhteenveto#

Monimutkaisen ja hienovaraisen luonteensa vuoksi on ymmärrettävää, että näitä yksityiskohtia usein unohdetaan. Jotkut ovat vain satunnaisia merkkijonon kaltaisia tiloja.

On kuitenkin tärkeää huomata, että nämä turvallisuustoimenpiteet lisäävät kerroksia käyttäjän valtuutuksen suojaamiseen, lievittäen riskejä, kuten CSRF-hyökkäyksiä, valtuutuskoodin sieppauksia ja luvattomia uudelleenohjauksia.

Nämä ovat vain pieni osa laajoista turvallisuusominaisuuksista, joita OAuth-protokolla tarjoaa. OAuth tarjoaa vankan kehyksen turvalliseen todennukseen ja valtuutukseen. Se tarjoaa myös joustavia ja avoimia päättepisteitä vastaamaan erilaisia tarpeita reaaliaikaisissa tuotesovelluksissa.

Kehittäjät ja palveluntarjoajat, on ensiarvoisen tärkeää jatkuvasti asettaa etusijalle käyttäjän valtuutusvirtauksen turvallisuus. Varmuuden pitäminen, parhaiden käytäntöjen noudattaminen ja pysyminen ajan tasalla OAuth-ekosysteemin viimeisimmissä kehityksissä ovat välttämättömiä käyttäjän identiteettien ja arkaluontoisten tietojen eheyden ja suojelun varmistamiseksi. Olemme sitoutuneet jatkossakin noudattamaan korkeimpia turvallisuusstandardeja OAuth:n toteuttamisessa ja käyttäjiemme yksityisyyden ja luottamuksen suojaamisessa.