¿Cuál es el peligro de tener algún código aleatorio, fuera de mi control, de JavaScript ejecutándose en mis páginas?

Riesgo

En el peor de los casos, podría hacer que el sitio web sea completamente inaccesible para los usuarios, podría realizar acciones particulares como ellos (por ejemplo, solicitar la eliminación de una cuenta, gastar dinero) o podría robar datos confidenciales.

Prevención

No se puede hacer. Si ejecuta el JavaScript de otra persona en su sitio web, no se vuelve más seguro que ese tercero. Tienes que alojarlo tú mismo.

Sin embargo, puedes acercarte al objetivo.

1. Una cosa puede ser Política de seguridad de contenido . La configuración de ejemplo del encabezado Content-Security-Policy a script-src 'self' www.google-analytics.com; , evitaría la ejecución de scripts servidos desde otros dominios distintos al suyo o www.google-analytics.com . De esa manera, si alguien encuentra alguna vulnerabilidad de secuencias de comandos entre sitios (XSS) que le permita agregar su propio código de JavaScript en línea a su sitio web, no se ejecutará.
2. Otra cosa realmente interesante se llama Integridad del sub-recurso . Esencialmente, se agrega la suma hash de JS que esperas ejecutar al parámetro integrity que le das a la etiqueta script .

<script src="https://example.com/example-framework.js"integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"/>

Puede generar esos hashes en línea en enlace o con el comando:

openssl dgst -sha384 -binary FILENAME.js | openssl base64 -A 

Esto, por supuesto, tiene desventajas, por ejemplo, los proveedores de análisis pueden cambiar sus scripts y tendrá que cambiar el parámetro integrity para que sigan funcionando. También es una característica bastante nueva (Chrome 45.0+, Firefox 43+, Opera 32+, no es compatible con IE, Edge o Safari en este momento), por lo que establece la seguridad de su cliente en su propio software.

Ver también Hoja de trucos de administración de Javascript de terceros de OWASP.

  

¿Qué es lo peor que puede pasar?

El tercero puede hacer cualquier cosa que usted pueda hacer con JavaScript, o cualquier cosa que un atacante pueda hacer con XSS.

Esto incluye robar cookies, inyectar un keylogger de JavaScript, omitir la protección CSRF y, por lo tanto, ejecutar cualquier solicitud que pueda ejecutar (por ejemplo, agregar un nuevo usuario administrador) o cambiar el contenido de su página web (por ejemplo, para inyectar anuncios o para ataques de phishing) .

  

¿Cómo empiezo a lidiar con el riesgo?

Si no confía en las intenciones o la seguridad del tercero, la única solución adecuada sería alojar el script usted mismo (después de asegurarse de que haga solo lo que usted quiere que haga).

Si no desea hacer eso, puede agregar Subresource Integrity para mitigar el riesgo:

Agregue un hash del script a la inclusión y navegadores modernos comparará el hash con el hash del archivo incluido. Si no coincide, el código no se ejecutará: <script src="https://example.com/script.js"integrity="[hash]" crossorigin="anonymous"></script> . De esta manera, puede asegurarse de que el script no cambie. Por supuesto, si cambia, debe volver a revisar el script y cambiar el hash, ya que de lo contrario su sitio web se romperá.

  

¿Qué riesgos plantea este código no controlado? ¿Qué es lo peor que puede pasar?

En general, el atacante obtiene acceso a cualquier cosa que sus métodos de autenticación estén diseñados para proteger.

En el peor de los casos, suponga que el código está diseñado a la medida para su sitio. Se le puede pedir a las acciones que realiza el usuario que ingresen las credenciales de seguridad, lo que le da al atacante acceso a la cuenta de ese usuario mucho tiempo después de que se desconecte. Para una cuenta bancaria, una billetera de bitcoin u otros sitios que controlan el acceso a los activos, el atacante tendrá acceso a acciones irreversibles de alto valor. Si no hay valor en el momento pero obtienen las credenciales para acceder a la cuenta, pueden esperar hasta que haya suficiente valor en la cuenta para que valga la pena.

  

¿Cómo empiezo a lidiar con el riesgo?

Bien: establezca la política de seguridad de contenido y la integridad de los sub-recursos en los scripts que usted mismo hospeda. Consulte la respuesta de @ Przemek para obtener más información sobre estos. No estoy seguro de si es necesario decirlo, pero todo el JavaScript debe servirse a través de HTTPs; esto al menos aumenta el costo de MITM para esos recursos.

Mejor: aloja el código tú mismo. Pero, no olvides actualizarlo regularmente. Estos proveedores lanzan sus propios arreglos de seguridad. No te quedes atrás.

