He visto artículos y publicaciones por todas partes (incluido SO) sobre este tema, y el comentario predominante es que la política del mismo origen impide que un formulario POST entre dominios. El único lugar donde he visto a alguien sugerir que la política del mismo origen no se aplica a las publicaciones de formularios es aquí .
Me gustaría recibir una respuesta de una fuente más "oficial" o formal. Por ejemplo, ¿alguien sabe el RFC que aborda cómo el mismo origen afecta o no a un formulario POST?
aclaración : no estoy preguntando si se puede construir y enviar un GET o POST a algún dominio. Estoy preguntando:
- si Chrome, IE o Firefox permitirán que el contenido del dominio 'Y' envíe una POST al dominio 'X'
- si el servidor que recibe la POST realmente verá algún valor de formulario. Digo esto porque la mayoría de los analistas de registros de discusión en línea dicen que el servidor recibió la publicación, pero los valores del formulario estaban vacíos / despojados.
- Qué documento oficial (es decir, RFC) explica cuál es el comportamiento esperado (independientemente de lo que los navegadores hayan implementado actualmente).
Por cierto, si el mismo origen no afecta a los POST de forma, entonces hace que sea algo más obvio por qué son necesarios los tokens antifalsificación. Digo "algo" porque parece demasiado fácil creer que un atacante podría simplemente emitir un HTTP GET para recuperar un formulario que contiene el token antifalsificación, y luego hacer un POST ilícito que contenga ese mismo token. Comentarios?
Respuestas:
La misma política de origen es aplicable solo para los lenguajes de programación del lado del navegador. Entonces, si intenta publicar en un servidor diferente al servidor de origen usando JavaScript, entonces entra en juego la misma política de origen, pero si publica directamente desde el formulario, es decir, la acción apunta a un servidor diferente como:
y no hay javascript involucrado en la publicación del formulario, entonces la misma política de origen no es aplicable.
Ver wikipedia para más información
fuente
Es posible crear una solicitud GET o POST arbitraria y enviarla a cualquier servidor accesible para un navegador de víctimas. Esto incluye dispositivos en su red local, como impresoras y enrutadores.
Hay muchas formas de construir un exploit CSRF. Se puede enviar un simple ataque CSRF basado en POST utilizando el
.submit()método. Los ataques más complejos, como los ataques CSRF de carga de archivos entre sitios , explotarán el uso de CORS del comportamiento xhr.withCredentals .CSRF no viola la Política del mismo origen para JavaScrip t porque el SOP se preocupa de que JavaScript lea la respuesta del servidor a una solicitud de un cliente. Los ataques CSRF no se preocupan por la respuesta, se preocupan por un efecto secundario o cambio de estado producido por la solicitud, como agregar un usuario administrativo o ejecutar código arbitrario en el servidor.
Asegúrese de que sus solicitudes estén protegidas utilizando uno de los métodos descritos en la Hoja de trucos de prevención CSRF de OWASP . Para obtener más información sobre CSRF, consulte la página de OWASP en CSRF .
fuente
La misma política de origen no tiene nada que ver con el envío de solicitud a otra url (protocolo diferente o dominio o puerto).
Se trata de restringir el acceso a los datos de respuesta (lectura) desde otra url. Por lo tanto, el código JavaScript dentro de una página puede publicar en un dominio arbitrario o enviar formularios dentro de esa página a cualquier lugar (a menos que el formulario esté en un iframe con una URL diferente).
Pero lo que hace que estas solicitudes POST sean ineficientes es que estas solicitudes carecen de tokens antiforgery, por lo que la otra url las ignora. Además, si el JavaScript intenta obtener esos tokens de seguridad, al enviar una solicitud AJAX a la URL de la víctima, la Política del mismo origen le impide acceder a esos datos.
Un buen ejemplo: aquí
Y una buena documentación de Mozilla: aquí
fuente