Admin-subdomein stop nie CSRF nie: vier kontroles voor die bekendstelling

Om die administratiewe koppelvlak na admin.example.com te skuif, is n werklike verbetering: dit hou admin-koekies weg van openbare bladsye, gee die twee toepassings aparte kasgeheues en laat jou n strenger netwerkbeleid op een gasheernaam rig. Dit is egter nie n CSRF-beheer nie, en dit maak die openbare werf se kode nie veilig om oop te he vir n aangemelde administrateur nie. Die skeiding verander wat die blaaier as n grens beskou, nie wat die bediener nagaan nie. Werk dus hierdie vier kontroles deur voordat jy se dat dit klaar is.

Lees oorsprong en werf as twee verskillende woorde

n Oorsprong is skema, gasheer en poort, so https://www.example.com en https://admin.example.com is verskillende oorspronge. n Werf, in die SameSite-sin, is skema plus registreerbare domein, so daardie twee gasheername is gewoonlik dieselfde werf. Daardie verskil is die hele lokval: die SameSite-eienskap sal jou nie oor suster-subdomeine help nie, want die blaaier beskou die versoek glad nie as kruiswerf nie. Rig die admin-koppelvlak op n werklik ander registreerbare domein, soos admin-example.net, en die versoek word wel kruiswerf, en dit is waar SameSite=Lax of Strict werk begin doen waarop jy kan staatmaak.

Toets dit in die blaaier eerder as om daaroor te redeneer.

Laai die openbare werf, maak die ontwikkelaarnutte oop en kyk watter koekies die blaaier aan n versoek na die admin-gasheer heg. As die koekie geen Domain-eienskap het nie, is dit slegs-gasheer en bly dit op sy eie gasheernaam; as dit Domain=example.com dra, reis dit na elke suster, en die nuwe subdomein het vir daardie koekie niks opgelewer nie.

Skei kan die antwoord lees van kan die versoek stuur

Die selfde-oorsprongbeleid beperk die lees van antwoorde oor oorspronge. Dit stop nie n versoek om gestuur te word nie, en dit stop nie n vormplasing om geloofsbriewe te dra wat die blaaier reeds hou nie. n Eenvoudige versoek, een met n vorm-inhoudtipe of n gewone GET, word sonder voorvlug afgelewer; CORS besluit dan of die roepende script die antwoord mag lees. CSRF le heeltemal aan die stuur-kant.

Daarom het die bediener n eksplisiete kontrole vir toestandveranderende bewerkings nodig. n Sinchroniseerder-token wat aan die sessie gekoppel is, of n dubbelplasing-koekie wat bedienerkant vergelyk word, dek die geval; n Origin- of Referer-vergel-yking is die moeite werd om as tweede hek by te voeg, maar nie as die enigste nie, want nie elke versoek dra die kop nie en nie elke proxy bewaar dit nie. OWASP se CSRF-voorkomingsriglyne behandel SameSite as een laag onder verskeie, juis om hierdie rede.

Bepaal wat die netwerkhek werklik bewys

n VPN-uitgang-allowlist voor die admin-gasheernaam is n goeie beheer en n swak identiteitsbewering. Dit bewys dat die versoek van n adres kom wat die VPN uitdeel, wat deur almal op daardie uitgang gedeel kan word, en dit se niks oor watter persoon of toestel daar agter is nie. Behandel dit as n ingangsfilter, nie as verifikasie nie.

Hou dit onafhanklik van die versoekvlak-kontroles. As die allowlist die enigste ding tussen n aanvaller en n toestandveranderende eindpunt is, verwyder een verkeerd opgestelde roete, een split-tunnel-kliënt of een geleende skootrekenaar die beheer heeltemal.

Merk ook verwerpe van buite die verwagte reekse aan. n Uitbarsting daarvan is die nuttigste sein dat iemand die grens peil wat jy pas gebou het, en stilte is die sein dat die filter glad nie bereik word nie.

Hou koekies, aanmelding en magtiging eksplisiet

Koekiebestek bepaal die meeste van die uitkoms. n Ouerdomein-koekie word na die admin-gasheer gestuur, so n script-inspuiting op die openbare werf kan met n administrateur se sessie optree; n slegs-gasheer-koekie kan nie. Verkies die slegs-gasheer-vorm, voeg die Secure-eienskap by en gebruik die __Host--voorvoegsel waar die platform dit ondersteun, want daardie voorvoegsel vereis Secure, Path=/ en geen Domain-eienskap nie. Lees die antwoordkop eerder as die koekiepot: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, sonder Domain-eienskap. n Blaaier laat val n __Host--koekie wat Domain dra, so n koekie wat steeds op suster-gashere verskyn, is bewys dat die voorvoegsel nooit toegepas is nie.

Hou dan magtiging op die bediener, per versoek, op elke administratiewe eindpunt, nie net by aanmelding nie. n Versoek wat van n toegelate netwerk kom, moet steeds verifieer en gemagtig word vir die bewerking wat dit vra; die gasheernaam is nie n akteur nie. As die openbare en admin-toepassings n aanmeldvloei of n sessieberg deel, skryf daardie verhouding neer, want dit is die kortste pad van n openbare-werf-fout na n admin-aksie.

Kontroleer die grens weer na die skeiding

Voer die negatiewe toetse uit, nie net die gelukkige pad nie: n kruiswerf-vormplasing sonder token moet verwerp word, n token van n ander sessie moet verwerp word, en geen GET mag toestand verander nie. Kontroleer die koekie-eienskappe in ontwikkelaarnutte, bevestig dat die Origin-kontrole op n stemmende versoek afvuur, en probeer die admin-gasheer van buite die VPN-reeks om te sien dat die filter werk.

Niks hiervan verwyder n XSS-fout binne die admin-toepassing self nie. n Aparte gasheernaam is n blaaierkant-isolasiegrens met werklike waarde, en dit is nie n plaasvervanger vir die voorkoming van onveilige kode-uitvoering of vir bedienerkant-versoekbeskerming nie. Na die skeiding is die kontrolelys korter as wat dit lyk: aparte oorsprong, slegs-gasheer-koekies, n token op elke wysiging, n ingangsfilter wat jy nie as identiteit vertrou nie, en magtiging wat per versoek bepaal word.