No hay razón para que esto no funcione siempre que las cookies de terceros estén habilitadas en su navegador.
Se pueden usar los POST de formulario HTML, o en el caso de que los formularios sean un proceso de múltiples etapas, esto será más útil para ejecutar como solicitudes XHR, ya que su página de ataque puede controlar las solicitudes y emitirlas a su vez, solo como tu estas haciendo.
Asegúrese de que está configurando withCredentials en sus solicitudes de AJAX.
En jQuery esto se hace de la siguiente manera
$.ajax({
type: "POST",
url: 'http://www.example.com/Controller/Action',
data: 'foo=bar',
async: true,
xhrFields: {
withCredentials: true
}
});
Otras respuestas sugieren que usar withCredentials significa que una CORS se envía una solicitud antes del vuelo a la recurso en lugar del GET o POST previsto. Este no es el caso siempre que la solicitud sea una "solicitud simple". Si su exploit trabajó con formularios HTML, entonces el equivalente correcto de AJAX sería una simple solicitud, así que verifique que todo su código sea correcto.
Las solicitudes de origen cruzado vienen en dos tipos:
- solicitudes simples
- "solicitudes no tan simples" (un término que acabo de inventar)
Las solicitudes simples son solicitudes que cumplen con los siguientes criterios:
Las solicitudes simples se caracterizan como tales porque ya se pueden realizar desde un navegador sin usar CORS.
Esto se menciona en realidad en la especificación de CORS e indica que CORS no agrega seguridad, solo habilita la cruz -dominio de la comunicación cuando tanto el cliente como el servidor optan por la especificación. Si ambas partes no se inscriben (como en un ataque CSRF en el que el sitio de la víctima no desea ser comunicado de esta manera), el navegador actuará de manera similar a pre-CORS. es decir, se enviarán cookies aunque la respuesta no será legible:
los recursos que se ajustan a esta especificación siempre deben estar preparados para esperar solicitudes de origen cruzado simples con credenciales. Debido a esto, los recursos para los cuales las solicitudes simples tienen un significado distinto al de la recuperación deben protegerse de la falsificación de solicitudes entre sitios (CSRF) al exigir la inclusión de un token indiscutible en el contenido de la solicitud proporcionado de forma explícita.
Vuelve a tu pregunta:
Comparé las solicitudes HTTP reales tanto para el contenido como para el pedido: todas las coincidencias de datos de la capa de aplicación.
Le sugiero que utilice un proxy de interceptación como Burp o Fiddler2 para verificar las solicitudes. La verificación de las solicitudes desde el interior del navegador no es una forma precisa de verificar esto porque las solicitudes que se ven en Chrome están sujetas a la interpretación del Origen de la página desde la que se emiten y si el Origen no ve la respuesta debida a la misma Política de origen, entonces tampoco lo harás en herramientas de desarrollo. Chrome te informa de esto a través del mensaje “CAUTION: provisional headers are shown” .
Por ejemplo, la siguiente es la misma solicitud que se muestra en las herramientas de desarrollo de Chrome y luego en Burp. Observe que solo la herramienta externa muestra las cookies.
He probado este comportamiento con Chrome 38, Firefox 32 e Internet Explorer 11 en Windows 7 x64, y es consistente en todos los navegadores (sin embargo, asegúrese de que las cookies de terceros estén habilitadas en la configuración), por lo que esto es una indicación más de que esto El comportamiento cumple con las normas actuales.
Por lo tanto, mi consejo es que compruebe dos veces su código y las solicitudes utilizando un proxy interceptor. Tal vez los publique aquí para que otro par de ojos compruebe que está funcionando de una manera pero no la otra, entonces debe haber un error en alguna parte porque las solicitudes no serán las mismas.
Además, asegúrese de que su código no salga antes debido al error devuelto debido a la violación de la Política del mismo origen.