¿Por qué prohibir XSS en lugar de marcarlo?

Question

¿Por qué prohibir XSS en lugar de marcarlo?

#1 de Hendrik Brummermann (7 votos)
#2 de Mike Samuel (2 votos)

1

Considere un navegador que permita que un XMLHttpRequest descargado de foo.net realice solicitudes a bar.net, pero agregue un XHR-Origin: http://foo.net (o posiblemente un valor más descriptivo como http://foo.net/trustedapp.js ). El XHR no pudo tocar ese encabezado y el servidor pudo establecer reglas basadas en el origen del código de creación de instancias de XHR.

Dado que la especificación del W3C (aunque relajada con CORS) es más extrema que esto, ¿qué encontraron mal con esta técnica? ¿Qué vulnerabilidades existen que realmente requieren una prohibición XSS?

http xss javascript

pregunta Jordan 09.08.2012 - 06:14

fuente

2 respuestas

2

¿Qué vulnerabilidades existen que realmente requieren una prohibición de [Solicitud entre sitios]?

XHR implementado automáticamente lleva cookies con la solicitud. Esto significa que si el servidor asume que las solicitudes que tienen la cookie adecuada provienen de una página servida por sus servidores, son vulnerables a csrf (falsificación de solicitud entre sitios). Ya que XHR permite que el script de invocación inspeccione el resultado de manera programática de manera que las etiquetas <form> no lo hagan, XHR entre sitios permite explotaciones que rompen las suposiciones hechas por muchos escritores de servidores antes de que AJAX se haga conocido.

Debido a estas suposiciones anteriores, CORS y los mecanismos que compiten entre sí permiten que los sitios opten por el acceso programático a la API y el envío de credenciales.

respondido por el Mike Samuel 13.08.2012 - 17:11

fuente

Lea otras preguntas en las etiquetas http xss javascript

Limpiar completamente un disco duro (es decir, nada es recuperable) [duplicado] ¿Puede mi ISP saber mis contraseñas?

score 7 · Accepted Answer

Existen sitios web que no se actualizarán tan pronto como el primer navegador admita su propuesta. Esos sitios no verifican el encabezado XHR-Origin y, por lo tanto, son vulnerables.

Ejemplo de vulnerabilidad

Supongamos que ha iniciado sesión en su banco. Sin cerrar sesión, visita otro sitio web. Este sitio web envía una solicitud XHR a su banco para solicitar una respuesta JSON, que se utiliza en la vista del historial de la cuenta.

Sí, esta solicitud tendrá un encabezado XHR-Origin, pero si el software del banco no está ajustado, revelará datos confidenciales.

Por lo tanto, es responsabilidad del navegador no romper las restricciones SOP existentes.

¿Es CORS totalmente compatible con SOP?

La especificación CORS hace una serie de excepciones para las cuales no se requiere la verificación previa al chequeo. Se basan en situaciones en las que el SOP nunca se aplicó en el psat (por ejemplo, envío de formularios).

El problema en el borrador actual es que se basa únicamente en el encabezado Content-Type, pero las aplicaciones web tienden a ignorarlo.

Shreeraj Shah habló en Blackhat Europe 2012 sobre Top 10 amenazas de HTML5: ataques furtivos y ataques silenciosos