¿JSONP es seguro de usar?

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

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 callback. Sin embargo, debe tener en cuenta la falsificación de solicitudes entre sitios (CSRF) .

Siempre que controle el script 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.

Actualice el 28 de junio de 2012 : si desea protegerse contra los ataques CSRF, debe leer esta publicación en profundidad en un blog por un experto en seguridad: http://erlend.oftedal.no/blog/?blogid=130

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

Aquí hay un resumen de los problemas de seguridad con JSONP, según lo entiendo:

Desde la perspectiva del consumidor:

  • Debe confiar en que el proveedor no devuelva JavaScript malicioso en lugar del JSON esperado incluido en la callback JSONP que especifique.
  • Lo mismo puede decirse de 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 debe suponer que, aunque las cookies de los clientes estén presentes en la solicitud, 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.
  • De forma análoga a un CSRF / ataque adjunto confuso.

Hay 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 maneja 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, existe 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.

JSONP definitivamente no es seguro, ya que simplemente está ejecutando lo que tenga entre dominios como JavaScript.

¡solución! ¡solución!

Cree un iframe, preferiblemente uno de espacio aislado, y cargue JSONP allí. Capture el resultado y páselo por window.postMessage

Y sí, alguien entendió esta idea primero, como de costumbre 🙂

La publicación del blog ya no está allí, pero guardo el enlace aquí para obtener crédito: http://beebole.com/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup-security/

Usó el hack window.name para la comunicación iframe, pero eso fue para IE6 y 7.