¿Cómo puedo restringir o limitar los archivos de JavaScript de terceros (* .js) que pueden DOS en mi sitio?

3

Muchos propietarios de sitios web integran Google Analytics, varios complementos de javascript de redes sociales de Facebook o Twitter en sus páginas web. El problema es que esta confianza parece ser "todo o nada", lo que significa que no hay límites o estructura en cuanto a lo que está permitido hacer el sitio de terceros.

Además, no parece haber ningún manejo estructurado de excepciones (SEH) disponible para Javascript en cualquier momento, los scripts de los autores de sitios web independientes residen en la misma página web.

Ejemplo

En / 7 13 varios sitios que se integran con Facebook efectivamente dosificaron la mitad de Internet, haciendo que varios sitios sean inutilizables. Creo que este problema podría evitarse si el javascript de terceros pudiera estar restringido (según lo define el propietario del sitio web y el navegador), y / o haya una variación del manejo de excepciones meta-estructurado para Javascript.

Pregunta

  • ¿Hay alguna investigación o propuesta que intente restringir o controlar el javascript de terceros en cualquier nivel?

  • ¿Qué grupo de trabajo (W3C, grupo RFC, proveedor, etc.) es el más apropiado para proponer y definir formalmente un estándar para controles de javascript de terceros?

pregunta random65537 08.02.2013 - 02:40
fuente

4 respuestas

3

No. En la práctica, no hay una buena solución para este problema. Si incluye una biblioteca de JavaScript de terceros en su página web (a través de <SCRIPT SRC=...> ), está confiando en ese Javascript. Eso incluye confiar en no hacerte. Así es como funciona, y no hay solución, dado el modelo de seguridad actual del navegador.

Si no confía en el Javascript de terceros, no lo incruste en su página web. Esa es la única solución razonable hoy.

(En principio, podrías usar Caja, pero es un mecanismo bastante complejo: es como usar un cañón para disparar una mosca).

    
respondido por el D.W. 08.02.2013 - 22:51
fuente
2

Primero, esto parece haberse originado en un error cometido por alguien en Facebook que tiene acceso para actualizar sus scripts JS a su CDN que alguien no notó / reparó en Facebook durante 15-20 minutos. Dudo que haya sido un ataque malicioso (ya que solo se redirigió a una página de error y solo se aplicó a las personas que actualmente tienen acceso a Facebook en lugar de a todos).

Entonces, soluciones como La Política de seguridad del contenido no es relevante, ya que los distintos sitios web decidieron deliberadamente incluir el javascript de conexión de facebook en su página y querer que se ejecute. La Política de seguridad del contenido simplemente limita los dominios que pueden ejecutar código para mitigar XSS.

Del mismo modo, dudo que Facebook vaya a adoptar ADSafe de Douglas Crockford (o que ejecute su código a través de google-caja), e incluso si lo hicieran o escribieran su propio código, probablemente aún servirían desde su CDN. Así que aún tendrías que confiar fundamentalmente en Facebook para la competencia técnica.

La mejor solución es dudar antes de permitir que terceros carguen código en su página. ¿Realmente necesitas un botón de Me gusta / Compartir de Facebook en cada página? ¿Podría simplemente incluir un enlace estático para "Me gusta" en su organización en Facebook y esperar que las personas compartan contenido copiando la URL en su feed de Facebook?

Tal vez tome una versión estática de sus archivos javascript que funcione correctamente; aunque esto podría ser problemático si (a) dejan de admitir versiones antiguas de sus archivos JS o (b) tienen una verificación (posiblemente a través de CSP) de que el script estaba siendo servido desde su CDN (aunque no creo que CSP pueda hacer esto) en el momento) o (c) la versión estática que sacó tenía un código problemático que no le gustó.

Mi opinión es que Facebook tratará este lapso seriamente y es probable que no vuelva a suceder pronto. Deben hacer cosas como exigir que sus scripts se sirvan solo a través de https, y someterse a pruebas de calidad automatizadas y manuales significativas antes de la implementación; por ejemplo, ningún código se activa si no ha pasado días de pruebas (no se deben implementar correcciones de errores) en vivo, pero vuelva a la última versión de trabajo).

    
respondido por el dr jimbob 08.02.2013 - 17:14
fuente
1

Quizás esto pueda ayudarte.

enlace : ADsafe hace que sea seguro colocar el código de invitado (como publicidades de terceros o widgets) en una página web. ADsafe define un subconjunto de JavaScript que es lo suficientemente potente como para permitir que el código del huésped realice interacciones valiosas, al mismo tiempo que evita la intrusión o el daño malicioso o accidental.

enlace : compilador para hacer que HTML, CSS y JavaScript de terceros sean seguros para incrustar

  • Suena muy bien, pero el código de un tercero debe enviarse a un servidor de Caja (Google también proporciona uno) para "compilar".
respondido por el Matrix 08.02.2013 - 09:26
fuente
1

No estoy seguro de haber entendido tu pregunta correctamente, pero ya existe un sistema que controla desde qué dominios se aceptará JavaScript.

Si es el propietario de un sitio web, puede agregar Content-Security-Policy (CSP) al encabezado de tus páginas. En el CSP puede definir los dominios, desde cuya página acepta JavaScript. Si el navegador de los usuarios admite el CSP (Firefox desde la versión 4), entonces JavaScript no se cargará desde otros dominios que no sean los definidos. Así que las bibliotecas de JavaScript de google.com no pudieron cargar otras bibliotecas de example.com .

Hay muchas otras opciones en CSP, depende del navegador si se respetan o no.

    
respondido por el martinstoeckli 08.02.2013 - 13:14
fuente

Lea otras preguntas en las etiquetas