security - ejemplo - jsonpcallback
La mejor opción a largo plazo: JSONP vs EasyXDM (1)
¿Cuál es la mejor opción a largo plazo entre JSONP y EasyXDM para permitir que un dominio en http pueda comunicarse con el mismo dominio en https (protocolo cruzado)?
Por ejemplo, me gustaría que http://mywebsite.com se comunique con https://mywebsite.com porque la cookie de sesión solo supera https. Me gustaría mostrar un nombre de usuario en el sitio web http sin tener que transferir esos datos a través de http.
EasyXDM me está asustando con el lanzamiento de seguridad y JSONP no está muy claro sobre las precauciones de seguridad.
Descargo de responsabilidad: soy el autor principal de easyXDM .
En realidad, no es fácil responder esto directamente, ya que hay muchas cosas que considerar.
Primero, comparemos easyXDM y JSONP fuera del alcance de la pregunta.
JSONP permite un programa del lado del cliente (Javascript usando el BOM / DOM) para interactuar con un programa del lado del servidor (.net, php, etc. usando db''s, almacenamiento de sesión, etc.), y solo el cliente puede iniciar la mensajería (solicitud / respuesta, sondeo, o push, aunque para push puede configurar fácilmente un IMG.src, hacer un XHR o una publicación de FORMATO ya que no necesita una respuesta).
El cliente está limitado en la cantidad de datos que puede enviar al servidor, y estos datos también deben formatearse para ajustarse como un parámetro de cadena de consulta, y el servidor debe estar configurado para responder a dichos datos. Para cada mensaje se ejecuta un viaje de red con el costo que esto implica.
easyXDM facilita la mensajería entre dos programas del lado del cliente que utilizan una pila de transporte basada en cadenas. No es necesario que haya ningún programa del lado del servidor involucrado, y no hay tráfico de red. Los dos lados son iguales y pueden iniciar mensajes, y ambos pueden mantener el estado en el cliente (de ahí el término programas en lugar de Javascript simple). Los mensajes no tienen un tamaño limitado y, siempre que los datos se puedan serializar en una cadena, el transporte puede manejarlos (easyXDM le permite configurar un serializador personalizado o usar JSON).
La diferencia principal entre estos dos es que uno se encuentra entre un cliente y un servidor donde solo el cliente puede iniciar la mensajería, y que el otro se encuentra entre dos programas de cliente iguales, donde cualquiera puede usar XHR y otros medios para comunicarse o retransmitir datos a un servidor.
En cuanto a la seguridad; JSONP exige que el cliente confíe absolutamente en el servidor, después de todo, le permite ejecutar código arbitrario en su programa. Aparte de esto, hay algunos problemas, pero este es grave.
Con easyXDM, solo se transmite información (la cadena) y no se transmite ningún código, y depende del receptor inspeccionar la información y actuar sobre ella. Por lo tanto, no hay ningún riesgo de ejecución de código arbitrario . Si bien lo anterior es cierto, algunos de los componentes en los que se basó easyXDM para establecer el canal eran vulnerables a XSS (una url especialmente diseñada provocaría que el cliente ejecutara código arbitrario), pero estos se han cerrado. En la actualidad, no se conocen dichas vulnerabilidades, y todos los códigos nuevos se examinan minuciosamente.
Yo mismo uso easyXDM para algunos proyectos exigentes, y sitios como LinkedIn, Twitter y Disqus , así como aplicaciones ejecutadas por Nokia y otros, han construido sus aplicaciones sobre el marco de mensajería provisto por easyXDM, por lo que hay muchas personas que han pasado por alto. el código y lo verificó, y quién a través de su uso avala su seguridad.
Al final, se trata realmente del caso de uso. Por ejemplo, JSONP no se puede usar para cambiar el tamaño de una ventana entre dominios, ya que eso requiere comunicación entre el cliente y el cliente . Pero easyXDM se puede usar tanto para cliente / cliente como para cliente / servidor haciendo que una de las partes use XHR.
En su caso, ninguno de estos es realmente necesario si solo necesita hacer que una pequeña información esté disponible en el dominio no seguro.
- Navega por el dominio seguro, configura una cookie en la no segura
- Navega por el dominio seguro, haz que redirija a la información de paso insegura en su solicitud
- Navegue a través del dominio seguro, haga que almacene datos en window.name antes de redirigir a los inseguros.
Si es vital que la información no se pueda falsificar, entonces usted debe firmar los datos para que se pueda confirmar su autenticidad, pero si todo lo que necesita es un nombre, entonces esto debería ser innecesario.
Una manera simple de verificar la autenticidad es
- En el dominio no seguro, genere un secreto al azar y almacénelo, y redirija al dominio inseguro que pasa el secreto.
- En el dominio seguro, devuelva el secreto junto con la información (utilizando cualquiera de los medios descritos anteriormente)
- en el cliente, verifique que la información contenga el secreto.
Como solo las dos partes podrían tener el secreto, la información se verifica.
Para concluir , realmente no hay una respuesta definitiva, todo depende de la situación. Así que elige, pero elige sabiamente :)