¿Qué es una práctica más segura? Alojamiento desde CDN o sitio web principal.

Navega tus respuestas
2

Ha habido un largo debate sobre el modelado CSP, tengo una aplicación web y uso JQuery, para eso uso el sitio principal de JQuery http://code.jquery.com/jquery-x.yy.z.min.js para alojarlo en mi sitio para funcionar, sé que los CDN pueden ser útil en casos como este, también podría poner esto en mis etiquetas de script https://ajax.googleapis.com/ajax/libs/jquery/x.yy.z/jquery.min.js para trabajar el mismo proceso. En cuanto al tiempo de carga, Google alojó JQuery es más rápido que code.jquery.com .

Ahora, digamos que uso la segunda parte, es decir, ajax.googleapis.com, para alojar mi sitio JQuery en mi sitio web. Ahora, para colocar el Mecanismo de Defensa en profundidad para evitar que XSS use encabezados CSP (Contenido-Seguridad-Política), ahora lo primero que hago es en la Lista Blanca por script-src 'self' ajax.googleapis.com . Ahora, digamos que tengo una parte en mi sitio web donde la entrada se refleja sin filtrado, lo que puede causar XSS. Ahora, las secuencias de comandos en línea como <script>alert(/xss/)</script> se bloquearían y me proporcionarían protección. Pero luego hay un Negativo, ya que he incluido en la lista blanca el ajax.googleapis.com, cualquier atacante puede usar Angular JS 1.1.3 desde el mismo y causar XSS como "><script src="//ajax.googleapis.com/ajax/libs/angularjs/1.1.3/angular.min.js"></script><div ng-app ng-csp id=p ng-click=$event.view.alert(1337)><script async src=//ajax.googleapis.com/jsapi?callback=p.click></script>

Esto provocará un ataque XSS, ahora el punto es ¿Cómo podría modificar mi regla de CSP para que bloquee todos los demás puntos finales del sitio de la lista blanca que tengo? O si no es posible de lo que supongo que el API de Google CDN es seguramente no es una mejor opción que code.jquery.com . ¿Alguna explicación sobre cómo hacer ejercicio?

Porque incluso si uso code.jquery.com y la lista blanca, entonces Attacker puede usar una versión anterior de Jquery del mismo CDN y puede hacer un mal uso de la vulnerabilidad para causar XSS. Entonces, ¿cuál es la apuesta más segura que puedo hacer aquí? Explicar

    
pregunta Gerorge Timber 22.07.2016 - 10:00
fuente

3 respuestas

0

Es posible que desee echar un vistazo a la "Making CSP Great Una vez más, la presentación " de AppSec Europe, que analiza algunos matices de la implementación de CSP efectivos.

El comentario del usuario grc que menciona la integridad de los recursos secundarios es otra forma de ayudar a garantizar que solo los scripts que tiene explícitamente se puede cargar en la lista blanca (según el contenido de hash). Esto significa que puede evitar que un atacante pueda inyectar una versión vulnerable de Angular (fallará la comprobación de SRI), sin embargo, deberá monitorear las nuevas versiones de Angular / mantenerlo actualizado. También tenga en cuenta que es probable que el script inyectado por el atacante no incluya un hash SRI (por lo que se puede cargar cualquier biblioteca) a menos que solo puedan influir en el 'src' de una etiqueta de script a la que aplicó el hash.

La única forma en que realmente puede bloquear otros puntos finales vulnerables es incluir en la lista blanca las rutas .js específicas de su CSP, sin embargo, altamente recomiendo probar esto en múltiples navegadores (y / o tener algún tipo de regresión). prueba) para asegurarse de que no recurran a la lista blanca de todo el origen de origen.

Como alternativa, puede preferir usar un CSP basado en nonce: enlace

La idea es que, incluso si el atacante puede insertar otro elemento de script, no podrá determinar el nonce, y usted debería poder prohibir los scripts no deseados que viven en el mismo origen con esa técnica, siempre y cuando los usuarios no puede influir en el contenido del atributo 'src' para las etiquetas de script que bendice con el nonce.

Sin embargo, tenga en cuenta que esto todavía no protege la integridad del contenido (si su CDN es propiedad, todos los que extraigan JS de allí extraerán el contenido malicioso). Para eso, SRI es necesario.

    
respondido por el Phil Ames 22.07.2016 - 23:34
fuente
0

mi entendimiento es que no es posible especificar archivos JS individuales. en cambio, el principio es que confía en el proveedor de CDN, en este caso confía en google. Creo que sería una buena extensión para el CSP si se le permite incluir en la lista blanca el dominio y el recurso JS.

    
respondido por el Darragh 22.07.2016 - 10:23
fuente
0

Si realmente desea asegurar el javascript utilizado en su sitio, simplemente copie en su propio servidor la parte jQuery que usa y sirva directamente desde allí. Los CDN son extremadamente útiles para grandes contenidos como archivos de video. Pero javascript no es tan pesado y, por lo general, los navegadores del cliente pueden almacenar en caché, por lo que solo lo cargan una vez durante toda la sesión.

    
respondido por el Serge Ballesta 22.07.2016 - 14:14
fuente

Lea otras preguntas en las etiquetas

¿Qué ataque se puede detectar a partir de la información del flujo del controlador SDN? [cerrado] ¿La capacidad de eliminar datos afecta la disponibilidad en CVSS v2?