Admin-subdomein stopet gjin CSRF: fjouwer kontrôles foar de lansearring

It ferpleatsen fan de admin-interface nei admin.example.com is in echte ferbettering: it hâldt admin-cookies fuort fan iepenbiere siden, jout de twa applikaasjes aparte caches en lit jo in strangere netwurkbelied op ien hostnamme rjochtsje. Mar it is gjin CSRF-kontrôle, en it makket de koade fan de iepenbiere side net feilich om iepen te litten foar in oanmelde administrator. De skieding feroaret wat de browser as grins beskôget, net wat de tsjinner kontrolearret, dus doch dizze fjouwer kontrôles foardat jo it klear neame.

Lês oarsprong en side as twa ferskillende wurden

In oarsprong is skema, host en poarte, dus https://www.example.com en https://admin.example.com binne ferskillende oarsprongen. In side, yn de sin fan SameSite, is skema plus registrearber domein, dus dy twa hostnammen binne meast deselde side. Dat ferskil is de hiele fal: it SameSite-attribút sil jo net helpe tusken suster-subdomeinen, om’t de browser it fersyk hielendal net as cross-site beskôget. Rjochtsje de admin-interface op in wier oar registrearber domein, lykas admin-example.net, en it fersyk wurdt wol cross-site, en dêr begjint SameSite=Lax of Strict wurk te dwaan dêr’t jo op fertrouwe kinne.

Test it yn de browser ynstee fan der oer te riddenearjen.

Laad de iepenbiere side, iepenje de ûntwikkelersark en sjoch hokker cookies de browser oan in fersyk nei de admin-host taheakket. As de cookie gjin Domain-attribút hat, is it allinnich foar de host en bliuwt it op syn eigen namme; as it Domain=example.com draacht, reizget it nei elke suster, en it nije subdomein hat jo foar dy cookie neat brocht.

Skied it lêzen fan it antwurd fan it stjoeren fan it fersyk

It belied fan deselde oarsprong beheint it lêzen fan antwurden tusken oarsprongen. It stopet net dat in fersyk stjoerd wurdt, en it stopet net dat in formulier bewiisstikken meidraacht dy’t de browser al hat. In ienfâldich fersyk, mei in formulier-ynhâldtype of in gewoane GET, wurdt sûnder foarôfgeande kontrôle levere; CORS beslút dêrnei oft it oanroppende skript it antwurd lêze mei. CSRF libbet hielendal oan de stjoerkant.

Dêrom hat de tsjinner in eksplisite kontrôle nedich foar operaasjes dy’t de steat feroarje. In syngronisaasjetoken bûn oan de sesje, of in cookie mei dûbele ferstjoering dy’t op de tsjinner ferlike wurdt, dekt it gefal; in Origin- of Referer-fergeliking is de muoite wurdich as twadde poarte, mar net as de iennige, om’t net elk fersyk de kop draacht en net elke proxy dy bewarret. De OWASP-rjochtline foar it foarkommen fan CSRF behannelet SameSite as ien laach ûnder mear, krekt om dy reden.

Beslis wat de netwurkpoarte echt bewiist

In list fan tastiene VPN-útgongen foar de admin-host is in goede kontrôle en in swakke identiteitsbewearing. It bewiist dat it fersyk fan in adres kaam dat it VPN jout, dat troch elkenien op dy útgong dield wurde kin, en it seit neat oer wa’t persoan of apparaat der efter sit. Behandel it as in yngongsfilter, net as autentikaasje.

Hâld it ûnôfhinklik fan de kontrôles op fersyksnivo. As de list it iennige is tusken in oanfaller en in steatferoarjend einpunt, dan ferwideret ien ferkeard konfigurearre rûte, ien split-tunnel-klant of ien liend laptop de kontrôle hielendal.

Registrearje ek de ôfwizingen fan bûten de ferwachte berikken. In bulte dêrfan is it nuttichste sinjaal dat immen de grins besiket dy’t jo krekt boud hawwe, en stilte is it sinjaal dat it filter hielendal net berikt wurdt.

Hâld cookies, oanmelden en autorisaasje eksplisyt

It berik fan de cookie beslút it measte fan it resultaat. In cookie fan it âlderdomyn wurdt nei de admin-host stjoerd, dus in skript-ynjeksje op de iepenbiere side kin mei de sesje fan in administrator hannelje; in cookie allinnich foar de host kin dat net. Foarkar de foarm allinnich foar de host, foegje it Secure-attribút ta en brûk it foarheaksel __Host- dêr’t it platfoarm it stipet, om’t dat foarheaksel Secure, Path=/ en gjin Domain-attribút easket. Lês de antwurdkop ynstee fan de cookietrommel: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, sûnder Domain-attribút. In browser smyt in __Host--cookie mei Domain fuort, dus in cookie dy’t noch op susterhosts te sjen is, is bewiis dat it foarheaksel nea tapast is.

Hâld dêrnei de autorisaasje op de tsjinner, per fersyk, op elk admin-einpunt, net allinnich by it oanmelden. In fersyk fan in tastien netwurk moat noch altiten autentisearre en autorisearre wurde foar de operaasje dy’t it freget; de hostnamme is gjin akteur. As de iepenbiere en admin-applikaasje in oanmeldstream of in sesje-opslach diele, skriuw dy relaasje op, om’t it de koartste wei is fan in flater op de iepenbiere side nei in admin-aksje.

Kontrolearje de grins opnij nei de skieding

Rin de negative tests, net allinnich it lokkige paad: in cross-site-formulier sûnder token moat wegere wurde, in token fan in oare sesje moat wegere wurde, en gjin GET mei de steat feroarje. Kontrolearje de cookie-attributen yn de ûntwikkelersark, befêstigje dat de Origin-kontrôle ôfgiet by in net oerienkommend fersyk, en probearje de admin-host fan bûten it VPN-berik om it filter wurkje te sjen.

Neat hjirfan hellet in XSS-flater yn de admin-applikaasje sels fuort. In aparte hostnamme is in isolaasjegrins oan de browserkant mei echte wearde, en it is gjin ferfanging foar it foarkommen fan ûnfeilige koade-útfiering of foar it beskermjen fan fersiken oan de tsjinnerkant. Nei de skieding is de list koarter as it liket: in aparte oarsprong, cookies allinnich foar de host, in token by elke feroaring, in yngongsfilter dêr’t jo net op fertrouwe as identiteit, en autorisaasje besletten per fersyk.