Comprender la integridad de los subrecursos

1. Un poco de historia
2. ¿Qué puede salir mal?
3. Ingrese a la integridad del subrecurso
4. Probarlo
5. Cómo utilizar el SRI en sus propios proyectos
6. Generando hashes
7. Otras cosas a tener en cuenta
8. Conclusión

Cada fragmento de JavaScript que agregas a un sitio es una posible vía de entrada para un hacker. Esto es doblemente cierto si ese JavaScript está alojado en otra persona, como en una CDN pública. Subresource Integrity es una función del navegador que puede utilizar para asegurarse de que el código que se utiliza sea exactamente el deseado.

Si alguna vez ha utilizado una versión alojada en CDN de una biblioteca JavaScript, es posible que haya notado un integrityatributo de aspecto extraño en la etiqueta del script. Este atributo contiene basura alfanumérica aparentemente infinita que puede verse tentado a eliminar en la búsqueda de un código más limpio.

Toda esa basura es en realidad una característica de seguridad realmente útil llamada Subresource Integrity (SRI) que puede ayudar a defender su sitio contra ciertos tipos de ataques y compromisos. En este artículo, veremos qué es SRI, cómo puede ayudarlo a protegerse y cómo puede comenzar a usarlo en sus propios proyectos, no solo para archivos alojados en CDN.

Un poco de historia

En los días en que JavaScript era el primo más pobre de HTML y CSS, no necesitábamos pensar demasiado en cómo nuestros scripts podrían usarse como vector de ataque para nuestros sitios web. La mayoría de los sitios estaban alojados en un único servidor físico en algún lugar de nuestra propia infraestructura de alojamiento, y era el servidor que pensábamos defender cuando se trataba de las mejores prácticas de seguridad.

A medida que los navegadores se volvieron más capaces y las conexiones de red aumentaron, comenzamos a usar cada vez más JavaScript y, finalmente, comenzaron a surgir bibliotecas de JavaScript reutilizables. En aquellos primeros días, bibliotecas como script.aculo.us, Prototype y, finalmente, jQuery comenzaron a ser adoptadas entre los desarrolladores que buscaban agregar más interactividad a sus páginas.

Con estas bibliotecas agregadas y complementos posteriores, se agregó peso a la página y, en poco tiempo, comenzamos a pensar seriamente en el rendimiento del front-end. Recursos como las redes de entrega de contenido (CDN), que anteriormente habían sido reserva de corporaciones gigantes, se estaban convirtiendo en algo común para la gente común que creaba sitios web ágiles.

En el camino, una chispa brillante notó que todos los sitios solicitaban sus propias copias de bibliotecas comunes (cosas como el último jQuery) y si había una versión CDN común de esas bibliotecas que pudiera ser utilizada por todos los sitios, entonces el usuario no la usaría. No es necesario seguir descargando el mismo archivo. Recibirían el golpe por el primer sitio que usara el archivo, pero luego se guardaría en la caché de su navegador local y se podrían omitir las descargas para cada sitio posterior. ¡Genio!

Es por eso que verá enlaces CDN para sus bibliotecas favoritas usando URL como jsdelivr.com: están utilizando un CDN común para alojar los archivos para que sus usuarios vean los beneficios de rendimiento.

¿Qué puede salir mal?

Esta sigue siendo una forma buena y práctica de trabajar, pero introduce un vector potencial de ataque. Imaginemos que estamos en 2012 y todo el mundo está usando el nuevo jQuery 1.8. Volviendo a la forma tradicional de hacer las cosas, todos tendrían su propio archivo jQuery 1.8 alojado como parte de su propio sitio web en su propio servidor.

Si fueras una especie de actor malvado (como una especie de Hamburglar basado en jQuery) y hubieras descubierto una forma astuta de piratear la biblioteca para obtener tus propios beneficios malvados, tendrías que apuntar a cada sitio web individualmente y comprometer sus servidores para tener cualquier impacto. Eso es mucho esfuerzo.

Pero las cosas no son así ahora, ya que todo el mundo utiliza jQuery cargado desde una CDN común. Y cuando digo todos, no me refiero a cientos de páginas web. Me refiero a millones de páginas web. De repente, ese archivo se ha convertido en un objetivo muy atractivo para nuestro turbio hacker. Si pueden comprometer ese archivo, muy rápidamente podrán ejecutar código en millones de páginas web en todo el mundo.

No importa cuál sea ese código. Podría ser una broma para desfigurar páginas, podría ser un código para robar sus contraseñas, podría ser un código para extraer criptomonedas o podrían ser rastreadores furtivos que lo seguirán por la web y crearán un perfil de marketing. Lo importante es que el archivo inocente que el desarrollador agregó a una página ha sido cambiado y ahora tienes JavaScript maligno ejecutándose como parte de tu sitio. Ese es un gran problema.

Ingrese a la integridad del subrecurso

