¿Cómo se protegen contra ataques CSRF el envío de encabezados HTTP de referencia?

8

¿Cómo protege el envío de encabezados HTTP de referencia contra los ataques CSRF?

Intenté iniciar sesión en un sitio HTTPS con network.http.sendRefererHeader de Firefox establecido en 0 deshabilitado, como medida contra el seguimiento), y decía:

  

Prohibido (403)

     

Error en la verificación de CSRF. Solicitud abortada.

     

Está viendo este mensaje porque este sitio HTTPS requiere una   'Encabezado de referencia' que enviará su navegador web, pero no se envió ninguno.   Este encabezado es necesario por razones de seguridad, para garantizar que su   El navegador no está siendo secuestrado por terceros.

     

Si ha configurado su navegador para deshabilitar los encabezados "Referer",   por favor, vuelva a habilitarlos, al menos para este sitio, o para HTTPS   conexiones, o para solicitudes de 'mismo origen'.

¿Cómo evitaría esto los ataques CRSF? ¿No podría el atacante simplemente falsificar el encabezado del remitente, haciendo que se vea como uno que habría enviado?

    
pregunta Geremia 02.09.2016 - 00:48
fuente

2 respuestas

11

Para comprender esto, primero hay que entender qué es una falsificación de solicitud entre sitios.

Una falsificación de solicitud entre sitios es cuando el atacante tiene algún script o medio incrustado en un sitio web que controla, lo que hace que cualquier visitante a ese sitio solicite un recurso de un sitio diferente. Esa solicitud aparece ante ese otro sitio en el contexto del usuario. Podría, por ejemplo, agregar una imagen con la url https://othersite.example.com/delete_my_account.php?really=true a mi sitio web. Cuando visite mi sitio y haya iniciado sesión en su cuenta en othersite.example.com , su navegador solicitará esa URL, lo que causaría que othersite.example.com elimine su cuenta.

Pero hay un problema: cuando othersite.example.com puede leer su referencia, puede ver que esta solicitud es causada por alguien que interactúa con un sitio diferente. No hay una buena razón por la que un sitio web tenga un vínculo profundo a una URL que realice una acción. Cuando el otro sitio rechaza las solicitudes sin un referente, ese ataque se vuelve imposible.

Con respecto a la falsificación de referencias: tenga en cuenta que el cliente que realiza la solicitud no es el atacante. El atacante es un operador de sitio web. Lo peor que puede hacer el operador es hacer que su navegador web ejecute Javascript en el contexto de su sitio web. Si bien hay varias formas de realizar solicitudes a otros sitios web utilizando Javascript, ninguna de esas API permite falsificar el referente.

    
respondido por el Philipp 02.09.2016 - 01:05
fuente
7
  

¿No pudo el atacante simplemente falsificar el encabezado del remitente?

No, no pueden.

Obviamente, no es posible al enviar un formulario (o los diversos métodos GET, como etiquetas de imagen o URL en CSS), y tampoco es posible a través de XMLHttpRequest, según documentación .

Dicho esto, sugeriría usar un token en su lugar, ya que la verificación del referer puede omitirse si existe una vulnerabilidad de redireccionamiento abierto y la aplicación no tiene un estado de reposo, o si permite una baja a GET y contiene vulnerabilidades de redireccionamiento abiertas Vulnerabilidades de inyección de HTML, o vulnerabilidades de inyección de CSS. También puede causar problemas de uso (como en su caso).

    
respondido por el tim 02.09.2016 - 01:03
fuente

Lea otras preguntas en las etiquetas