Zaledje za čelni del oziroma BFF je upravičeno, kadar umik žetonov OAuth iz dosega JavaScripta v brskalniku zagotovi dovolj zaščite, da upraviči upravljanje zaledja in posredovanje prometa API. Odločitev je odvisna od posledic kraje žetonov, zahtev po neposrednih klicih API, izvedljivosti posredovanja in stroškov delovanja. Tok avtorizacijske kode s PKCE je ločena protokolarna odločitev: uporablja ga tudi BFF.
RFC 10017, objavljen avgusta 2026, določa najboljšo trenutno prakso IETF za aplikacije OAuth v brskalniku. Primerja tri arhitekture z različnimi mejami izpostavljenosti žetonov. Najprej določite te meje, nato preverite zaščito protokola in sej.
Izberite, kje je mogoče uporabljati žetone
| Arhitektura | Vrednosti, dostopne JavaScriptu aplikacije | Seja, ki jo upravlja brskalnik | Glavno preostalo tveganje |
|---|---|---|---|
| BFF | Brez žetonov OAuth | Piškotek HttpOnly, ki ga JavaScript ne more prebrati |
Vstavljena koda lahko še vedno pošilja avtenticirane zahteve prek BFF |
| Zaledje, ki posreduje žetone | Dostopni žetoni; osvežitveni žetoni ostanejo pod nadzorom zaledja | Piškotek HttpOnly za sejo z zaledjem |
Vstavljena koda lahko ukrade dostopne žetone ali jih zahteva od zaledja |
| Brskalniški odjemalec OAuth | Dostopni in, če so izdani, osvežitveni žetoni; neposredna berljivost je odvisna od izolacije shrambe | Ta vzorec sam po sebi ne vključuje piškotka za sejo z zaledjem | Zlonamerna koda lahko zlorabi odjemalca in pridobi žetone |
Razlike izhajajo iz RFC 10017 §6. Piškotek HttpOnly shrani in pošilja brskalnik, njegova vrednost pa JavaScriptu ni dostopna.
BFF deluje kot zaupni odjemalec OAuth, upravlja žetone prek seje s piškotkom in dodaja dostopne žetone zahtevam, ki jih posreduje strežnikom virov. Za primer BFF v tem članku je izbrano strežniško shranjevanje sej in žetonov. To je izvedbena odločitev, ne definicija BFF: RFC dopušča tudi shranjevanje seje v piškotku na strani odjemalca in priporoča šifriranje vsebine piškotka, kadar vsebuje dostopne žetone. RFC 10017 §6.1.2.3, §6.1.3.2
RFC 10017 močno priporoča BFF za poslovne aplikacije, občutljive aplikacije in aplikacije, ki obdelujejo osebne podatke. Pri presoji tega priporočila odgovorite na štiri praktična vprašanja:
- Do katerih podatkov in dejanj bi ukraden žeton omogočil dostop ter kako dolgo?
- Ali mora brskalnik neposredno klicati strežnik virov?
- Ali lahko zaledje varno posreduje zahtevani promet?
- Ali lahko ekipa zanesljivo upravlja posredniško in sejno infrastrukturo?
Sama izvedljivost posredovanja ne upraviči izbire arhitekture. Pove le, da je BFF mogoč; zmanjšanje izpostavljenosti in zahteve za delovanje določajo, ali je tudi primeren. Zaledje, ki posreduje žetone, obravnavajte kot možnost šele, kadar primeri uporabe ali sistemske zahteve preprečujejo uporabo polnega BFF. RFC 10017 §6.1.4.3, §6.2.4.4
Predstavljajte si portal za zaposlene, ki prek majhnega nabora API-jev ureja podatke strank. Če ekipa že upravlja zaledje in neposredni klici niso zahtevani, je BFF utemeljena izbira. Če mora obvezna integracija v brskalniku neposredno klicati strežnik virov, je lahko izvedljiv kompromis zaledje, ki posreduje žetone, ob izrecnem sprejetju izpostavljenosti dostopnih žetonov. Odjemalec, ki deluje samo v brskalniku, zahteva posebej dokumentirano odločitev o tveganju; opustitev upravljanja zaledja ne zmanjša posledic zlonamerne kode v brskalniku.
Preverite preusmeritve in zaščito povratnega klica
Za obravnavane zasnove uporabite tok avtorizacijske kode s PKCE kot izhodišče. Javni odjemalci v brskalniku morajo uporabljati PKCE, njihov avtorizacijski strežnik pa mora njegovo uporabo uveljavljati. RFC 9700 priporoča PKCE tudi za zaupne odjemalce. Uporabite S256, da v avtorizacijski zahtevi ne razkrijete preveritvene vrednosti code_verifier. RFC 10017 §6.3.2.1, RFC 9700 §2.1.1
| Preverjanje | Dokaz in odgovorna komponenta |
|---|---|
| Natančno ujemanje preusmeritve | Avtorizacijski strežnik zavrne neregistrirane spremembe vrednosti redirect_uri v zahtevi, vključno s spremenjenimi gostitelji, potmi in poizvedbenimi nizi. Preverjajte glede na nabor registriranih URI-jev. RFC 9700 §2.1 |
| Zaščita povratnega klica pred CSRF | Odjemalec dokaže delovanje izbrane zaščite: PKCE s preverjeno podporo strežnika in vezavo na transakcijo; pravilno preverjanje parametra OIDC nonce; ali enkratni žeton state, varno vezan na brskalnik, ki je začel postopek. RFC 9700 §2.1 |
| Vezava na izdajatelja | Odjemalec, ki podpira več avtorizacijskih strežnikov, pričakovanega izdajatelja veže na transakcijo in preveri odgovor z identifikacijo izdajatelja ali s predpisano zaščito z ločenimi preusmeritvenimi URI-ji. RFC 9700 §4.4.2 |
| Obravnava povratnega klica | Aplikacija obdela avtorizacijski odgovor, iz vidnega URL-ja nemudoma odstrani občutljive podatke odgovora in prepreči razkritje prek skript na strani, glave Referer ali telemetrije. RFC 9700 §4.2, §4.3 |
Natančno ujemanje velja za redirect_uri, poslan v avtorizacijski zahtevi. Avtorizacijskemu strežniku ne prepoveduje, da povratnemu naslovu doda veljavne parametre odgovora, kot sta code in state. Izjema za vrata naslova localhost pri izvornih aplikacijah ne dovoljuje nadomestnih vzorcev za povratne naslove aplikacije SPA. Odjemalci in avtorizacijski strežniki prav tako ne smejo omogočati odprtih preusmeritev. RFC 9700 §2.1
state ni vedno obvezen, kadar je pravilno izvedena druga dovoljena zaščita pred CSRF. Organizacija ga lahko zahteva poleg PKCE, vendar je to strožja organizacijska politika. Če state prenaša podatke aplikacije, vsebino, pri kateri je pomembna celovitost, zaščitite pred spreminjanjem in zamenjavo. RFC 9700 §4.7.1
Ločeno preizkusite štiri lastnosti PKCE
Ime knjižnice ni dokaz uspešnega preizkusa. V preizkusnem okolju ločite ustvarjanje vrednosti pri odjemalcu od njihovega preverjanja na avtorizacijskem strežniku.
| Lastnost | Dokaz, ki ga shranite |
|---|---|
| Naključnost in svežina pri odjemalcu | Preglejte uporabo kriptografsko varnega generatorja naključnih vrednosti in preverite, da ločeni poskusi avtorizacije ustvarijo nove vrednosti code_verifier. Vsaka mora ustrezati zahtevam RFC glede zapisa in dolžine. Podatke transakcije vežite na brskalnik, ki jo je začel. RFC 7636 §4.1, RFC 9700 §2.1.1 |
| Preverjanje ujemanja z izzivom na strežniku | Za kodo, izdano z izzivom S256, dokažite, da končna točka za žetone zavrne manjkajočo ali neustrezno vrednost code_verifier in sprejme pravilno vrednost za veljavno, še neuporabljeno kodo. RFC 7636 §4.4, §4.6 |
| Zavrnitev ponovne uporabe avtorizacijske kode | Po uspešni zamenjavi dokažite, da avtorizacijski strežnik zavrne ponovno zamenjavo iste kode, tudi s pravilno vrednostjo code_verifier. RFC 9700 §4.5 |
| Zavrnitev oslabitve zaščite | Preverite uveljavljanje zaščite na strežniku za nastavljenega odjemalca in odsotnost prehoda na šibkejši način pri odjemalcu. Zahteva za žeton z vrednostjo code_verifier ne sme uspeti za kodo, izdano brez izziva; obvezni PKCE že pri avtorizaciji prepreči izdajo take kode. RFC 9700 §4.8.2 |
Odjemalec, ki pri novih avtorizacijskih zahtevah znova uporablja isto vrednost code_verifier, krši zahtevo po svežini. Strežnik pa novo izdane kode ne zavrne nujno zgolj zato, ker se je pripadajoča preveritvena vrednost pojavila že v prejšnji transakciji. To ni isto kot ponovna uporaba avtorizacijske kode.
Za te izvedbene primere kot izrecno pravilo za izdajo zahtevajte S256 in zavrnite prehod na plain. RFC 7636 od odjemalcev, ki podpirajo S256, zahteva njegovo uporabo; RFC 9700 priporoča metode izziva, ki ne razkrijejo preveritvene vrednosti. Splošne podpore strežnika za plain ne predstavljajte kot dokaz oslabitve zaščite v preizkušeni transakciji. RFC 7636 §4.2, RFC 9700 §2.1.1
Skupaj preverite zaščito osveževanja in potek veljavnosti
Pri osvežitvenih žetonih, izdanih javnim odjemalcem v brskalniku, je rotacija ali vezava na pošiljatelja le del zahtev. Avtorizacijski strežnik mora določiti tudi najdaljšo življenjsko dobo ali potek po obdobju neaktivnosti. Če ima prvotni žeton vnaprej določen čas poteka, rotacija ne sme podaljšati veljavnosti nadomestnega žetona prek tega roka. RFC 10017 §6.3.2.3
| Preverjanje | Dokaz z avtorizacijskega strežnika |
|---|---|
| Rotacija, če je izbrana | Vsako osveževanje zamenja in razveljavi prejšnji žeton. Strežnik zazna ponovno uporabo razveljavljenega žetona in prekliče aktivni osvežitveni žeton, povezan z isto avtorizacijsko odobritvijo. RFC 9700 §4.14.2 |
| Vezava na pošiljatelja, če je izbrana | Poskus osveževanja brez zahtevanega dokazila ali z napačnim ključem ne uspe. RFC 9700 §4.14.2 |
| Potek veljavnosti | Osveževanje ne uspe po nastavljeni najdaljši življenjski dobi ali obdobju neaktivnosti, skladno z izbrano politiko. RFC 10017 §6.3.2.3 |
| Rok pri rotaciji | Kadar je prvotni rok poteka fiksen, zaporedni nadomestni žetoni ne omogočajo osveževanja po tem roku. RFC 10017 §6.3.2.3 |
Brisanje shranjenega žetona je lokalno čiščenje. Ne razveljavi ukradene kopije in ne nadomesti strežniške rotacije, vezave na pošiljatelja, poteka veljavnosti ali preklica. Pri BFF ali zaledju, ki posreduje žetone in deluje kot zaupni odjemalec, preverite avtentikacijo odjemalca in vezavo osvežitvenega žetona nanj; vseh pravil za javne odjemalce ne prenašajte samodejno na zaupne. RFC 9700 §4.14
Shranjevanje in XSS ocenite glede na arhitekturo
Shranjevanje v brskalniku ni splošno prepovedano. Obstojne shrambe, kot sta localStorage in IndexedDB, ter hranjenje v pomnilniku se razlikujejo po trajanju in izpostavljenosti. Izolacija v spletnem delavcu (Web Worker) lahko omeji neposreden dostop do obstoječih žetonov, vendar sama izolacija shrambe zlonamerni kodi ne prepreči pridobivanja novih žetonov prek tokov, ki so na voljo aplikaciji. RFC 10017 §8
Uporabite merila sprejemljivosti za izbrano arhitekturo:
- BFF s strežniško shrambo, izbran v tem članku: žetonov OAuth ni v odgovorih brskalniku, pomnilniku JavaScripta ali shrambah brskalnika. Brskalnik hrani le piškotek aplikacijske seje.
- Zaledje, ki posreduje žetone: dostopni žetoni OAuth so v brskalniku namenoma; osvežitveni žetoni morajo ostati pod nadzorom zaledja in nedostopni JavaScriptu v brskalniku.
- Odjemalec samo v brskalniku: dokumentirajte, kateri žetoni so v pomnilniku ali obstojni shrambi, kdo lahko dostopa do njih, kako dolgo ostanejo shranjeni ter kaj se zgodi ob ponovnem nalaganju in odjavi. Prepoved obstojnega shranjevanja žetonov je neobvezna organizacijska politika, ne splošna zahteva RFC.
Pri vseh arhitekturah nenamerno razkritje prek URL-jev, dnevnikov, analitike, poročil o napakah ali glave Referer obravnavajte kot napako. Avtorizacijska koda, ki pravilno prispe na povratni naslov, ni enaka dostopnemu žetonu v URL-ju. Čiščenje URL-ja tudi ne more izbrisati podatkov, ki so že prišli v dnevnik ali analitično storitev.
Pri BFF zahtevajte piškotke z atributoma Secure in HttpOnly. Upoštevajte priporočila RFC za SameSite=Strict, Path=/, odsotnost atributa Domain in predpono, ki označuje nastavitev piškotka prek HTTP, na primer __Host-Http-; utemeljena odstopanja od priporočil dokumentirajte. Path=/ zajema celotnega gostitelja in ne zgolj ozke poti aplikacije. RFC 10017 §6.1.3.2
Izvedite in preizkusite ustrezno zaščito pred CSRF za končne točke, ki uporabljajo avtentikacijo s piškotki. Pri oceni zaščite SameSite upoštevajte druge aplikacije na istem spletnem mestu. RFC 10017 §6.1.3.3
Omejite cilje posredovanja in dovoljene poti, da vhodni podatki odjemalca ne morejo povzročiti pošiljanja uporabnikovega žetona neodobrenemu gostitelju ali na nedovoljeno pot. Ciljne gostitelje preverjajte glede na izrecen seznam odobrenih strežnikov virov; dinamično nastavljiv posrednik mora dovoliti le izrecno dovoljene gostitelje in poti. RFC 10017 §6.1.3.6
BFF zmanjša možnost iznosa žetonov, vendar lahko vstavljena koda še vedno deluje prek aktivne seje. V zasnovo vključite preprečevanje XSS, nadzor nad skriptami in najmanjša potrebna pooblastila. RFC 10017 §5
Odločitev o izdaji in shranjeni dokazi
Zgornja preverjanja uporabite kot predlog pravil za izdajo. Izdajo ustavite ob neustreznem ujemanju preusmeritev, neučinkoviti zaščiti povratnega klica, neuspešnih preverjanjih PKCE, manjkajoči zahtevani zaščiti osveževanja, neodobrenih ciljih posredovanja, nenamernem razkritju poverilnic ali izpostavljenosti žetonov, ki nasprotuje izbrani arhitekturi. Namerno ravnanje z žetoni v brskalniku samo po sebi ni razlog za ustavitev izdaje.
Popis podatkovnih tokov in rezultate preizkusov z odstranjenimi občutljivimi vrednostmi shranite v lastno arhitekturno dokumentacijo, zapis o izdaji ali sistem za sledenje nalogam. Zabeležite lokacije žetonov, nastavitve piškotkov, preusmeritvene URI-je, izdajatelje, strežnike virov, obsege pooblastil, pravila poteka veljavnosti ter vedenje ob odjavi in preklicu. Izrecno vključite izpostavljenost žetonov, preostali vpliv XSS, odgovorne za odpravo in rezultate ponovnih preizkusov. Dokaze hranite brez poverilnic, ki bi jih bilo mogoče ponovno uporabiti.
Za dodatno branje o razlagi poslovnega vpliva in prednostnih nalogah odprave glejte Poročanje in tveganja (v angleščini). Stran pojasnjuje pristop k ocenjevanju; dokaze za izdajo hranite v lastnih evidencah.
Ta preverjanja potrjujejo določene meje in opaženo vedenje. Ne dokazujejo, da aplikacija, ponudnik identitete, brskalnik ali odvisnosti nimajo ranljivosti.
Pogosta vprašanja
Ali PKCE izenači brskalniško aplikacijo SPA z BFF? Ne. PKCE ščiti zamenjavo avtorizacijske kode. Arhitektura določa, ali aplikacija prejme žetone in katera dejanja lahko izvaja zlonamerna koda v brskalniku.
Ali je piškotek HttpOnly dostopen JavaScriptu? Njegova vrednost ni. Brskalnik ga lahko še vedno doda zahtevam, ki jih sproži JavaScript, tudi vstavljena koda.
Ali se mora vsak brskalniški odjemalec izogniti obstojni shrambi? Splošne prepovedi ni. Dokumentirajte prednosti in tveganja izbrane shrambe, uveljavite zahtevano zaščito osveževanja in navedite morebitno strožjo organizacijsko politiko.
Nadaljnje branje
Zanima vas več o tej temi? Preberite mojo strokovno stran o Web Application Security →
Komentarji
Ni še komentarjev. Bodite prvi!
Dodaj komentar