¿Cuán seguros son los CDN para entregar jQuery?

Question

Construimos sitios que tienen un área pública (no segura) y un área segura (entregada a través de HTTPS) y utilizamos la biblioteca jQuery.

Recientemente sugerí que usemos Google CDN para la entrega de jQuery. Algunos de mis colegas expresaron preocupaciones con respecto al aspecto de seguridad de esta forma de entregar bibliotecas de JavaScript.

Por ejemplo, mencionan el escenario donde alguien podría secuestrar el servidor DNS y luego inyectar una biblioteca modificada maliciosamente, abriendo la puerta a diferentes ataques de seguridad. Ahora, si el pirata informático puede inyectar código malicioso a través de Google CDN, entonces probablemente pueda hacer lo mismo si jQuery se sirve desde el sitio en sí, ¿no?

Parece que google CDN admite el servicio de bibliotecas a través de SSL.

Está sirviendo jQuery de CDN realmente menos seguro que sirviéndolo desde el servidor mismo? ¿Qué tan seria es esta amenaza?

Answer 1

Una forma de mitigar el riesgo es ejecutar una suma de comprobación contra el archivo obtenido de Google, y compararlo con una suma de comprobación conocida que ya esté en su poder.

En respuesta a una pregunta sobre si Google altera estos archivos de alguna manera, el empleado de Google Ben Lisbakken suggested comparing MD5 checksums de un archivo proporcionado por Google a la versión canónica de ese mismo archivo obtenido del sitio de inicio de sus mantenedores. Lea el comentario ocho en el sitio vinculado para el contexto.

Si le preocupa el secuestro de DNS, entonces, por supuesto, se aplicarán las mismas preocupaciones al archivo obtenido del sitio "original". También es probable que no desee incurrir en la penalización de velocidad de ejecutar una suma de comprobación contra el archivo jQuery en cada solicitud, a menos que sea increíblemente paranoico. Y, por supuesto, hacerlo eliminaría todas las ventajas de usar un CDN.

Pero suponiendo que sólo está algo paranoico, podría intentar algo como esto:

• asegurarse de que está hace referencia a una versión única y específica del archivo de jQuery de Google. Por ejemplo, hacer esto:

  http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js 
  

  y no esto:

  http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js 
  

  La última versión 1.4.2 puede volver ahora, pero mañana 1.4.3.Si usted tiene una combinación de HTTP y HTTPS necesidades, puede utilizar las direcciones URL relativas al protocolo, como esto:

  //ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js 
  

• Inicialmente generar y almacenar su propia suma de comprobación para este archivo.

• Repita periódicamente el proceso y asegúrese de que la nueva suma de comprobación coincida con la anterior. Si no es así, haz sonar los claxones.

Puede hacerlo mediante programación, por supuesto. Usted decide qué intervalo tiene sentido. ¿Cada minuto? ¿Cada cinco? Ahora tiene las características de un interruptor de muerte automático cuya sensibilidad puede ajustar a su preferencia. La rutina "monitor" ciertamente no tiene que ejecutarse sincrónicamente dentro de la aplicación que está buscando proteger; quizás ejecute una pequeña aplicación de utilidad en el mismo servidor solo para este propósito.

Es bastante fácil de probar: simplemente modifique el hash almacenado. Como hace referencia a una versión de archivo específica, no se presionará el botón de pánico con cada actualización de versión menor. Cuando desee pasar a una nueva versión de jQuery, cambie la URL de la API AJAX en su sitio y almacene el nuevo hash.

Answer 2

Como sus colegas señalan, secuestrar un servidor DNS sería un problema aquí. No lo sería si sirvió la biblioteca desde el mismo host que su sitio. Sin embargo, si uno usa HTTPS, es poco probable que el atacante tenga un certificado válido en el sitio falsificado. No sé cómo reaccionarían los navegadores a esto, pero sospecho que marcarían el sitio como inseguro (ya que no se puede confiar en una parte del mismo) y actuarían en consecuencia.

Así que en resumen; si también se accede a la CDN utilizando HTTPS, no debería haber grandes riesgos.

Editar: Ten en cuenta también el tema de la privacidad por parte Gert G.

Answer 3

Si existe confianza en línea a continuación, Google es el más digno de confianza ...

No hay duda de que Google CDN es seguro, pero los problemas siempre siempre vienen de conexión a Internet calidad de usuario/servidor.

Por cierto, si se incluye la biblioteca jQuery con Google secuencia de comandos API cargador, Google añade un pequeño código de seguimiento de estadísticas a que es bibliotecas JavaScript disponibles CDN (aproximadamente + 4 kb, ver en Firebug) que hace 20kb minified y comprimido jQuery biblioteca un poco pesado, además de prever la velocidad de SSL.

De todos modos minifying/compresión/almacenamiento en caché jQuery no es un problema en estos días, sugiero hacer su propio ...

Answer 4

está sirviendo de jQuery CDN realmente menos seguro después de servirlo desde el propio servidor?

Sí. Si se trata de un recurso externo, es siempre menos seguro. ¿Cómo podría estar seguro de saber lo que realmente obtendrán sus clientes si no posee el código fuente? Y si no está familiarizado con CloudBleed, es posible que desee leer antes de continuar.

Si necesita cargar jQuery desde un CDN externo por motivos de rendimiento, asegúrese de estar utilizando Subsesource Integrity. Más información sobre SRI can be located en MDN.

Por último, si la carga de forma segura a través de jQuery CDN es una preocupación debido al rendimiento del sitio web y la creación de un un solo punto de la insuficiencia (y que debería ser una preocupación si usted está en todo familiarizado con el trabajo de Steve Souders), es casi seguro que esté mejor desde una perspectiva de seguridad y rendimiento moviendo todas sus secuencias de comandos internamente y cargándolas de forma asincrónica en paralelo usando Fetch Injection. Solo asegúrate de que, si lo haces, estás almacenando cachés agresivamente en el navegador. Y si prestas servicio a un público global, asegúrate de almacenar en el caché esos activos.