¿Cuáles son las implicaciones de riesgo de no verificar el encabezado del remitente en el formulario de inicio de sesión?

Un ataque CSRF intenta explotar "la confianza que un sitio tiene en el navegador de un usuario" (dice La página de Wikipedia, y está bien dicho). Se trata de que el servidor acepte una solicitud del cliente, en virtud de que la solicitud viene con alguna característica de autenticación que hace que el servidor crea que proviene del usuario genuino (lo que hace) y que está bajo el control consciente del usuario genuino (que Es falso). La "característica de autenticación" sería clásicamente un valor de cookie (aceptable para el servidor), o HTTPS con autenticación de cliente basada en certificados.

Para una página de inicio de sesión , el servidor no confía en la solicitud del cliente. Ese es el punto de una página de inicio de sesión: inicializar la confianza. La página de inicio de sesión espera un inicio de sesión y una contraseña precisamente porque no habrá nada con lo que pueda venir la solicitud, lo que hará que el servidor sea más feliz y lo distraiga de su acción prevista, que es verificar el par de inicio de sesión + contraseña. Como tal, los ataques CSRF no se aplican a esta página.

Aún puedes revisar el campo Referer para verificar "negocios maliciosos" (si está ausente o no está bien, entonces algo está definitivamente mal), pero realmente no cambiará la seguridad.

¿Cuál es la implicación de verificarlo? El encabezado del referente:

• puede ser falsificado por el cliente
• puede ser omitido completamente por el cliente (notoriamente cuando se pasa por TOR / proxies)
• no es garantía de que el usuario realmente vino de allí

El encabezado del remitente se envía como cortesía desde su navegador, no es un requisito HTTP RFC. Consulte aquí los detalles en el encabezado: enlace .

Por lo tanto, debería ser obvio que este encabezado no tiene ningún valor en absoluto, y no debe ser una garantía de nada . Además, cualquier persona lo suficientemente inteligente puede falsear esto. Si desea una garantía real de que los datos de su formulario de inicio de sesión provienen de su formulario de inicio de sesión, realice una comprobación que intente encontrar un valor único, generado aleatoriamente, basado en el usuario (o basado en el navegador). Esto será mucho más confiable (pero, dependiendo de la implementación, no necesariamente a prueba de balas) que un encabezado del Referer.

Para un formulario de inicio de sesión, no tanto. Lo más que podría suceder es que un sitio conocido como Facebook pueda ir malintencionado y usar las máquinas de sus clientes (a través de solicitudes POST desde un formulario incorporado activado por javascript) como parte de una entidad similar a una red de bots para aplicar fuerza bruta a su formulario de inicio de sesión.

Pero eso es bastante improbable, por lo que no hay problema con no verificar los referers al iniciar sesión.

Tenga en cuenta que el resto del sitio web, después de iniciar sesión, debe consultar a los remitentes en cualquier tipo de solicitud (GET o POST) con efectos secundarios. De lo contrario, podría crear un sitio que tenga un iframe incrustado con contenidos como:

<form method=post action="www.yoursite.com/makepayment.php">
<input type=hidden name="to" value="123453323">
<input type=hidden name="amount" value="$10000">
</form>

y JS activan el formulario, enviando una solicitud POST que transfiere dinero de usted a mí (o lo que sea).

Desea evitar eso, así que verifique los referentes allí .

Aún mejor, use un token CSRF (un token temporal que se adjunta a una cuenta específica por un pequeño período de tiempo) en un <input type=hidden> en cada formulario en la página que tiene efectos secundarios (es decir, no se carga simplemente una nueva página, pero también muta los datos almacenados en el servidor o en otro lugar)