Implementar código fuente de aplicación web verificable

De los documentos web de MDN:

  

La integridad del sub-recurso (SRI) es una característica de seguridad que habilita   navegadores para verificar que los recursos que obtienen (por ejemplo, de un CDN)   Se entregan sin manipulación inesperada. Funciona permitiendo   para proporcionar un hash criptográfico que un recurso recuperado debe   partido.

La idea es generar un hash a partir de los archivos de su aplicación web (por ejemplo, archivos javascript) mediante el uso de comandos como openssl o shasum , y especificar la función de hash como as (sha256, sha384 y sha512), que son los prefijos permitidos actuales, y luego incrustar el resumen de hash generado en el script de ejecución del usuario a través del atributo de valor integridad . El navegador debe primero comparar el script con el hash esperado y verificar que haya una coincidencia.

Si la secuencia de comandos no coincide con su valor integridad asociado, el navegador se negará a ejecutar la secuencia de comandos, lo que indica que no es el mismo código fuente, probablemente debido a un error de red o una manipulación inesperada del archivo.

Generando un resumen de hash al ejemplo de "FILENAME.JS" usando el comando openssl :

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

Y antes de ejecutar el script FILENAME.js en el lado del usuario, debe incrustar el hash generado a través del valor integridad en su etiqueta de script, para que el navegador valide el hash del script al valor esperado. hash.

Para más información:

enlace

Respuesta corta: no puedes.

Supongo que está hablando específicamente de aplicaciones entregadas a través de un navegador.

El certificado SSL en su servidor prueba que el código vino de allí. Y, como sugiere Hussein, el uso de la integridad de los sub-recursos refuerza la validez del origen al tiempo que permite el almacenamiento en caché y los problemas de CDN, pero no hay nada que impida la manipulación del código en sentido ascendente.

El ActiveX firmado por Microsoft parece que fue diseñado para abordar la integridad de la cadena de entrega completa, pero sabemos cuán efectivo ha demostrado ser. La mayoría de los navegadores aún admiten la ejecución de código Java firmado, pero ahora es 2018.

  

De mis conocimientos básicos de programación y criptografía,

Lo que propones es un enfoque creíble (aunque vea mis comentarios anteriores sobre Java y ActiveX) Pero actualmente, para implementar esto, deberías hacer cambios en la forma en que funcionan actualmente HTML y HTTP para poder admitir Esto con aplicaciones bajo demanda. O eso o desarrollar su propio protocolo y cliente.

Supongo que sería posible usar un encabezado personalizado y una extensión del navegador, pero aún debe pensar cómo un cliente sabría cuándo se está conectando a un servicio que implementa este tipo de seguridad elevada en comparación con la forma en que necesita tratar el resto de internet.

El uso de una aplicación HTML5 ciertamente cambia mucho el paisaje y reduce la superficie de ataque, pero aún así no resuelve el problema.

(Por cierto, si no se está compilando tu Javascript, lo estás haciendo mal)