Distribuisci codice sorgente webapp verificabile

Question

Distribuisci codice sorgente webapp verificabile

#1 da (1 voti)
#2 da (0 voti)

0

Recentemente ci sono state alcune discussioni sull'approccio alla sicurezza di ProtonMail. Dato che fa crypto roba sul lato client, caricando il codice javascript nel browser dell'utente, per quanto ne so, anche se quel codice è pubblicato da qualche parte su Internet, non c'è alcuna garanzia che non sia stato manipolato da un'entità malvagia con l'accesso amministratore al server prima che l'utente lo usi effettivamente.

Quindi, in generale, la domanda è: come posso sviluppare software open source e consentire all'utente finale di verificare se il codice dietro a quel software è lo stesso pubblicato?

In caso di software compilato posso usare build riproducibili firmati, ma in caso di codice interpretato (ad esempio JavaScript come in ProtonMail) cosa posso fare?

Dalla mia conoscenza di base della programmazione e della crittografia, proverei a risolvere questa situazione aggiungendo al codice pubblicato l'impronta digitale di, diciamo, ogni file sorgente. Tale impronta digitale dovrebbe essere firmata dallo sviluppatore. A questo punto, quando l'utente scarica il codice mentre accede al servizio web, può calcolare l'impronta digitale e confrontarla con quella pubblica. È un approccio praticabile? Mi manca qualcosa?

Grazie in anticipo!

P.S. Ho già letto alcune altre domande come questo e penso che ancora non completa risposta a questa domanda.

cryptography code-signing programming checksum

posta hwktest 09.12.2018 - 18:47

fonte

2 risposte

Leggi altre domande sui tag cryptography code-signing programming checksum

Esiste un formato 'Apri contenitore file crittografato'? L'exploit descritto in A Monitor può essere applicato a computer portatili e smartphone / tablet?

score 1 · Answer 1

Da MDN web docs:

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match.

L'idea è di generare un hash dai tuoi file di app web (ad esempio file javascript) usando comandi come openssl o shasum e specificare la funzione di hash come come (sha256, sha384 e sha512) che sono i prefissi consentiti correnti e quindi incorporare il digest di hash generato nello script di esecuzione dell'utente tramite l'attributo del valore integrity . Il browser deve prima confrontare lo script con l'hash previsto e verificare che vi sia una corrispondenza.

Se lo script non corrisponde al valore integrità associato, il browser rifiuterà di eseguire lo script indicando che non è lo stesso codice sorgente, probabilmente a causa di un errore di rete o di manipolazione imprevista dei file.

Generazione dell'hash digest sull'esempio "FILENAME.JS" utilizzando il comando openssl :

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

E prima di eseguire lo script FILENAME.js sul lato utente, è necessario incorporare l'hash generato attraverso il valore integrity nel tag script, affinché il browser convalidi l'hash dello script al previsto hash.

Per maggiori informazioni:

link

score 0 · Answer 2

Risposta breve: non puoi.

Presumo che tu stia parlando specificamente delle applicazioni fornite tramite un browser.

Il certificato SSL sul tuo server dimostra che il codice è venuto da lì. E come suggerisce Hussein, l'uso della sub-resource integrity rafforza la validità dell'origine, consentendo anche problemi di cache e CDN, ma non c'è nulla che impedisca la manomissione a monte del codice.

Microsoft ha firmato ActiveX come se fosse stato progettato per risolvere l'integrità della catena di consegna completa, ma sappiamo quanto sia stato efficace. La maggior parte dei browser supporta ancora l'esecuzione del codice Java firmato, ma ora è il 2018.

From my very basic knowledge of programming and cryptography,

Ciò che proponi è un approccio credibile (anche se vedi i miei commenti precedenti su Java e ActiveX) ma al momento, per implementarlo, dovresti apportare modifiche al modo in cui sia HTML che HTTP funzionano al momento per supportare questo con applicazioni on-demand. O quello o sviluppa il tuo protocollo e client.

Suppongo che sarebbe possibile utilizzare un'intestazione personalizzata e un'estensione del browser - ma devi ancora pensare a come un client dovrebbe sapere quando si connette a un servizio che implementa questo tipo di sicurezza elevata rispetto al modo in cui ha bisogno di tratta il resto di Internet.

L'utilizzo di un'app HTML5 cambia molto il paesaggio e riduce la superficie di attacco, ma non risolve il problema.

(A proposito se il tuo Javascript non viene compilato allora stai sbagliando)