Todos los orificios de bucle lógico en esta idea para la prevención de Cross Site Request falsificación?

Question

He leído varias soluciones XSRF que se basan en la adición de más fichas a la respuesta, que no ayudan a proteger el código que sólo funciona en la POST.

es decir. esto sería un ataque de un paso depender de una página que responde a HTTP GET

<img src="http://amazon.com/buybook/anarchistscookbook/mailto/me/execute.php">

Pero con mejores librerías como jQuery, su cada vez más fácil de escribir guiones XMLHTTPRequest código JavaScript malicioso, que puede hacer un ataque de dos pasos (un GET, analizar el anti-XSRF estado de vista / cadena de consulta / etc galletas extra) y luego presentar un POST . (O es? No me preocupo por AES sido descodificada en el corto plazo, debería siquiera preocuparse de 2 ataques XSRF paso de orientación acciones POST HTTP llegar a ser tan fácil como el ataque etiqueta img muestra arriba?)

supongo que el ataque de un paso en su mayoría se puede tharted por no hacer nada Sensive en GET, podrían ambos tipos de ataques pueden tharted al requerir que el usuario del sitio web para resolver un CAPTCHA de, que luego yeilds un token de cadena de consulta que lo haría se requiere para todas las direcciones URL para el resto de la sesión?

Hasta el momento parece que sólo no cuando CAPTCHA de falla, por ejemplo, si el software de OCR puede leer el texto o si hay un componente Mechanical Turk.

EDIT: El ataque en particular en mente es un correo electrónico con xhr javascript o la imagen de la etiqueta. Por lo que el código se ejecuta en el navegador del cliente de correo electrónico o desde una página HTML cargada desde el sistema de archivos local. Por el bien de simplicidad, me estoy imaginando el sitio no tiene vulnerabilties XSS (es decir. No hay oportunidades para los usuarios maliciosos para inyectan su HTML en el HTML del sitio envía como respuestas)

Answer 1

El punto es que JavaScript no puede leer el contador anti-XSRF de un contexto de dominios cruzados, y XMLHTTPRequest es del mismo origen solamente, por lo que no se puede utilizar para robar el token.

Si su sitio ya tiene una vulnerabilidad XSS, que ya está regado y fichas anti-XSRF no le ayudará.

Answer 2

Ni XmlHttpRequests ni javascript marco de trabajo manipulación multidominio en estos días; eso sería pura locura. CSRF ataca en estos días suelen consistir ya sea de la etiqueta de la imagen como usted ha mencionado o autogenerating una forma de que los puestos a otro sitio. Sin embargo, la recuperación de un token anti-XSRF (presumiblemente un nonce criptográfica generada en una base por sesión) es casi imposible. Sólo si se trata de un token extremadamente pobre que no comprueba la sesión del usuario y la dirección IP podrían un lenguaje de servidor, posiblemente, pueden aprovechar para recuperarlo y luego combinarlo con un CSRF del lado del cliente. Aparte de fichas, mucha gente deja de CSRF simplemente comprobando los remitentes y el bloqueo de todos los dominios remotos. La presentación de CSRF con XmlHttpRequests es prácticamente imposible gracias a las restricciones de dominio.

En cualquier caso, usted no tiene que preocuparse por XmlHttpRequest poder acceder a un dominio remoto. La única vez que algo así podría suceder es si usted tiene una vulnerabilidad XSS, en cuyo caso, como dijo EricLaw, ya que está regado.

Answer 3

Creo que está confundido acerca de la política del mismo origen. Solicitando una página HTML que se encuentra en un archivo local no elude esta política. De hecho, CREO incluso normas más estrictas se aplican a un recurso de archivo. Usted encontrará que el Javascript en un archivo HTML local no será capaz de hacer una solicitud exitosa es posible recuperar un recurso no local.

  

Los navegadores modernos no permiten Javascript   en archivos HTML locales tengan acceso a distancia   recursos HTTP.

En el explorador que has sido capaz de realizar con éxito un XHR entre dominios desde un archivo: /// recursos

He probado esto en IE6, IE7, IE8, Firefox 3, Firefox 3.5 y versiones recientes de Chrome, Opera y Safari en las ventanas; todos ellos rechazan la petición HTTP entre dominios.

<html>
<head>
<script 
  type="text/javascript" 
  src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
<script type="text/javascript">
  $(document).ready(function() {
    $( '#xhr' ).append( 'replace me with remote xhr' );
    $( '#xhr' ).load( 'http://stackoverflow.com/', function() {
      $( '#xhr' ).append( 'xhr load complete' );        
    });
  });
</script>
</head>
<body>
  test
  <div id="xhr">original</div>
</body>
</html>

Es posible que algunos navegadores mucho más antiguas son menos restrictivas.