¿Puedo hacer un formulario desde otro sitio web

Question

Tengo un usuario en el sitio web A y necesito iniciar sesión en el sitio web B (no bajo mi control) pero sin poner en peligro su contraseña en el sitio web B. El sitio web B no tiene una API que es lo que hace que esto sea más complicado de lo que debería ser.

Mi primera opción es hacer mi propio formulario en el sitio web A, el usuario ingresa su contraseña B en mi formulario, y de alguna manera transfiero su contraseña al sitio web B para registrarlo. Esto significa que tengo que primero pasar la contraseña de forma segura desde el cliente a mi servidor, luego pasarla de nuevo de forma segura desde mi servidor al sitio web final. Eso es lo que supongo que tengo que hacer, pero no tengo un plan sobre cómo implementar estos 2 saltos de forma segura, así que me preocupa que pueda exponer la contraseña del usuario de alguna manera.

Así que pensé en la segunda opción, que es presentar el mismo sitio web B desde el sitio web B en mi sitio web. Pero el formulario en el sitio web B es parte de una página más grande, ¿así que se puede hacer esto?

• ¿cómo iba a aislar el código de la forma misma del código de la página completa
• la forma de presentar el formulario en mi sitio web. Quiero que el usuario lo vea iframe viene a la mente, pero nunca trabajó con él
• se forma todavía ser válido cuando el usuario hace clic en el botón de enviar o no prestar la forma en mi sitio web de alguna manera invalida

Estas son las 2 soluciones diferentes que pensé de. Doy la bienvenida a las respuestas para cada uno de ellos, y también recibo respuestas que sugieren un tercer enfoque alternativo que puede ser más fácil.

Answer 1

Para aislar el formulario de la página más grande, busque las etiquetas <form> y </form>, y copie solo elementos y elementos entre ellas. Ahora ponga ese formulario en su página, con su acción aún apuntando a la URL a la que apuntaba en el sitio web original. La contraseña nunca pasa por tu servidor.

Answer 2

No estoy realmente conseguir lo que quiere hacer, si se acaba de sesión en el sitio que tal vez puede hacer algo como esto:
Mainsite:

<iframe id="logon" src="/logonto-other.html"></iframe> 

/logonto-otro .html:

<form onsubmit="top.logon.style.visibility='none';" action="http://other-site.com/login" method="post"> 
    <dl> 
    <dt><label for="user">Name</label></dt> 
     <dd><input name="user" /> 
    <dt><label for="pass">Password</label></dt> 
     <dd><input name="pass" /> 
    </dl> 
    <?php //code that acquires hash from other site 
    // Don't know site B so can't write this one yet. 
    ?> 
    <input type="submit" value="Login" /> 
</form> 

De esta manera el usuario sólo se registra en el otro sitio, su capacidad de interacción con todavía estarían limitados (o sh Creo que nunca aprendí las mismas políticas de origen ya que nunca he sentido que haya alguna restricción a lo que hago. Tal vez los navegadores de hoy son más estrictos).

Acerca de lo de "2 saltos", ¿tiene un certificado y soporte SSL/HTTPS en su servidor A? ¿El servidor B tiene esto? ¿Crees que puedes hacer que los usuarios confíen en ti al tener su contraseña? Un consejo sería que agregue un párrafo explicando la situación y un enlace allí; el usuario puede contactar al sitio B para agregar presión sobre ellos para implementar OAuth y/o OpenID.

