bootstrap - ¿Cómo puedo asegurarme de que mis archivos JavaScript entregados a través de un CDN no se alteren?

code-signing

Question

Estoy trabajando en un escenario en el que algunos archivos JavaScript se alojarán en una CDN. Quiero tener algún mecanismo para que cuando se descarguen estos archivos en el lado del usuario, pueda asegurarme de que los archivos no fueron alterados y de hecho provienen del CDN especificado.

Entiendo que la tarea es muy fácil si estoy usando SSL, pero aun así, quiero asegurarme de que se sirvan los archivos correctos incluso en HTTP sin SSL.

Por lo que pude buscar, no existe un mecanismo existente como la firma digital para archivos JavaScript que sea compatible con todas las plataformas. Quizás no es necesario?

¿Hay algún método integrado en los navegadores para verificar el autor de los archivos JavaScript? ¿Hay algo que pueda hacer para hacer esto de manera segura?

Answer 1

De hecho, una característica como esta se está redactando actualmente bajo el nombre de Subresource Integrity . Mire el atributo de integrity de la etiqueta <script> . Si bien aún no se ha adoptado completamente en todos los ámbitos , cumple con este propósito.

integrity

Contiene metadatos en línea que un agente de usuario puede usar para verificar que un recurso recuperado se haya entregado sin manipulación inesperada. Ver Integridad de los recursos secundarios.

Source

Subresource Integrity (SRI) es una característica de seguridad que permite a los navegadores verificar que los archivos que obtienen (por ejemplo, de un CDN) se entregan sin manipulación inesperada. Funciona al permitirle proporcionar un hash criptográfico que debe coincidir con un archivo recuperado.

Source

Ejemplo:

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

Sin embargo, tenga en cuenta que esto no lo protegerá contra los ataques de Man in the Middle si está transfiriendo sus recursos a través de HTTP simple. En este caso, el atacante puede suplantar el código hash, haciendo que la defensa contra los archivos de script manipulados sea inútil.

Por esta razón, siempre debe usar conexiones HTTPS seguras en lugar de HTTP simple, además de las medidas de seguridad descritas anteriormente.

Answer 2

Está buscando verificaciones de integridad de recursos secundarios .

Por ejemplo, aquí está el fragmento de jQuery CDN:

<script src="https://code.jquery.com/jquery-3.1.0.js"
integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
crossorigin="anonymous"></script>

Answer 3

Hay un punto importante sobre lo que este tipo de firma puede y no puede hacer. Puede proteger al usuario de ataques hipotéticos en los que alguien modifica su código. No puede asegurar a su sitio que su código es el código que se está ejecutando. En otras palabras, usted todavía no puede confiar en nada del cliente que venga a su sitio.

Answer 4

Si su modelo adversario permite que un atacante modifique archivos JavaScript a medida que se entregan desde un CDN, entonces su modelo adversario permite que un atacante modifique la fuente de referencia tal como se entrega para eliminar cualquier intento de verificación, para alterar la dirección de origen a otra que no sea el CDN, y / o eliminar completamente la referencia al JavaScript.

Y no abra la lata de gusanos de cómo su aplicación puede determinar si el resolutor del usuario está resolviendo o no correctamente a la CDN a través de solicitudes HTTP (o cualquier otro mecanismo que no tenga una cadena de confianza verificada).

/ etc / hosts:

# ...
1.2.3.4 vile-pirates.org trustworthy.cdn
# ...

Answer 5

Descargo de responsabilidad: como siempre, solo debe considerar que estos mecanismos son de alguna utilidad al usar https, ya que pueden deshabilitarse fácilmente a través de MitM con http

Además del mecanismo en las respuestas anteriores, también puede usar los encabezados de respuesta http de la política de seguridad de contenido en la página principal.

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

Política de seguridad de contenido: script-src ''sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng =''

Hay algunas cosas a tener en cuenta aquí. El prefijo sha * - especifica el algoritmo utilizado para generar el hash. En el ejemplo anterior, se usa sha256-. CSP también es compatible con sha384- y sha512-. Al generar el hash no incluya las etiquetas. También son importantes las mayúsculas y los espacios en blanco, incluidos los espacios en blanco iniciales o finales.

Con Chrome 40 o posterior, puede abrir DevTools y luego volver a cargar su página. La pestaña Consola contendrá mensajes de error con el hash sha256 correcto para cada uno de sus scripts en línea.

Este mecanismo ha existido durante bastante tiempo, por lo que el soporte del navegador es bastante bueno, solo asegúrese de verificarlo.

Además, si desea asegurarse de que los navegadores antiguos no conformes no sean inseguros, puede incluir un script de redireccionamiento síncrono en la parte superior de la página que no esté permitido por la política.