En lugar de hacer retroceder el tiempo y abandonar una forma útil de utilizar el código, SRI es una solución que añade un nivel simple de seguridad. Lo que hace SRI y el integrityatributo es asegurarse de que el archivo que vinculó a una página nunca cambie. Y si cambia, el navegador lo rechazará.

Comprobar que el código no ha cambiado es un problema muy antiguo en informática y afortunadamente tiene algunas soluciones muy bien establecidas. SRI hace un buen trabajo al adoptar el hash de archivos más simple.

El hash de archivos es el proceso de tomar un archivo y ejecutarlo a través de un algoritmo que lo reduce a una representación de cadena corta, conocida como hash o suma de comprobación. Sin entrar en detalles, el proceso es repetible o reversible, tanto que si le dieras a otra persona un archivo junto con el hash, podría ejecutar el mismo algoritmo para comprobar que los dos coinciden. Si el archivo cambia o el hash cambia, entonces ya no hay coincidencia y usted sabe que algo anda mal y debe desconfiar del archivo.

Cuando se utiliza SRI, su página web contiene el hash y el servidor (CDN o cualquier lugar) contiene el archivo. El navegador descarga el archivo y luego lo calcula rápidamente para asegurarse de que coincida con el hash del integrityatributo. Si coincide se utiliza el archivo, y si no se bloquea.

Probarlo

Si voy getbootstrap.comhoy para obtener un enlace CDN a una versión de Bootstrap, obtengo una etiqueta similar a esta:

script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"/script

Puede ver que el srcatributo es como estamos acostumbrados y integrityque contiene lo que ahora sabemos que es un hash. Curiosidades y tops de internet

En realidad, el hash se divide en dos partes. El primero es un prefijo para declarar qué algoritmo hash utilizar. En este caso, es sha384. A esto le sigue un guión y luego el propio hash, codificado con base64.

Quizás le resulte familiar base64una forma de codificar archivos en línea, como imágenes, en páginas. No es un proceso criptográfico, es simplemente una forma rápida y conveniente de codificar datos potencialmente desordenados de una manera que se traduce claramente a ASCII. Por eso se utiliza mucho en la web.

Al ver esto, el navegador descargará bootstrap.min.js. Antes de ejecutarlo, decodificará base64el hash y luego utilizará el sha384algoritmo de hash para confirmar que el hash coincide con el archivo que acaba de descargar. Si coincide, se ejecuta el archivo.

Puedo probar esto colocando esa etiqueta en una página y luego pasando a la pestaña Red en las herramientas de mi navegador para ver que el archivo se ha cargado.

Puedo ver que bootstrap.min.js(y también el archivo jQuery que necesita) se han cargado correctamente.

Veamos qué pasaría si actualizo el hash para que sea algo que sé que es incorrecto.

script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-SmashingMagazineIsCoolForCats" crossorigin="anonymous"/script

Como puede ver, el hash especificado en mi página ya no coincide con el archivo, por lo que el archivo se bloquea.

Cómo utilizar el SRI en sus propios proyectos

Tener esta capacidad para bibliotecas en una CDN es excelente, y si ve la opción de usar un archivo incrustado con un integrityatributo, entonces definitivamente debería favorecer esa opción. Pero no se limita a grandes proyectos en CDN, puede usarlo usted mismo para sus propios sitios.

No es nada descabellado imaginar un escenario en el que un hacker consiga acceder a sólo unos pocos archivos de su sitio. Creo que la mayoría de nosotros hemos visto a un cliente, colega o amigo que en algún momento tuvo un sitio de WordPress comprometido con un montón de basura desagradable que ni siquiera sabía que estaba allí.

El SRI también puede protegerte de esto. Si genera hashes de integridad para sus propios archivos, puede hacer que su sitio rechace cualquier cambio tal como lo haría con un archivo alojado de forma remota.

Generando hashes

Como era de esperar, puede ejecutar algunos comandos en la terminal de su computadora para generar un hash para un archivo. Este ejemplo de cómo hacerlo proviene de la página MDN Subresource Integrity :

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

Eso es obtener el contenido FILENAME.jsy pasarlo como entrada para opensslcrear un resumen usando sha384, que luego se pasa como entrada a otro opensslcomando para base64codificar el resultado. Esto no sólo es complicado y oscuro, sino que tampoco es el tipo de cosas que deseas hacer a mano cada vez que cambia tu archivo JavaScript.

Lo que es más útil es que querrás integrar esto de alguna manera en el proceso de creación de tu sitio y, como puedes imaginar, hay muchas opciones listas para usar allí. La implementación exacta variará enormemente según su proyecto, pero aquí hay algunos elementos básicos.

Si usa Gulp para crear sus sitios, existe gulp-sri que generará un archivo JSON con una lista de sus archivos y sus hashes. Luego podrá utilizar esto en su sitio. Por ejemplo, para un sitio renderizado dinámicamente, puede crear un complemento de plantilla para leer ese archivo y agregar los hashes a sus plantillas cuando sea necesario.

