O subdominio de administración non detén o CSRF: catro comprobacións antes de publicar

Mover a interface administrativa a admin.example.com é unha mellora real: mantén as cookies de administración lonxe das páxinas públicas, dá ás dúas aplicacións cachés separadas e permite dirixir unha política de rede máis estrita a un só nome de host. Non é un control contra CSRF, e non fai que o código do sitio público sexa seguro para deixalo aberto ante un administrador con sesión iniciada. A separación cambia o que o navegador considera un límite, non o que comproba o servidor, así que faga estas catro comprobacións antes de dalo por terminado.

Lea orixe e sitio como dúas palabras distintas

Unha orixe é esquema, host e porto, así que https://www.example.com e https://admin.example.com son orixes distintas. Un sitio, no sentido de SameSite, é esquema máis dominio rexistrable, así que eses dous nomes de host adoitan ser o mesmo sitio. Esa diferenza é toda a trampa: o atributo SameSite non lle axudará entre subdominios irmáns, porque o navegador non considera a petición entre sitios en absoluto. Dirixa a interface administrativa a un dominio rexistrable realmente distinto, como admin-example.net, e a petición si pasa a ser entre sitios, e aí é onde SameSite=Lax ou Strict comeza a facer un traballo no que pode confiar.

Próbeo no navegador en lugar de razoar sobre iso.

Cargue o sitio público, abra as ferramentas de desenvolvemento e mire que cookies engade o navegador a unha petición dirixida ao host administrativo. Se a cookie non ten atributo Domain, é só de host e queda no seu propio nome; se leva Domain=example.com, viaxa a cada irmán, e o novo subdominio non lle aportou nada para esa cookie.

Separe poder ler a resposta de poder enviar a petición

A política do mesmo orixe restrinxe ler respostas entre orixes. Non impide que se envíe unha petición nin que un formulario leve credenciais que o navegador xa ten. Unha petición simple, con tipo de contido de formulario ou un GET simple, entrégase sen comprobación previa; CORS decide despois se o script que chama pode ler a resposta. O CSRF vive por completo no lado do envío.

Por iso o servidor necesita unha comprobación explícita para operacións que cambian estado. Un token de sincronización ligado á sesión, ou unha cookie de dobre envío comparada no servidor, cobre o caso; comparar Origin ou Referer merece engadirse como segunda porta pero non como a única, porque non toda petición leva a cabeceira e non todo proxy a conserva. A guía de OWASP para previr CSRF trata SameSite como unha capa entre varias exactamente por iso.

Decida que demostra realmente a porta de rede

Unha lista de saídas VPN permitidas diante do host administrativo é un bo control e unha afirmación de identidade feble. Demostra que a petición veu dun enderezo que entrega a VPN, que poden compartir todos os que están nesa saída, e non di nada sobre que persoa ou dispositivo hai detrás. Trátea como un filtro de entrada, non como autenticación.

Manteña independente das comprobacións a nivel de petición. Se a lista é o único entre un atacante e un punto final que cambia estado, unha ruta mal configurada, un cliente con split-tunnel ou un portátil prestado elimina o control por completo.

Rexiste tamén os rexeitamentos de fóra dos rangos esperados. Unha ráfaga deles é o sinal máis útil de que alguén está sondando o límite que acaba de construír, e o silencio é o sinal de que o filtro non se está alcanzando en absoluto.

Manteña explícitas as cookies, o inicio de sesión e a autorización

O alcance da cookie decide a maior parte do resultado. Unha cookie do dominio pai envíase ao host administrativo, así que unha inxección de script no sitio público pode actuar coa sesión dun administrador; unha cookie só de host non pode. Prefira a forma só de host, engada o atributo Secure e use o prefixo __Host- onde a plataforma o admita, porque ese prefixo esixe Secure, Path=/ e ningún atributo Domain. Lea a cabeceira de resposta en lugar do tarro de cookies: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, sen atributo Domain. O navegador descarta unha cookie __Host- que leve Domain, así que unha cookie que aínda aparece en hosts irmáns é proba de que o prefixo nunca se aplicou.

Despois manteña a autorización no servidor, por petición, en cada punto final administrativo, non só ao iniciar sesión. Unha petición dunha rede permitida aínda ten que autenticarse e autorizarse para a operación que pide; o nome de host non é un actor. Se as aplicacións pública e administrativa comparten un fluxo de inicio de sesión ou un almacén de sesións, escriba esa relación, porque é o camiño máis curto dun fallo no sitio público a unha acción administrativa.

Volva comprobar o límite tras a separación

Execute as probas negativas, non só o camiño feliz: un formulario entre sitios sen token debe rexeitarse, un token doutra sesión debe rexeitarse e ningún GET debe cambiar estado. Comprobe os atributos das cookies nas ferramentas de desenvolvemento, confirme que a comprobación de Origin salta nunha petición que non coincide e probe o host administrativo desde fóra do rango da VPN para ver o filtro en acción.

Nada disto elimina un fallo XSS dentro da propia aplicación administrativa. Un nome de host separado é un límite de illamento do lado do navegador con valor real, e non substitúe a prevención de execución de código inseguro nin a protección de peticións no servidor. Tras a separación a lista é máis curta do que parece: orixe distinta, cookies só de host, un token en cada mutación, un filtro de entrada no que non confía como identidade e autorización decidida por petición.