Es posible encontrar algo muy bien, incluso si no tiene HTTPS en su servidor, puede usar JavaScript o un applet de Java para cifrar la contraseña (tiene que haber PGP en JavaScript en algún lugar de la red. Aunque, si la barra de direcciones de los navegadores se pone verde, los usuarios tienen una decisión más fácil si confían o no en usted.

Me gustaría recibir algunas respuestas a mis preguntas, y ¿se nos puede permitir saber qué es el Sitio B? Y qué es exactamente lo que intentas hacer, tal vez podamos resolver esto juntos.

Le deseamos buena suerte.

Answer 3

Siempre que utilice SSL en su sitio, no hay un riesgo significativo en términos de comprometer la contraseña del usuario (a menos que esté haciendo transacciones financieras de algún tipo, entonces aclare).

Mi sugerencia sería, no copie su formulario. En su lugar, replique el HTTP POST generado por ese formulario. Puede hacer esto completamente mediante programación y el usuario nunca abandonará SU sitio, pero (en la mayoría de los casos) el resultado será que el usuario también ha iniciado sesión en SU ​​sitio.

Si hay algún tipo de campos hash de tratar, solicitar su página de formulario (mediante programación) y el uso de los valores que se reciben para enviar de vuelta al segundo sitio para que la solicitud validará. Su servidor no sabe que la solicitud no proviene de un navegador (de hecho, puede agregar un agente de usuario a los encabezados HTTP si lo desea).

He utilizado esta metodología contra el sitio de Verizon y LinkedIn (ambos para fines legítimos) y funciona.

Para recapitular:

1. Conocer la estructura de su HTTP POST.

2. Agregue un formulario de inicio de sesión a SU sitio.

3. Manipule la solicitud en su código para que parezca el POST que su sitio espera.

4. POST a su sitio desde su código.

5. Muestra la respuesta al usuario en tu sitio (si es necesario), redirige, lo que sea.

Answer 4

Todo depende de cómo el servidor hay demasiados temas que maneja CSRF [Cross-Site Request falsificaciones], ya que es básicamente lo que está haciendo. Si están utilizando un Django que es relativamente reciente, por ejemplo, las solicitudes POST desde un servidor externo fallarán de manera predeterminada, a menos que contengan el valor de la cookie csrf.

Es posible evitar esto, si también tiene el control del servidor al que está efectuando la PUESTA EN CORREO.

Answer 5

Voy a tratar de delinear una solución, pero puede no ser correcta, o incluso lo que quería y definitivamente no es práctico.

Por lo que sé sobre XSRF si el sitio de destino hizo su tarea, no podrá imitar un formulario enviado desde su dominio.

El único que tiene acceso a las credenciales de usuario, además del sitio de destino, es el navegador. Entonces, lo que realmente necesita hacer es convertirse en un navegador. Esto significa que debe convencer al usuario de que puede darle su información de inicio de sesión al otro sitio. No tengo idea de cómo puedes hacer eso, por mi parte, no confiaría en algo así. (Otra opción sería engañarlo (phishing), pero eso es ilegal y no creo que siquiera lo considere.)

Una vez que logra convencer al usuario de que le proporcione sus datos, igual tendrá que actuar como un navegador. Tendrá que implementar un sistema para almacenar cookies para cada usuario para que pueda crear una sesión cuando inicie sesión.

Después de hacerlo, iniciará sesión con los datos del usuario, pero el usuario no lo hará ser. Por lo tanto, deberá implementar cualquier otra operación que el usuario necesite a través de su sitio también.

---

lo que recomiendo:

De cualquier contacto con el sitio de destino y establecer un protocolo que se puede utilizar para autenticar al usuario de su sitio. Hay algunas técnicas de iframe realmente geniales para hacer eso. Lea este artículo para una presentación competente http://softwareas.com/cross-domain-communication-with-iframes.

O haga que el usuario abra una ventana emergente con la página de inicio de sesión a ese sitio. Asegúrese de que la ventana emergente tenga la barra de direcciones visible.

Answer 6

Ver: formulario de acceso HTML de Sockets

1. Estudio SitioB para recopilar una lista de nombres de campo, los valores esperados y url acción.
2. Rehaga el formulario en su propio sitio, utilizando los mismos nombres de campo. La url de acción debe apuntar a un script de manejo en su propio servidor. Una advertencia en este punto es si el Sitio B usa algún campo de token especial o conjunto de cookies cuando se carga su página de formulario de inicio de sesión. Si ese es el caso, use conectores para conectarse y obtener una nueva copia de la página de inicio de sesión del Sitio B. Necesitarás saber HTTP message standards and proper request body structure para lograr esto. Luego, analice el texto recuperado para el campo del token o los nombres y valores de las cookies para usar en su propia página.
3. El usuario ingresa su nombre de usuario y contraseña para el Sitio B en su formulario. En el envío, los resultados del formulario se pasan a su secuencia de comandos del controlador.
4. Su secuencia de comandos del manejador usa Sockets para conectarse al objetivo de la url de acción del Sitio B como una solicitud POST normal. Esta solicitud POST incluye las cookies y los nombres/valores de tokens que el Sitio B le dio en los pasos anteriores. Deberá seguir las pautas de la estructura de mensajes del protocolo HTTP nuevamente para lograr esto.
5. El sitio B autentica usando la información de su usuario. La secuencia de comandos del controlador está allí esperando una respuesta.
6. El sitio B responde al script del controlador. Deberá estudiar las respuestas típicas. El sitio B regresa para saber cómo analizar cualquier texto de respuesta (y nuevamente aprender a analizar los mensajes HTTP), incluidos los encabezados de cookies devueltos.
7. La secuencia de comandos de su manejador debe mantener un registro en algún lugar que coincida con los valores de las cookies devueltos después de la autenticación exitosa por el sitio B. En cualquier solicitud futura al sitio B, use sockets nuevamente como usuario, pasando la cabecera de la cookie/val utiliza para su identificación (IE: su) sesión de inicio de sesión para el sitio B.

Tenga en cuenta que puede que desee mantener un diálogo abierto y honesto acerca de lo que está haciendo con el sitio B, o podría ser liable for civil action.

Answer 7

El escenario que está describiendo puede ser engañoso o imposible. El principal problema al que se enfrenta es cómo publica las credenciales de inicio de sesión en el sitio B de manera que las cookies devueltas por el inicio de sesión exitoso acaben en el navegador del usuario y pertenezcan al sitio B, de modo que el sitio B las obtenga cuando el el usuario realmente navega allí.

Un par de personas han sugerido que se publique el formulario en un archivo PHP en su servidor y permitan que se inicie sesión de servidor a servidor. Esta solución casi nunca funciona. Incluso si el sitio B acepta su inicio de sesión servidor-servidor (que probablemente lo hará, ya que puede falsificar cualquier navegador que desee), será su servidor web que recibirá las nuevas cookies, y su IP de servidor web que la sesión se asociará con. Incluso si devuelve la cookie al navegador, la guardará para su sitio (sitio A) y no la enviará al sitio B cuando llegue el navegador, por lo que el usuario permanecerá desconectado del sitio B.

Por lo tanto, lo único que puede hacer aquí es alojar un formulario de inicio de sesión para su sitio en su servidor. Esto significa que tendrá que enviar un formulario al navegador que tiene una ACCIÓN que apunta al formulario de inicio de sesión del sitio B. Esto también significa que cada vez que el usuario hace clic en el botón de inicio de sesión, el control se transfiere al sitio B: el usuario estará navegando fuera de su sitio y usted lo pierde.

Hay dos problemas técnicos importantes con este segundo método: uno es que el sitio B podría tener la prevención XSS y en realidad puede impedirle publicar cosas en su página de inicio de sesión. El otro problema es que si su sitio está en SSL, los navegadores serán una gran molestia para que envíe un formulario a un sitio web diferente. Ninguno de estos es algo que puede resolver usted mismo.

La única solución limpia sería sentarse realmente con el sitio B y hacer algún plan sobre una autenticación común, o al menos una API de autenticación. Puedes probar la solución de crossposting de formularios, pero es probable que tengas problemas que no te gusten.