Mejor: revisa todo el código fuente. La mayoría de las veces, puede encontrar versiones no minimizadas de JS que puede leer usted mismo (y eventualmente solo dife), y luego reducirlas y agruparlas con el resto de sus sitios JS. Obviamente, este es un alto costo, ponderarlo adecuadamente contra las necesidades de su sitio.

  

¿Qué es lo peor que puede pasar?

El término técnico es ejecución de código arbitrario. En este contexto, "arbitrario" significa "cualquiera", como en "cualquier cosa que sea posible codificar en JavaScript podría terminar ejecutándose en su sitio".

¿Es posible usar JavaScript para leer valores de campos de formulario? Sí. ¿Es posible usar JavaScript para cargar algo desde una URL? Sí. Luego, la ejecución de código arbitrario significa que alguien podría leer el nombre de usuario y la contraseña de un usuario al iniciar sesión y transmitirlos a su propio servidor, codificados como parámetros en una solicitud GET. (Esto proporciona una ejecución final ordenada alrededor del cifrado HTTPS de los datos de inicio de sesión de sus usuarios, por cierto).

¿Es posible usar JavaScript para leer datos en una página? Sí. Luego, la ejecución de código arbitrario significa que alguien puede leer los datos privados del perfil de un usuario cuando accede a la página que lo contiene. (Y use una solicitud HTTP para informar al servidor del atacante).

... y así sucesivamente. Una vulnerabilidad de ejecución de código arbitrario se considera lo peor posible desde una perspectiva de seguridad cibernética, ya que explotarlo significa que literalmente cualquier cosa mala que sea posible se puede realizar en su sistema.

Vale la pena considerar todo lo anterior, pero para ser justos, existen prácticas de desarrollo bien aceptadas, así como protecciones integradas en los navegadores modernos que protegen contra los casos más graves señalados.

También vale la pena señalar que hay tres formas en que el código de terceros puede ejecutarse en el contexto (es decir, compartir el mismo DOM del navegador) que sus páginas web: 1) JS que incluye y representa junto con su página, p.ej Google Analytics, o 2) Bookmarklets que el usuario controla (por ejemplo, Spritzlet o Pinterest), y 3) extensiones de navegador o barras de herramientas. Los dos últimos están casi completamente fuera de su control; El primero es algo que puedes auditar hasta cierto punto.

Por mucho, lo más importante que debe asegurarse es que los servidores web que controla y que responden al cliente (navegador, bot, malware) están bloqueados. XSS, CSRF, inyección de SQL y muchos otros vectores de ataque están bajo su control en el lado del servidor. Tendría que permitir explícitamente CORS en su servidor, pero si lo hace, asegúrese de saber lo que está haciendo y esté particularmente atento. Esto no quiere decir que todo esto sea fácil, obvio o algo así, pero es totalmente independiente de si la vulnerabilidad se viola a través de JS o cualquier otro método.

Suponiendo que ha protegido su servidor web y ha bloqueado los puntos finales a los que se puede llamar, el resto de lo que falla funciona en una clase diferente. JS (y plugins / extensions / toolbars / bookmarklets) puede hacer una gran variedad de cosas malas: registradores de pulsaciones de teclas, inyección de elementos de apariencia inofensiva que en realidad envían datos a otros lugares, etc. Todos estos son ejecutados por el navegador.

Si está sirviendo el JS en nombre de un tercero, debe tener cuidado de confiar y verificar la fuente. Un fragmento de Google Analytics es probablemente seguro. Un widget de publicación de anuncios de terceros podría valer la pena estudiarlo más detenidamente. En todos los casos, el código detrás de estos puede ser inspeccionado: si el navegador puede ejecutarlo, puede ver el código JS y decidir: ¿es esto algo que desea en su sitio?

JavaScript es una herramienta poderosa. Pero al final, JS es un software que ejecuta el navegador, por lo que confiamos mucho en los navegadores y sistemas operativos que los ejecutan para garantizar la seguridad. JS no es un software que tenga habilidades mágicas particulares para violar su servidor o hacer que su servidor haga cosas para las que no está diseñado.

Su sitio puede hacer poco o nada, lo que le permite a JS ejecutar código de manera arbitraria en la computadora del usuario; es el usuario el que debe tener actualizaciones recientes a los navegadores y sistemas operativos, etc. Puede detectar versiones antiguas y publicar advertencias en Sé un buen chico, pero eso es todo.

Asegure su servidor, instale actualizaciones, asegúrese de que su código esté seguro, evite servir a JS de terceros desconocidos. Y luego, asegúrese de que su sitio esté registrado con las Herramientas para webmasters de Google, que le notificarán si su sitio ha sido pirateado en muchos casos y, si se lo puede permitir, obtenga un servicio que analice las vulnerabilidades de su sitio.