Estoy leyendo sobre Subsource Integrity en Mozilla [1] . Analizan el fragmento de código a continuación y escriben lo siguiente al respecto:
El valor anónimo significa que el navegador debe omitir cualquier cookie o autenticación que el usuario pueda tener asociada al dominio. Esto evita fugas de datos de origen cruzado y también hace que la solicitud sea más pequeña.
<script src="https://code.jquery.com/jquery-2.1.4.min.js" integrity="sha384-R4/ztc4ZlRqWjqIuvf6RX5yb/v90qNGx6fS48N0tRxiGkqveZETq72KgDVJCp2TC" crossorigin="anonymous"></script>Me interesa saber por qué esto evita las fugas de datos de origen cruzado [2] . Mozilla escribe lo siguiente:
Los atacantes intentarían cargar el recurso con un resumen conocido y observar las fallas de carga. Si la carga falla, el atacante podría suponer que la respuesta no coincidió con el hash y, por lo tanto, obtener una idea de su contenido. Esto podría revelar, por ejemplo, si un usuario ha iniciado sesión o no en un servicio en particular.
Entiendo cómo se puede usar el atributo de integrity para revelar el contenido del recurso. Esto parece interesante si los contenidos dependen del cliente. Sin embargo, no entiendo dos cosas:
responseText a un sitio web malicioso de inmediato?crossorigin en anonymous para que los piratas informáticos no puedan "forzar brutamente" la información de la página mediante hashes de fuerza bruta. Si los piratas informáticos pueden controlar el atributo de integrity en la página, también pueden controlar el atributo de crossorigin en la mayoría de los casos, entonces, ¿por qué es importante?La situación que describes es diferente a la que tenían en mente los autores de esa documentación. Es posible que el atacante no esté interesado en el contenido exacto de la respuesta a una solicitud autenticada desencadenada por una carga de subrecurso; en cambio, el atacante puede simplemente querer determinar, desde un origen malicioso, si la víctima ha iniciado sesión en el objetivo.
Imagine un caso en el que la respuesta a GET ting https://example.com/1.js depende de si la solicitud lleva alguna cookie de autenticación (marcada como SameSite=None; Secure here, para simplificar):
alert('authenticated');o
alert('anonymous'); El SHA-256 de alert('anonymous'); (seguido de una nueva línea) es a7c873e2f388c05f57d1245cfa0c20e4bf5b064677ba4f959c5dd53668590339 . El atacante podría configurar la siguiente página maliciosa, que funcionaría como un oráculo de inicio de sesión:
<script integrity="sha256-a7c873e2f388c05f57d1245cfa0c20e4bf5b064677ba4f959c5dd53668590339" src="https://example.com/1.js" crossorigin="use-credentials" onerror="notifyAttackerVisitorIsLoggedInToExampleDotCom();">Cuando la víctima visita la página maliciosa del atacante, son posibles dos casos:
https://example.com , la respuesta a la carga del subrecurso contiene alert('anonymous'); , cuyo valor hash coincide con el especificado en el atributo de integrity del atacante. No se produce ningún error.https://example.com , la respuesta a la carga del subrecurso contiene alert('authenticated'); , cuyo valor hash no coincide con el especificado en el atributo de integrity del atacante. Por lo tanto, se produce un error y se activa el detector de eventos onerror , notificando al atacante.