jquery - the - la saga crepúsculo luna nueva recaudación

¿Qué tan seguros son los CDN para entregar jQuery?

Question

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

Recientemente sugerí que usáramos Google CDN para la entrega de jQuery. Algunos de mis colegas expresaron su preocupación con respecto al aspecto de seguridad de esta forma de entregar bibliotecas de JavaScript.

Por ejemplo, mencionan el escenario en el que alguien podría secuestrar el servidor DNS y luego inyectar una biblioteca modificada malintencionadamente, 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í, ¿verdad?

Parece que google CDN soporta bibliotecas de servicio sobre SSL.

¿El servicio jQuery desde CDN es menos seguro que el servidor en sí? ¿Qué tan seria es esta amenaza?

Answer 1

¿El servicio jQuery desde CDN es menos seguro que el servidor en sí?

Sí. Si es un recurso externo siempre es menos seguro . ¿Cómo podría estar seguro de saber lo que realmente obtienen 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 razones de rendimiento, asegúrese de que está utilizando la Subcontratación Integridad . Se puede encontrar más información sobre SRI en MDN.

Por último, si cargar jQuery de forma segura a través de CDN es una preocupación debido al rendimiento del sitio web y la creación de un punto único de falla (y debería ser una preocupación si está familiarizado con el trabajo de Steve Souders), es casi seguro que sea mejor desde el punto de vista de la seguridad y el rendimiento, moviendo todos sus scripts de forma interna y cargándolos de forma asíncrona en paralelo con Fetch Injection . Solo asegúrese de que, si lo hace, está agresivamente el almacenamiento en caché del navegador. Y si sirve a una audiencia global, asegúrese de estar al borde de almacenar esos activos.

Answer 2

Como sus colegas señalan, el secuestro de un servidor DNS sería un problema aquí. No sería si sirviera 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 falso. No sé cómo reaccionarían los navegadores ante esto, pero sospecho que marcarían el sitio como inseguro (ya que parte de él no se puede confiar) y actuarán en consecuencia.

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

Edición: También considere el tema de privacidad mencionado por Gert G.

Answer 3

Si existe confianza en línea, entonces Google es el más confiable ...

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

Por cierto, si incluye la biblioteca jQuery con el script del cargador de la API de Google, Google agrega un pequeño código de seguimiento de estadísticas a sus bibliotecas de JavaScript disponibles CDN ( aproximadamente + 4kb, consulte Firebug ) que hacen que la biblioteca jQuery minificada y comprimida de 20 kb sea un poco pesada. más prever la velocidad SSL.

De todos modos, minimizar / comprimir / almacenar en caché jQuery no es un problema en estos días, sugiero que hagas tu propio ...

Answer 4

Una forma de mitigar el riesgo es ejecutar una suma de comprobación contra el archivo obtenido de Google, y compararla con una suma de comprobación que se sabe que ya se encuentra en su poder.

En respuesta a una pregunta sobre si Google modifica estos archivos de alguna manera, el empleado de Ben , Ben Lisbakken, sugirió comparar las sumas de comprobación MD5 de un archivo provisto por Google a la versión canónica de ese mismo archivo que se obtuvo del sitio de inicio de sus mantenedores. Lea el comentario ocho en el sitio vinculado para el contexto.

Si está preocupado por el secuestro de DNS, por supuesto, las mismas preocupaciones se aplicarían al archivo que se obtuvo del sitio "original". También es probable que no desee incurrir en la penalización de velocidad al 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 asumiendo que solo eres un tanto paranoico, podrías intentar algo como esto:

• Asegúrese de que está haciendo referencia a una versión única y específica del archivo jQuery de Google. Por ejemplo, haz 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 puede devolver 1.4.2 ahora, pero 1.4.3 mañana. Si tiene una combinación de necesidades de http y https, puede usar URL relativas al protocolo, como esta:

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

• Inicialmente genere y almacene 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í, haga sonar los claxones.

Puedes hacer esto programáticamente, por supuesto. Tú decides qué intervalo tiene sentido. ¿Cada minuto? Cada cinco? Ahora tiene las características de un interruptor de apagado automático cuya sensibilidad puede ajustar a sus preferencias. La rutina del "monitor" ciertamente no tiene que ejecutarse sincrónicamente dentro de la aplicación que busca 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: solo modifica el hash almacenado. Ya que está haciendo 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 quiera pasar a una nueva versión de jQuery, cambie la URL de la API de AJAX en su sitio y almacene el nuevo hash.