Subdomain-i i administrimit nuk e ndal CSRF: katër kontrolle para nisjes

Kalimi i ndërfaqes së administrimit në admin.example.com është një përmirësim i vërtetë: i mban cookie-t e administrimit larg faqeve publike, u jep të dy aplikacioneve cache të veçanta dhe ju lejon të drejtoni një politikë rrjeti më të rreptë në një emër të vetëm hosti. Por nuk është kontroll CSRF dhe nuk e bën kodin e sajtit publik të sigurt për ta lënë të hapur përpara një administratori të kyçur. Ndarja ndryshon atë që shfletuesi e konsideron kufi, jo atë që verifikon serveri, prandaj kryeni këto katër kontrolle përpara se ta shpallni të përfunduar.

Lexoni origjinën dhe sajtin si dy fjalë të ndryshme

Origjina është skema, hosti dhe porta, prandaj https://www.example.com dhe https://admin.example.com janë origjina të ndryshme. Sajti në kuptimin SameSite është skema plus domain-i i regjistrueshëm, prandaj këta dy emra hosti janë zakonisht i njëjti sajt. Ky ndryshim është e gjithë kurthi: atributi SameSite nuk do t’ju ndihmojë mes subdomain-eve motra, sepse shfletuesi nuk e konsideron fare kërkesën si ndërsajtëse. Drejtojeni ndërfaqen e administrimit në një domain të regjistrueshëm vërtet tjetër, si admin-example.net, dhe kërkesa bëhet vërtet ndërsajtëse, dhe aty SameSite=Lax ose Strict fillon të bëjë punë ku mund të mbështeteni.

Testojeni në shfletues në vend që të arsyetoni për të.

Ngarkoni sajtin publik, hapni mjetet e zhvilluesit dhe shikoni cilat cookie shfletuesi lidh me një kërkesë drejt hostit të administrimit. Nëse cookie-t i mungon atributi Domain, është vetëm për hostin dhe qëndron në emrin e vet; nëse mban Domain=example.com, shkon te çdo motër, dhe subdomain-i i ri nuk ju dha asgjë për atë cookie.

Ndani leximin e përgjigjes nga dërgimi i kërkesës

Politika e së njëjtës origjinë kufizon leximin e përgjigjeve mes origjinave. Nuk e ndal dërgimin e një kërkese dhe nuk pengon një formular të mbajë kredencialet që shfletuesi tashmë i ka. Një kërkesë e thjeshtë, me tip përmbajtjeje formulari ose GET të thjeshtë, dorëzohet pa verifikim paraprak; pastaj CORS vendos nëse skripti që thërret mund ta lexojë përgjigjen. CSRF jeton tërësisht në anën e dërgimit.

Prandaj serveri ka nevojë për një kontroll të shprehur për veprimet që ndryshojnë gjendjen. Një token sinkronizimi i lidhur me sesionin, ose një cookie dërgimi të dyfishtë i krahasuar në server, e mbulon rastin; krahasimi i Origin ose Referer meriton të shtohet si porta e dytë, por jo si e vetmja, sepse jo çdo kërkesë e mban atë header dhe jo çdo proxy e ruan. Udhëzuesi i OWASP për parandalimin e CSRF e trajton SameSite si një shtresë mes disa, pikërisht për këtë arsye.

Vendosni çfarë vërteton vërtet porta e rrjetit

Një listë e lejuar e daljeve VPN përpara hostit të administrimit është kontroll i mirë dhe pretendim i dobët identiteti. Vërteton që kërkesa erdhi nga një adresë që jep VPN-ja, të cilën mund ta ndajnë të gjithë në atë dalje, dhe nuk thotë asgjë për personin ose pajisjen pas saj. Trajtojeni si filtër hyrjeje, jo si vërtetim identiteti.

Mbajeni të pavarur nga kontrollet në nivel kërkese. Nëse lista është e vetmja gjë mes një sulmuesi dhe një pikë fundore që ndryshon gjendjen, një rrugë e konfiguruar gabimisht, një klient split-tunnel ose një laptop i huazuar e heq kontrollin plotësisht.

Regjistroni edhe refuzimet jashtë intervaleve të pritura. Shpërthimi i tyre është sinjali më i dobishëm se dikush po heton kufirin që sapo ndërtuat, dhe heshtja është sinjali se filtri nuk arrihet fare.

Mbajini cookie-t, hyrjen dhe autorizimin të shprehur

Shtrirja e cookie-t vendos pjesën më të madhe të rezultatit. Një cookie e domain-it prind dërgohet te hosti i administrimit, prandaj një injektim skripti në sajtin publik mund të veprojë me sesionin e një administratori; një cookie vetëm për hostin nuk mundet. Preferoni formën vetëm për hostin, shtoni atributin Secure dhe përdorni prefiksin __Host- aty ku platforma e mbështet, sepse ai prefiks kërkon Secure, Path=/ dhe pa atribut Domain. Lexoni header-in e përgjigjes dhe jo kavanozin e cookie-ve: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, pa atribut Domain. Shfletuesi hedh poshtë një cookie __Host- që mban Domain, prandaj një cookie që shfaqet ende në hoste motra është provë se prefiksi nuk u zbatua kurrë.

Pastaj mbajeni autorizimin në server, për çdo kërkesë, në çdo pikë fundore administrative, jo vetëm në hyrje. Një kërkesë që vjen nga një rrjet i lejuar duhet ende të vërtetohet dhe të autorizohet për veprimin që kërkon; emri i hostit nuk është aktor. Nëse aplikacioni publik dhe ai administrativ ndajnë një rrjedhë hyrjeje ose një depo sesionesh, shkruajeni atë marrëdhënie, sepse është rruga më e shkurtër nga një defekt në sajtin publik te një veprim administrativ.

Rikontrolloni kufirin pas ndarjes

Ekzekutoni testet negative, jo vetëm rrugën e lumtur: një formular ndërsajtës pa token duhet të refuzohet, një token nga një sesion tjetër duhet të refuzohet dhe asnjë GET nuk duhet të ndryshojë gjendjen. Kontrolloni atributet e cookie-ve në mjetet e zhvilluesit, konfirmoni që kontrolli i Origin aktivizohet në një kërkesë që nuk përputhet dhe provoni hostin e administrimit nga jashtë intervalit të VPN për ta parë filtrin në punë.

Asgjë nga kjo nuk e eliminon një defekt XSS brenda vetë aplikacionit administrativ. Një emër i veçantë hosti është një kufi izolimi në anën e shfletuesit me vlerë reale dhe nuk zëvendëson parandalimin e ekzekutimit të kodit të pasigurt ose mbrojtjen e kërkesave në anën e serverit. Pas ndarjes lista është më e shkurtër se sa duket: origjinë e veçantë, cookie vetëm për hostin, një token në çdo ndryshim, një filtër hyrjeje të cilit nuk i besoni si identitet dhe autorizim i vendosur për çdo kërkesë.