¿JSONP es seguro de usar?

Question

¿Hay algún problema de seguridad que deba tenerse en cuenta al usar JSONP?

Answer 1

Actualización: JSONP es un truco común para hacer solicitudes entre dominios. Los navegadores modernos ahora tienen Cross Origin Resource Sharing, e IE8 + tienen XDomainRequest que es similar. Ver http://enable-cors.org/ para más información.

JSONP es solo una secuencia de comandos que le permite usar una devolución de llamada. Sin embargo, debe tener en cuenta Cross-site request forgery (CSRF).

Mientras controle la secuencia de comandos y el servidor, JSONP ya no es inseguro como lo es un script. A menos que tenga un servicio JSONP que devuelva datos confidenciales a los usuarios que hayan iniciado sesión. Un sitio malicioso puede enviar una solicitud al servicio (con la esperanza de que el usuario inicie sesión en su sitio) y recuperar los datos. El servicio puede verificar la referencia de la solicitud, pero es posible falsificar la referencia utilizando flash (gracias a Chris Moschini).

Imagine este senario: - Un usuario inicia sesión en su cuenta de banca por Internet. Almacenar una cookie de sesión en el navegador de los usuarios. Este sitio tiene un servicio jsonp con información confidencial sobre el usuario y sus cuentas. - Otros sitios no sabrán que el usuario ha iniciado sesión, pero podrían hacer una gran conjetura e intentar acceder al servicio jsonp. Como el usuario tiene una cookie de sesión, el navegador obtendrá una respuesta, y no hay nada que impida que el sitio haga una publicación ajax para guardar los datos confidenciales en su servidor.

actualización 28va de junio de 2012: Si desea proteger contra CSRF ataques debe leer esto en profundidad entrada del blog por un experto en seguridad: http://erlend.oftedal.no/blog/?blogid=130

Answer 2

Sí, es necesario tener cuidado, pero cuando se utiliza correctamente con servicios confiables es relativamente seguro.

He aquí un resumen de los problemas de seguridad con JSONP, como yo lo entiendo:

Desde la perspectiva del consumidor:

• Usted debe confiar en el proveedor de no volver JavaScript malicioso en lugar de la JSON esperado envuelta en la devolución de llamada JSONP que especifique.
• Lo mismo ocurre con los complementos incrustados de JavaScript de terceros, como Google Analytics.
• Es solo similar a los ataques XSS ya que le permite a un tercero ejecutar JavaScript arbitrario en su aplicación, sin embargo, primero debe elegir confiar en ese tercero al realizar la solicitud en primer lugar.

Desde la perspectiva del proveedor:

• No hay que suponer que a pesar de cookie (s) de los clientes están presentes en la petición de que el consumidor es una página web bajo su control. Compruebe el encabezado del Referer contra una lista blanca de URL autorizadas y/o no confíe en la autenticación basada en cookies.
• Análoga a un CSRF/ataque adjunto confuso.

Answer 3

Existen problemas de seguridad para ambas partes. El más serio es para el sitio, incluido JSONP.

Si incluye un dominio de otro dominio (que no controla), ese dominio puede cambiar el script en cualquier momento. Pueden hacer que el javascript haga algo en el contexto de su página web, que su propio javascript podría hacer. No hay forma de evitar esto si usa JSONP. Debería considerar la comunicación entre dominios usando iframes, lo cual se hace mejor con la excelente biblioteca EasyDXM.

Si está ofreciendo un servicio web que maneje JSONP, debe protegerse de la Falsificación de solicitudes entre sitios (CSRF). Aquí es donde su servicio web devuelve información confidencial a los usuarios que han iniciado sesión. Si un usuario ha ingresado a su sitio, cualquier otro puede generar una solicitud GET para el servicio JSONP, y las cookies de SU dominio se envían con la solicitud, en esencia, autenticando al usuario conectado, excepto que ahora, el control remoto ¡Dominio obtiene la respuesta y puede leer los datos confidenciales!

La mejor manera de protegerse contra CSRF es generar un nonce (un número aleatorio difícil de adivinar) y almacenarlo en la sesión. Imprima este formulario en todos sus formularios en SUS páginas web, e inclúyalo en todas las solicitudes JSONP en SUS páginas. En el servidor, asegúrese de que el nonce esté presente y sea correcto en la solicitud (ya sea un GET, POST, etc.) Otros dominios no podrán adivinar este nonce y, por lo tanto, no podrán obtener la información confidencial, a pesar de las cookies siendo enviado.

Finalmente, hay otro tipo de problema de seguridad: JSONP simplemente no admite la autenticación de usuario en el navegador, del tipo que es posible con OAuth. Por supuesto, puede hacer que el servidor obtenga algún tipo de token de acceso (como con OAuth) y usar eso. Sin embargo, si desea realizar la autenticación por completo en el navegador, debe usar la comunicación entre dominios con iFrames. Creo que así es como OAuth 2.0 lo hace. Así es como lo configura: las páginas alojadas en su sitio tienen acceso completo a su servidor. Tenga una biblioteca de JavaScript que cargue EasyDXM y la use para configurar un marco flotante oculto en su sitio, y hable con él.

Answer 4

solution! ¡solución!

Tengo este pensamiento que hay un pirateo de dominios cruzados iframe que no ejecuta el código que viene, pero le permite pasar una variable. ¿Por qué no usarlo para envolverlo por seguridad? ...

Y sí, alguien se esta idea en primer lugar, como de costumbre :)

http://beebole.com/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup-security/

y también hay window.postMessage, que es seguro y no hacky