¿Es suficiente una comprobación del servidor de encabezado X-Requested With para proteger contra un CSRF para una aplicación impulsada por ajax?

Question

Estoy trabajando en una aplicación completamente ajax impulsado por que todas las solicitudes pasan a través de lo que básicamente equivale a un controlador principal que, en sus huesos desnudos, se ve algo como esto:

if(strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') { 
    fetch($page); 
} 

¿Es esta generalmente suficiente para proteger contra falsificaciones de solicitudes entre sitios?

Es bastante inconveniente tener un token rotativo cuando no se actualiza toda la página con cada solicitud.

Supongo que podría pasar y actualizar el token único como una variable javascript global con cada solicitud, pero de alguna manera se siente torpe y parece intrínsecamente inseguro de todos modos.

EDITAR - Quizás un token estático, como el UUID del usuario, sería mejor que nada?

EDIT # 2 - Como The Rook señaló, esta podría ser una pregunta desgarradora. He leído especulaciones en ambos sentidos y escuché rumores lejanos sobre versiones anteriores de flash que pueden explotarse para este tipo de travesuras. Como no sé nada de eso, estoy ofreciendo una recompensa para cualquiera que pueda explicar cómo esto es un riesgo de CSRF. De lo contrario, lo estoy dando a Artefacto. Gracias.

Answer 1

Yo diría que es suficiente. Si se permitieran solicitudes entre dominios, estaría condenado de todos modos porque el atacante podría usar Javascript para obtener el token CSRF y usarlo en la solicitud falsificada.

Una ficha estática no es una gran idea. El token se debe generar al menos una vez por sesión.

EDIT2 Mike no tiene razón después de todo, lo siento. No había leído la página a la que me había vinculado correctamente. Dice:

Una petición en sitios cruzados simple es aquella que: [...] no establece encabezados personalizados con la petición HTTP (tal como X-Modificado, etc.)

Por lo tanto, si configura X-Requested-With, la solicitud debe realizarse previamente, y a menos que responda a la solicitud previa al vuelo OPTIONS que autoriza la solicitud entre sitios, no se realizará.

EDIT Mike tiene razón, a partir de Firefox 3.5, XMLHttpRequests entre sitios es permitted. En consecuencia, también debe verificar si el encabezado Origin, cuando existe, coincide con su sitio.

if (array_key_exists('HTTP_ORIGIN', $_SERVER)) { 
    if (preg_match('#^https?://myserver.com$#', $_SERVER['HTTP_ORIGIN']) 
     doStuff(); 
} 
elseif (array_key_exists('HTTP_X_REQUESTED_WITH', $_SERVER) && 
     (strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest')) 
    doStuff(); 

Answer 2

No creo que esto ofrezca ningún tipo de protección. Un sitio de ataque aún puede usar xmlhttprequest para su solicitud entre sitios eludir su verificación.

Answer 3

Respuesta corta: no. Cualquier atacante simplemente usaría Ajax para atacar su sitio web. Debe generar un token aleatorio con un tiempo de vida corto pero no demasiado largo que actualizaría durante cada solicitud de Ajax.

Debería usar una matriz de tokens en javascript ya que puede tener varias solicitudes ajax ejecutándose al mismo tiempo.

Answer 4

Lo que está haciendo es seguro porque xmlhttprequest generalmente no es vulnerable a la falsificación de solicitudes entre sitios.

ya que este es un problema en el cliente, la forma más segura sería la de comprobar la arquitectura de seguridad de cada navegador :-)

^{(Este es un resumen; Estoy añadiendo esta respuesta porque esta pregunta es muy confuso, veamos qué dicen los votos)}

Answer 5

No creo que esto sea seguro. Las mismas políticas de origen están diseñadas para evitar que los documentos de diferentes dominios accedan al contenido que se devuelve desde un dominio diferente. Esta es la razón por la cual los problemas XSRF existen en primer lugar. En general, a XSRF no le importa la respuesta. Se utiliza para ejecutar un tipo específico de solicitud, como una acción de eliminación. En la forma más simple, esto se puede hacer con una etiqueta IMG formateada correctamente. Su solución propuesta evitaría esta forma más simple, pero no protege a alguien de usar el objeto XMLHttp para realizar la solicitud. Debe usar las técnicas de prevención estándar para XSRF. Me gusta generar un número aleatorio en JavaScript y agregarlo a la cookie y una variable de formulario. Esto asegura que el código también puede escribir cookies para ese dominio. Si desea más información, consulte this entry.

Además, para evitar que los comentarios sobre XMLHttp no funcionen en el script. Usé el siguiente código con firefox 3.5 para hacer una solicitud a google desde html corriendo en el dominio localhost. El contenido no será devuelto, pero usando Firebug, puede ver que se realiza la solicitud.

<script> 
var xmlhttp = false; 

if (!xmlhttp && typeof XMLHttpRequest != 'undefined') { 
    try { 
     xmlhttp = new XMLHttpRequest(); 
    } catch (e) { 
     xmlhttp = false; 
    } 
} 
if (!xmlhttp && window.createRequest) { 
    try { 
     xmlhttp = window.createRequest(); 
    } catch (e) { 
     xmlhttp = false; 
    } 
} 

xmlhttp.open("GET", "http://www.google.com", true); 
xmlhttp.onreadystatechange = function() { 
    if (xmlhttp.readyState == 4) { 
     alert("Got Response"); 
     alert(xmlhttp.responseText) 
    } 
} 

xmlhttp.send(null) 
alert("test Complete"); 

Answer 6

Sí. Es un enfoque reconocido para la protección de CSRF.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Protecting_REST_Services:_Use_of_Custom_Request_Headers