OAuth-i kontrollnimekiri RFC 9700 põhjal: MUST ja SHOULD

RFC 9700, mis avaldati 2025. aasta jaanuaris BCP 240 nime all, eristab OAuth 2.0 turvalisuse tugevdamise nõuetest need, mis on MUST, ja need, mis on vaid SHOULD. Identity provideri konsooli unustatud wildcard redirect URI on just selline seadistus, mille standard välistab, ja korrektne kliendikood seda ei korva. RFC uuendab dokumente RFC 6749, RFC 6750 ja RFC 6819 ning hoiatab, et selle järgimine võib rikkuda koostalitlusvõime vanemate ökosüsteemidega. Sellegipoolest soovitab see uuendada niipea kui võimalik.

Nõuded tugevuse järgi

Redirect URI-d: täpne vastavus ja open redirectorite puudumine

Kui autoriseerimisserver võrdleb päringu redirect_uri registreeritud väärtustega, peab ta kasutama täpset sõnede võrdlust. Ainus erand on natiivrakenduste localhost-suunamiste portnumber. Wildcardid, prefiksivasted ja registreeringud kujul "mistahes tee sellel hostil" ei vasta sellele reeglile.

Oluline on ka registreeritud nimekiri, sest iga kirje on lubatud sihtkoht authorization code'idele. Eemaldage aegunud kirjed, eriti hostid, mida te enam ei kontrolli, näiteks kasutuselt kõrvaldatud staging-domeen, mille võiks üle võtta keegi teine.

Open redirectorid on probleemi teine pool. Endpoint, mis suunab brauseri päringuparameetrist saadud suvalisele URI-le, võib lekitada authorization code'e ja access tokeneid ning RFC ütleb, et ei kliendid ega autoriseerimisserverid ei tohi sellist endpointi avalikustada. OWASP-i näide http://example.com/example.php?url=http://malicious.example.com näitab probleemi: kasutaja näeb usaldusväärset hosti ja ei märka suunamist.

Lahenduse annab OWASP-i spikker kontrollimata suunamiste kohta. Parim on URL-i vastuvõtmise asemel seostada serveris lühike ID sihtkohaga. Kui peate URL-i siiski vastu võtma, parsige see hooldatava parseriga ja võrrelge scheme'i, kanoonilist hosti ning efektiivset porti selgesõnalise allowlistiga. Lükake tagasi userinfo ja ärge kunagi võrrelge toorete prefiksite ega sufiksite järgi.

PKCE igal kliendil, avalikel kohustuslik

Avalikud kliendid peavad kasutama PKCE-d. Konfidentsiaalsetele klientidele on see soovitatav, sest see takistab ka code injectionit ja kõrvalmõjuna CSRF-i. Konfidentsiaalsed OpenID Connecti kliendid võivad kasutada selle asemel noncei ja vastavat ID Tokeni claimi, kuid ainult jaotises 4.5.3.2 kirjeldatud meetmetega. Soovitus kehtib ka veebirakendustele, kuigi PKCE loodi natiivrakenduste jaoks.

• Challenge'i väärtus peab iga tehingu puhul muutuma. Konstantne väärtus teeb kogu mehhanismi mõttetuks.
• Kasutage S256. RFC 9700 nimetab seda praegu ainsaks meetodiks, mis ei paljasta verifierit authorization requestis; ründaja, kes saab selle päringu lugeda, võib muidu PKCE-st mööda minna. RFC 7636 lisab, et plain leevendab ainult ründajat, kes näeb vaid vastuseid.
• Verifier on juhuslik 43 kuni 128 märgi pikkune sõne unreserved-märkide hulgast. RFC 7636 soovitab 32 juhuslikku oktetti, base64url-kodeeritult, mis annab 43 märki.

Server peab blokeerima ka downgrade'i: token request koos code_verifieriga aktsepteeritakse ainult siis, kui authorization request sisaldas code_challengeit. Kui avaldate serveri metaandmetes code_challenge_methods_supported, saavad kliendid tuvastada PKCE toe.

Implicit grant, CSRF ja mix-up

Kliendid ei tohiks kasutada response_type=tokenit ega ühtegi response type'i, mis tagastab access tokenid authorization response'is. RFC 9700 nimetab neid haavatavaks tokenite lekkele ja taasesitusele ning märgib, et nii väljastatud tokeni sender-constrainimiseks puudub standardiseeritud meetod. Kasutage codei või tüüpi, mis väljastab tokenid token endpointis, näiteks code id_token.

CSRF-i vastu redirection endpointil on vaja PKCE-d (kui klient on kinnitanud, et server seda toetab), OpenID Connecti vootes noncei või kasutaja user agentiga seotud ühekordset state väärtust. Kui teie klient suhtleb rohkem kui ühe autoriseerimisserveriga, kasutage RFC 9207 iss parameetrit või samaväärset iss väärtust, näiteks ID Tokeni claimi.

Tokenid: kasutage sender-constrainimist, kus võimalik

Autoriseerimis- ja ressursiserverid peaksid access tokeneid sender-constrainima mutual TLS-iga (RFC 8705) või DPoP-ga (RFC 9449), et varastatud token oleks ilma sobiva saladuseta kasutu. Avalike klientide refresh tokenid peavad olema sender-constrained või rotatsiooniga, nagu on kirjeldatud RFC jaotises 4.14.

Kust alustada

1. Koostage nimekiri kõigist iga kliendi registreeritud redirect URI-dest. Eemaldage wildcardid, osalised teed ja hostid, mida te enam ei kontrolli. Seejärel lisage töötavas authorization requestis tee lõppu midagi või muutke alamdomeeni; server peab päringu tagasi lükkama.
2. Otsige nii kliendist kui ka autoriseerimisserverist suunamisparameetreid nagu url, next või returnUrl. Asendage vabas vormis URL-id serveripoolse ID-seosega või parsitud URL-ide allowlistiga.
3. Otsige kliendikoodist ja serveri seadetest response_type=tokenit. Viige need kliendid üle authorization code flow'le koos PKCE-ga, mis kasutab S256.
4. Testige PKCE-d otse. Saatke authorization request ilma code_challengeita ja lunastage kood code_verifieriga. Seejärel lunastage PKCE-ga kaitstud kood ilma verifierita. Mõlemad peavad token endpointis ebaõnnestuma; token vastuses tähendab, et server ei läbinud testi.
5. Testige statei: esitage uuesti kasutatud väärtus ja seejärel teisest brauserisessioonist pärit väärtus; klient peab mõlemad tagasi lükkama. Kui teie provider tagastab issi, muutke seda ja veenduge, et klient lükkab vastuse tagasi. ID Tokeni claime saate kontrollida meie JWT tööriistaga ja kui soovite välist hinnangut, saab penetratsioonitest katta ka need vood.
6. Avalike klientide puhul valige sender-constrainimine või rotatsioon. Rotatsiooni korral esitage testis kasutatud refresh token kaks korda ja vaadake, mida server teeb. Leidke see katse autoriseerimisserveri logidest, kuna sündmuste nimed erinevad toodeti, ja seadistage selle peale alert.