Evaluar la seguridad de un script de terceros

Navega tus respuestas
2

Estoy investigando sobre las herramientas de terceros para usar en un proyecto, y no he encontrado ninguna evidencia concluyente sobre esto:

¿Es mejor * incluir scripts de terceros con una etiqueta <script> o alojarlos localmente? Donde mejor significa que probablemente afectará a un número menor de usuarios.

Pude encontrar las mejores prácticas de seguridad para cada caso, pero no información sobre cuál es la mejor práctica. Estos son los principales pros / contras que puedo encontrar para una secuencia de comandos externa:

  • El tercero pirateado : todos sus clientes son vulnerables ahora.
  • Actualización de seguridad automática : todos los clientes están seguros ahora.

La configuración de la etiqueta integrity parece mucho más parecida a la autoubicación, ya que está bloqueado en una versión específica. Además, si el host está inactivo, su script está inactivo. Entonces, desde el punto de vista de la seguridad, un script externo con una suma de comprobación parece ser igualmente seguro, con más tiempo de inactividad.

De modo que realmente parece reducirse a cuánto confía en que las actualizaciones de terceros sean benignas o maliciosas Y cuál es el tiempo de respuesta de su empresa .

Mi opinión es que, si tiene un equipo de respuesta de seguridad las 24 horas del día, los 7 días de la semana, monitoree activamente a todos sus terceros Y HAGA una evaluación de seguridad de cualquier código nuevo, entonces podría tener sentido alojarlo usted mismo para reducir el riesgo de que lo hagan. hackeado (al tiempo que aumenta el tiempo de respuesta). De lo contrario, tiene más sentido dejar que la empresa lo aloje, ya que su tiempo de respuesta será mucho menor que la combinación de su tiempo de respuesta + el tiempo de respuesta de la compañía.

Entonces, ¿cuál es el estándar de la industria? ¿Hay alguna recomendación oficial?

Editar: encontré algunas publicaciones alarmistas en el blog que instaban a no usar las etiquetas <script> de terceros, pero todas invariablemente no reconocían el beneficio de seguridad de tener su script alojado por el creador de la compañía.

Edit2: Esta es una buena reseña que se relaciona indirectamente con las ventajas / desventajas de los scripts de terceros: "Si está utilizando scripts de terceros, asegúrese de examinarlos y su implementación postMessage" & & "Me puse en contacto con Matt Abrams (AddThis CTO), quien se aseguró de que la solución se implementara rápidamente y se enviara a los usuarios finales".

    
pregunta Me - 06.03.2018 - 07:08
fuente

1 respuesta

1

Si el script está alojado por un tercero

  • No tienes control sobre el script. Esto incluye tanto el contenido como la disponibilidad.
  • La secuencia de comandos se puede cambiar en cualquier momento, de manera adecuada (actualización de seguridad), de manera incorrecta (sitio pirateado) o de manera inconveniente (corrección de errores que, lamentablemente, rompe su caso de uso). Pero, si desea siempre la última versión de la secuencia de comandos, también puede simplemente tener un cronjob en ejecución que lo copia a su propio sitio y así mantenerlo disponible incluso si el tercero se cae. Y podría mantener las versiones de la secuencia de comandos para auditar los cambios que hicieron y cómo estos podrían afectar su sitio y sus usuarios.
  • Confía plenamente en la seguridad del tercero. Esto incluye que usted confíe en que su sitio no haya sido pirateado, su proveedor de DNS no haya sido pirateado y que nunca dejen de renovar su nombre de dominio (ya que otros podrían secuestrarlo de otra manera). Esto también significa que usted confía en sus empleados de que no cambian voluntariamente su guión (como agregar una puerta trasera) o que rompen cosas accidentalmente.
  • Al mirar el encabezado HTTP del Referer de las solicitudes, el tercero puede rastrear dónde está incrustado el script. Estas URL también pueden contener información confidencial en la propia URL. Además, el tercero podría rastrear a sus usuarios utilizando cookies (obvias) o cacheando encabezados como Etag (menos obvio ya que probablemente se espera el almacenamiento en caché).
  • Si la secuencia de comandos no se sirve desde su propio sitio, el navegador debe crear otra conexión TCP para obtener la secuencia de comandos y quizás otra sesión TLS (en caso de https). La conexión existente a su sitio no se puede reutilizar para esto. Esto significa que el script de terceros integrado puede reducir el rendimiento de su sitio, o al menos el rendimiento está fuera de su control.

En resumen: veo principalmente problemas al incrustar scripts de terceros. Pierde el control, la seguridad, la privacidad y quizás incluso el rendimiento. Solo si puede confiar plenamente (es decir, en un 100%, no solo en un 99%) al tercero para que no lo dañe voluntariamente o de mala gana, podría pensar en incrustar los scripts directamente del tercero. Especialmente en el caso de que su propio sitio sea lento o de ancho de banda restringido en comparación con el alojamiento de terceros, es posible que obtenga un aumento de rendimiento si el script es grande.

    
respondido por el Steffen Ullrich 06.03.2018 - 07:43
fuente

Lea otras preguntas en las etiquetas

certificado SSL para WebAPI ¿Qué ventajas tendrían los certificados del lado del cliente sobre la autenticación basada en firmas, como Oauth2 o HMAC para solicitudes HTTP?