El subdomini d’administració no atura el CSRF: quatre comprovacions abans de publicar

Moure la interfície administrativa a admin.example.com és una millora real: manté les galetes d’administració lluny de les pàgines públiques, dona memòries cau separades a les dues aplicacions i permet dirigir una política de xarxa més estricta a un sol nom d’amfitrió. Però no és un control contra el CSRF ni fa que el codi del lloc públic sigui segur de deixar obert davant d’un administrador autenticat. La separació canvia què considera frontera el navegador, no què comprova el servidor, així que feu aquestes quatre comprovacions abans de donar-ho per acabat.

Llegiu origen i lloc com dues paraules diferents

Un origen és esquema, amfitrió i port, així que https://www.example.com i https://admin.example.com són orígens diferents. Un lloc, en el sentit de SameSite, és esquema més domini registrable, així que aquests dos noms d’amfitrió solen ser el mateix lloc. Aquesta diferència és tot el parany: l’atribut SameSite no us ajudarà entre subdominis germans, perquè el navegador no considera la petició cross-site en absolut. Adreceu la interfície administrativa a un domini registrable realment diferent, com admin-example.net, i la petició sí que esdevé cross-site, i és aquí on SameSite=Lax o Strict comença a fer feina en què podeu confiar.

Proveu-ho al navegador en lloc de raonar-hi.

Carregueu el lloc públic, obriu les eines de desenvolupament i mireu quines galetes adjunta el navegador a una petició cap a l’amfitrió administratiu. Si la galeta no té atribut Domain, és només d’amfitrió i es queda al seu propi nom; si porta Domain=example.com, viatja a cada germà, i el subdomini nou no us ha aportat res per a aquesta galeta.

Separeu poder llegir la resposta de poder enviar la petició

La política del mateix origen restringeix llegir respostes entre orígens. No atura que s’enviï una petició ni impedeix que un formulari porti credencials que el navegador ja té. Una petició simple, amb tipus de contingut de formulari o un GET pla, es lliura sense comprovació prèvia; CORS decideix després si l’script que crida pot llegir la resposta. El CSRF viu del tot al costat de l’enviament.

Per això el servidor necessita una comprovació explícita per a operacions que canvien estat. Un token de sincronització lligat a la sessió, o una galeta de doble enviament comparada al servidor, cobreix el cas; comparar Origin o Referer val la pena com a segona porta, però no com a única, perquè no tota petició porta la capçalera ni tot proxy la conserva. La guia d’OWASP per prevenir el CSRF tracta SameSite com una capa entre diverses exactament per aquest motiu.

Decidiu què demostra realment la porta de xarxa

Una llista d’exits de VPN permesos davant de l’amfitrió administratiu és un bon control i una afirmació d’identitat feble. Demostra que la petició ve d’una adreça que la VPN atorga, que poden compartir tots els qui són en aquesta sortida, i no diu res sobre quina persona o dispositiu hi ha al darrere. Tracteu-la com un filtre d’entrada, no com una autenticació.

Manteniu-la independent de les comprovacions a nivell de petició. Si la llista és l’única cosa entre un atacant i un punt final que canvia estat, una ruta mal configurada, un client amb split-tunnel o un portàtil prestat elimina el control del tot.

Registreu també els rebuigs de fora dels rangs esperats. Una allau és el senyal més útil que algú està sondant la frontera que acabeu de construir, i el silenci és el senyal que el filtre no s’està assolint gens.

Manteniu explícites les galetes, l’inici de sessió i l’autorització

L’abast de la galeta decideix la major part del resultat. Una galeta del domini pare s’envia a l’amfitrió administratiu, així que una injecció d’script al lloc públic pot actuar amb la sessió d’un administrador; una galeta només d’amfitrió no pot. Preferiu la forma només d’amfitrió, afegiu l’atribut Secure i useu el prefix __Host- on la plataforma el suporti, perquè aquest prefix exigeix Secure, Path=/ i cap atribut Domain. Llegiu la capçalera de resposta i no el pot de galetes: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, sense atribut Domain. El navegador descarta una galeta __Host- que porti Domain, així que una galeta que encara apareix als amfitrions germans és prova que el prefix no es va aplicar mai.

Després manteniu l’autorització al servidor, per petició, a cada punt final administratiu, no només a l’inici de sessió. Una petició d’una xarxa permesa encara s’ha d’autenticar i autoritzar per a l’operació que demana; el nom d’amfitrió no és un actor. Si les aplicacions pública i administrativa comparteixen un flux d’inici de sessió o un magatzem de sessions, escriviu aquesta relació, perquè és el camí més curt d’un error al lloc públic a una acció administrativa.

Torneu a comprovar la frontera després de la separació

Feu les proves negatives, no només el camí feliç: un formulari cross-site sense token s’ha de rebutjar, un token d’una altra sessió s’ha de rebutjar i cap GET no ha de canviar estat. Comproveu els atributs de les galetes a les eines de desenvolupament, confirmeu que la comprovació d’Origin salta en una petició que no coincideix i proveu l’amfitrió administratiu des de fora del rang de la VPN per veure el filtre en acció.

Res d’això no elimina un defecte XSS dins de l’aplicació administrativa mateixa. Un nom d’amfitrió separat és una frontera d’aïllament del costat del navegador amb valor real, i no substitueix la prevenció d’execució de codi insegur ni la protecció de peticions al servidor. Després de la separació la llista és més curta del que sembla: origen diferent, galetes només d’amfitrió, un token a cada mutació, un filtre d’entrada en què no confieu com a identitat i autorització decidida per petició.