¿Sería posible tener un observatorio de javascript y un CSP (Política de seguridad de contenido) más estricto ... similar al observatorio de SSL de la EFF?
Creo que primero debes decidir contra qué tipo de ataques quieres protegerte. ¿El atacante solo podrá reemplazar el contenido de sitios de terceros incluidos en el sitio principal (es decir, jquery.org) o será capaz de modificar el sitio principal también?
Si el atacante solo puede comprometer los lados de terceros, un CSP estricto y algo así como un observatorio de JavaScript podrían funcionar, porque o bien prohíbe la inclusión de secuencias de comandos de terceros o lo restringe a un buen script conocido (vea también hashes para script-src que están implementados en Chrome 46).
Pero si el atacante también puede modificar el contenido del sitio principal, este enfoque probablemente solo ayude a los pocos sitios que no tienen un script en línea, ningún script dependiente del usuario y donde el script cambia raramente. En la práctica, JavaScript se cambia mucho más a menudo que un certificado y, a menudo, hay casos en los que el JavaScript que se entrega a un usuario se adapta al usuario, es decir, depende de la sesión, la cuenta, etc. Esto no solo se aplica al script en línea sino también al script. Incluido con la etiqueta de script. También tiene muchos fragmentos de script pequeños incluidos con onXXX attibute (es decir, onclick="dothis();" ) donde no solo es relevante el código del script en sí, sino también donde este código se usa en el HTML. Por lo tanto, un observatorio no ayudaría a todos sino a unos pocos sitios, principalmente estáticos.
El filtro NoScript XSS es defectuoso.
Todos los filtros XSS están limitados, al igual que todas las soluciones antivirus. Es imposible distinguir de manera confiable entre lo bueno y lo malo con la información limitada que tienen estos filtros acerca de lo que puede ser bueno o malo para un sitio específico. O bloquean demasiado (falsos positivos) o pierden algo (falsos negativos). En el primer caso, el usuario apagará el filtro y, en el segundo, no ofrecerá protección completa.
El sandboxing más estricto (para Windows), podría evitar el código de explotación para acceder a las API que dan acceso a nombre de usuario, nombre de computadora, dirección MAC, nombre de host, conexiones abiertas a direcciones IP arbitrarias, etc.
Sí, no consideraría óptima la arquitectura de seguridad actual de Firefox y creo que Chrome proporciona una mejor protección contra las vulnerabilidades que intentan salir del navegador. Por otro lado, por lo que sé, Chrome no proporciona la API que necesita para las comprobaciones completas realizadas por NoScript (es decir, prevención XSS, detección de clickjacking ...).
Otro enfoque sería ejecutar el sistema operativo con el navegador dentro de alguna máquina virtual para que el atacante no solo salga del navegador, sino también de la máquina virtual para obtener la información relevante. Cada nivel de separación hace que sea más difícil para el atacante.
¿Alguien podría explicar partes del Firefox de 0 días del FBI?
Según la información pública disponible, parece que utilizaron Javascript para activar un error en el navegador para inyectar un código de shell que luego podría hacer cualquier cosa con los permisos del usuario, incluido el acceso al nombre de host y MAC y el envío de esta información al servidor de los atacantes. . No puedo ver en la información pública qué sitio comprometieron y si el sitio dependía de un script, si usaba un script en línea, etc. Por lo tanto, se desconoce si su enfoque con el observatorio y el CSP habría protegido al usuario en este caso.