¿Cuáles son los riesgos de la comunicación JSONP entre dominios?

Question

En nuestra aplicación web nos encontramos con la situación en la que tenemos que hacer una llamada AJAX entre dominios desde un dominio que controlamos completamente a otro dominio que controlamos por completo. He estado navegando por la mejor solución y los dos que me vienen a la mente son un proxy de archivo local (archivo local que usa php :: fopen) o jquery/JSONP.

Cuando miro en línea veo que las personas hablan rutinariamente acerca de cómo es peligroso usar JSONP porque alguien podría inyectar datos maliciosos con él. El dilema es que la mayoría de los argumentos en contra no parecen contener mucha agua, así que voy a pedirle aclaraciones a la Pila.

¿Cuáles son los vectores específicos de ataque que se abrirán mediante el dominio cruzado JSONP?

Desde mi entender el único vector de JSONP es el mismo vector exacta que se abre mediante la inclusión de una etiqueta <script> en su sitio cuya src es cualquier sitio que no está controlado por usted: Que pudieran convertir malicioso y comenzar a cultivar sesiones de usuario/cookies/datos. Si eso es cierto, parece que no se trata del protocolo (JSONP), sino de la fuente de la que se recopilan los datos.

Porque si se trataba de un proxy del lado del servidor, una etiqueta <script>, o ajax/JSONP, el riesgo es que coloque el contenido de otra persona en mi página, y podrían comenzar a cultivar sesiones de usuario si se sintieran obligados (en una forma que es exactamente lo que Google Analytics hace por medio de una etiqueta de script).

Muchos vectores que escucho en línea dependen de la validación incorrecta de los formularios y datos enviados por los usuarios. En el ejemplo, JSONP se utiliza para extraer algún archivo, que coloca los datos en un formulario, y luego el formulario se envía para la inserción de la base de datos. Si los datos de ese formulario son confiables, porque provienen de una fuente segura para ser segura (datos JSONP) y se ingresan sin validación, tampoco es JSONP el que tiene la culpa, sino la entrada del usuario validado incorrectamente. Un usuario puede hacer exactamente las mismas modificaciones a esa forma usando Firebug, pero la última vez que revisé nadie llama a Firebug un vector de seguridad.

El último elemento es la noción de que con el proxy del lado del servidor hay una mayor capacidad para filtrar los resultados antes de pasarlo al cliente. Sin embargo, ya sea PHP o Javascript, podría filtrar los resultados para eliminar cosas como, onclick o iframe. Claro, alguien del lado del cliente podría alterar mi función javascript para eliminar el filtrado, pero el filtrado solo afectaría su experiencia específica del cliente y no se alteraría para otros usuarios, lo que evitaría un ataque XSS multicliente permanente.

Obviamente, hay algunos beneficios para el proxy del lado del servidor porque facilitaría el registro de posibles ataques XSS, pero en términos de prevención del ataque en sí, tanto PHP como Javascript parecen tener las utilidades adecuadas. De alguna manera, parece que JSONP es en realidad más seguro que una simple etiqueta <script> porque al menos con JSONP el resultado pasa a través de una función lo que significa algo filtrado, en lugar de confianza general, como ocurre con <script>.

¿Hay algún riesgo que me falte o que pase por alto? Si entiendo el problema correctamente, entonces no existe riesgo de seguridad al usar JSONP para incluir los contenidos de un archivo en el que confiamos de una fuente en la que confiamos. ¿Es eso una evaluación precisa?

SOLUCIÓN

1. Si ambos extremos son de confianza, no hay peligro en JSONP (es básicamente una etiqueta <script>).

2. Ambos Script/JSONP tienen las mismas vulnerabilidades de seguridad porque se ejecutan automáticamente, en lugar de simplemente transmitir como datos. Usar un proxy del lado del servidor significa que el retorno entre dominios se pasa como datos y se puede filtrar para detectar contenido malicioso. Si el dominio cruzado es completamente confiable, entonces JSONP/SCRIPT es seguro, si hay alguna sospecha de riesgo, luego pasarlo a través de un proxy de filtro.

Answer 1

Cuando se controla ambos extremos de la solicitud, la mayor parte de los tradicionales de seguridad preocupaciones sobre JSONP no son un problema.

Un problema adicional que encontrará es que algunos usuarios bloquean scripts de terceros como medida de seguridad. Eso bloqueará tus solicitudes JSONP también. El enfoque de proxy del lado del servidor no tiene ese problema.

Answer 2

Hay una GRAN diferencia entre server-side-proxy y <script>/JSONP. En el primer caso, se descarga datos, en este último se descarga y ejecuta automáticamentecódigo

Cuando se construye un lado-servidor proxy, el código JavaScript puede utilizar XmlHttpRequest para descargar datos. Esta información no se ejecutará automáticamente; tienes que hacer algo estúpido explícitamente, como eval(), para que se ejecute. Incluso si el formato de datos es JSON y el otro servidor se ha visto comprometido y su propio proxy del lado del servidor no capta el compromiso, usted todavía tiene una línea de defensa disponible para su código de cliente. Puede, por ejemplo, analizar el JSON utilizando safeJSON parser y rechazar el script malicioso.

Pero cuando utiliza JSONP o una etiqueta <script>, está incluyendo directamente el código de de otra persona. Debido a su código (y no a los datos), el navegador lo ejecuta automáticamente, sin darle la oportunidad de inspeccionarlo o modificarlo.

En resumen, del lado del servidor proxy le da dos líneas adicionales de defensa -

1. capacidad de inspeccionar datos en el servidor de contenido malicioso
2. capacidad de inspeccionar datos en javascript antes de ejecución, si es necesario, debe ejecutarlo.