Integridad del sub-recurso para recursos del mismo origen (primera parte)

1

Casi todos los artículos que leí sobre integridad del sub-recurso cubren la carga de scripts (y CSS) de CDN y recursos de terceros, lo que tiene sentido.

¿Hay algún valor en agregar el atributo integrity a mis propios scripts (es decir, de primera persona)?

Mi sitio se sirve mediante HTTPS, por lo que los scripts no deben modificarse en tránsito (si un atacante puede modificar la información en tránsito desde mi servidor, entonces pueden modificar el HTML de todos modos).

Con respecto a las secuencias de comandos que se están modificando, creo que si un atacante puede modificar el contenido de los archivos en mi servidor, tengo problemas mucho mayores que los que puede proteger el SRI.

¿Debo dedicar tiempo a implementar SRI para scripts de primera persona? Ya tengo un proceso de compilación, por lo que no es difícil generar los hashes, pero rellenar las etiquetas <script> es un poco difícil en mi flujo de trabajo actual.

Sé que no es compatible con Microsoft Edge pero eso es un problema ortogonal de AFAIK.

    
pregunta rink.attendant.6 17.10.2016 - 04:38
fuente

2 respuestas

1

Estoy de acuerdo con su evaluación de que si los scripts se publican en el mismo servidor que HTML, integrity no le da mucha seguridad. Sería un compromiso extraño cuando el atacante lograra escribir en los archivos de secuencia de comandos pero no podría escribir en otros archivos, incluido HTML (o PHP, .jar, .dll, etc.).

Si el atacante puede modificar archivos en su servidor y desea cambiar el javascript que se sirve, solo puede eliminar o actualizar el atributo integrity en su HTML.

Si los scripts están saliendo de un servidor diferente (físico o virtual), el atributo integrity significará que el atacante debe comprometer ambas máquinas para cambiar el javascript.

    
respondido por el David Waters 17.10.2016 - 05:34
fuente
0

Los piratas informáticos no obtienen necesariamente el control total del servidor adivinando los detalles de registro. Pueden explotar un agujero de seguridad en una página específica y así obtener acceso a lo que tengan. Por lo tanto, podría haber un valor en agregar el atributo de integridad a los mismos scripts de origen, pero no hay garantía.

Estoy pensando en (para dominios alojados) simplemente tener un dominio extra (B) que se utiliza para almacenar copias de código de mis otros dominios (A). Y luego haga un cronjob en el dominio B, que verifica regularmente si el código es el mismo y envía una advertencia si no es así. Esto es para mantener las ventajas de los mismos scripts de origen y agregar algo de seguridad a los dominios A. Esto también es útil para páginas html completas con código js. El flujo de trabajo debe ser relativamente simple con la necesidad de actualizar el dominio B ingresando una URL del dominio A cada vez que se realicen cambios en la URL del dominio A.

    
respondido por el Hanne 21.10.2016 - 11:49
fuente

Lea otras preguntas en las etiquetas