Si todavía está con Gulp pero tiene un sitio estático (o un sitio generado estáticamente), puede usar gulp-sri-hash , que realmente se ejecutará en sus páginas HTML y las modificará para agregar hashes cuando sea necesario, lo cual es muy útil.

Si está utilizando Webpack, existe la integridad de los subrecursos de la página web que, en el verdadero estilo de Webpack, es más compleja de lo que cualquier ser humano podría esperar, pero parece funcionar.

Para aquellos que usan el motor de plantillas de manillar, parece haber opciones disponibles , y si su proceso de compilación es solo JavaScript básico, también existen soluciones simples .

Si está utilizando un CMS como WordPress, encontré un complemento que parece hacerlo fácil, aunque no lo he probado yo mismo. Buscar en Google su propia plataforma de elección con SRI o Sub Resource Integrity probablemente le indicará la dirección correcta.

Básicamente, desea conectar su hash después de que sus archivos JavaScript hayan sido minimizados y luego hacer que ese hash esté disponible de alguna manera para cualquier parte de su sistema que genere las scriptetiquetas. Una de las maravillas de la plataforma web es que es muy diversa desde el punto de vista técnico, pero eso, lamentablemente, me impide darte buenas instrucciones de implementación.

Otras cosas a tener en cuenta

En este artículo, he hablado mucho sobre los archivos JavaScript porque es allí donde realmente tiene más sentido defenderse contra los ataques de piratería. SRI también funciona con CSS, por lo que puedes usarlo exactamente de la misma manera allí. El riesgo de CSS malicioso es mucho menor, pero la posibilidad de desfigurar un sitio aún existe y quién sabe qué errores del navegador también podrían llevar a que CSS exponga inadvertidamente su sitio a un hacker. Así que allí también funciona el SRI.

Otra cosa interesante que puedes hacer es usar una Política de seguridad de contenido para especificar que cualquier script (o estilo) en tu página debe usar SRI y, por supuesto, ese SRI debe validarse.

Content-Security-Policy: require-sri-for script; 

Esta es una forma de garantizar que siempre se utilice SRI, lo que podría ser útil en sitios en los que trabajan varios miembros del equipo que pueden o no estar completamente al tanto de cómo hacer las cosas. Nuevamente, un buen lugar para leer más sobre esto son los siempre excelentes documentos de MDN para Subresource Integrity .

Lo último de lo que vale la pena hablar es de la compatibilidad del navegador con SRI. La compatibilidad con los navegadores modernos es amplia, con la principal excepción de Internet Explorer. Sin embargo, debido a la forma en que se implementó la especificación, que es compatible con versiones anteriores, es seguro utilizarla inmediatamente. Los navegadores que comprendan el integrityatributo utilizarán el hash y comprobarán la integridad, y los navegadores más antiguos seguirán como siempre y seguirán funcionando. Por supuesto, no obtendrá protección adicional en esos navegadores más antiguos, pero sí en los navegadores que sí ofrecen soporte.

Conclusión

Hemos visto no sólo lo que integrityhacen esos extraños hashes en los atributos, sino también cómo podemos usarlos para defendernos contra ciertos tipos de ataques en nuestro sitio web. Por supuesto, no existe una solución milagrosa que defienda nuestros sitios contra todo tipo de exploits, pero Subresource Integrity es una herramienta realmente útil en la cadena.

Explotar una falla de seguridad a menudo consiste en alinear varias piezas pequeñas. Si A está en su lugar y usted puede hacer que B suceda, entonces un error en C hace posible D. Las funciones del navegador como SRI nos brindan una buena manera de atar las cosas un poco más y potencialmente romper esa cadena y evitar que un pirata informático obtenga lo que quiere. Es más, si puede integrarlo en su proceso de compilación o CMS, es algo que debería poder configurar una vez y luego olvidarse y no le causará inconvenientes en el día a día.

Como tal, realmente recomendaría analizar seriamente Subresource Integrity e implementarlo en sus sitios si puede.

(yk, il)Explora más en

• javascript
• Actuación
• Seguridad

Tal vez te puede interesar:

1. ¿Deberían abrirse los enlaces en ventanas nuevas?
2. 24 excelentes tutoriales de AJAX
3. 70 técnicas nuevas y útiles de AJAX y JavaScript
4. Más de 45 excelentes recursos y repositorios de fragmentos de código

Comprender la integridad de los subrecursos

Un poco de historia¿Qué puede salir mal?Ingrese a la integridad del subrecursoProbarloCómo utilizar el SRI en sus propios proyectosGenerando hashesOtras cos

programar

es

https://aprendeprogramando.es/static/images/programar-comprender-la-integridad-de-los-subrecursos-978-0.jpg

2025-01-14

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente