Publicación de formulario de dominio cruzado

145

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?

— Brent Arias
fuente

Sí, un atacante podría hacer eso ... con un navegador web común.

— Michael Hampton

Quizás no haya RFC por la misma razón por la que no hay RFC que digan: "no publique su contraseña en su sitio web". Los estándares web solo se requieren cuando varias partes deben trabajar juntas para lograr algo: la misma política de origen es más un conjunto complejo de "mejores prácticas de seguridad" que evitan que los usuarios sean pirateados.

— Ciro Santilli 郝海东冠状病六四事件法轮功

@Ciro Dígalo explícitamente. Las reglas para la publicación cruzada en otros sitios no afectan a múltiples partes. No es necesario el lenguaje brumoso.

— Little Alien

Respuestas:

175

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:

<form action="http://someotherserver.com">

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

— Suresh Kumar
fuente

Lamento arrastrar una vieja pregunta, ¿qué pasaría si la acción se cambiara usando JS pero luego el formulario se publicara usando un botón? ¿Eso permitiría una publicación exitosa entre dominios?

— Chris

AFAIK no debería ser un problema, pero no lo he intentado yo mismo. Sería interesante descubrirlo.

— Suresh Kumar

Soy del mismo pensamiento. De hecho, me preocupaba la seguridad, algunos JS / virus de terceros cambiaron la acción para publicar el formulario en algún lugar malicioso, pero me di cuenta de que esto se podía hacer en cualquier formulario de pago que recibiera un dominio cruzado o no y el resultado sería el mismo. Lección aquí realmente: verifique los archivos JS de terceros;)

— Chris

En resumen: SÍ, se permite la POST entre dominios.

— Christian Davén

-1 para: La misma política de origen no tiene nada que ver con el envío de solicitudes a otra url (protocolo diferente o dominio o puerto), se trata de restringir el acceso a los datos de respuesta (lectura) desde otra url (y, por lo tanto, evitar que javascript actualice el documento con formularios que tienen tokens de seguridad de otra url).

— Mohsenme

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 .

— Mikey
fuente

He actualizado mi pregunta para aclarar. Además, el enlace de WordPress que proporcionó involucra exploits que se iniciaron desde dentro del mismo origen X, en lugar de iniciarse desde el dominio cruzado Y ... por lo que no es el escenario correcto por lo que veo.

— Brent Arias

@Brent Arias sí, lo que está describiendo en 1 y 2 es exactamente igual a lo que realiza un ataque CSRF, tal vez debería intentar ejecutar uno de los exploits CSRF proporcionados y detectar el tráfico. He actualizado mi publicación, debe leer todos los enlaces proporcionados porque responderá estas preguntas con precisión. El punto de un ataque de "falsificación de solicitudes entre sitios" (CSRF) es que la solicitud se origina en otro dominio, todos los exploits proporcionados cumplen completamente este requisito fundamental.

— Mikey

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í

— Mohsenme
fuente