Rischi per la sicurezza di manifesti ClickOnce senza firma

4

Utilizzando manifesti firmati nelle distribuzioni ClickOnce, non è possibile modificare i file dopo che il pacchetto di distribuzione è stato pubblicato - l'installazione avrà esito negativo poiché le informazioni hash nel file manifest non corrisponderanno ai file modificati. Recentemente mi sono imbattuto in una situazione in cui ciò era problematico: i clienti devono essere in grado di impostare le stringhe di connessione in app.config prima di distribuire il software ai propri utenti.

Ho risolto il problema deselezionando l'opzione "Firma i manifesti ClickOnce" in VS2010 ed escludendo esplicitamente il file app.config dall'elenco di file per generare gli hash generati durante il processo di pubblicazione.

Da una pagina correlata su MSDN

"Unsigned manifests can simplify development and testing of your application. However, unsigned manifests introduce substantial security risks in a production environment. Only consider using unsigned manifests if your ClickOnce application runs on computers within an intranet that is completely isolated from the internet or other sources of malicious code."

Nella mia situazione, questo non è un problema immediato: l'implementazione non sarà rivolta a Internet. Tuttavia, sono curioso di sapere quali sarebbero "i rischi sostanziali per la sicurezza" di ciò che avrei fatto se si fosse trattato di Internet (o se le cose fossero cambiate e dovessero esserlo in futuro).

Grazie in anticipo!

Modifica / follow-up:

non firma il manifest di ClickOnce costituisce un manifest non firmato (come da definizione di MSDN)? Il manifest dell'applicazione contiene un hash dei file nel pacchetto di distribuzione. Qualsiasi modifica ai file al suo interno provoca un errore di convalida durante l'installazione. Questo nega i rischi di sicurezza di cui sopra, del tutto?

    
posta Tom Tom 26.06.2013 - 18:29
fonte

1 risposta

6

Immagino che i rischi siano gli stessi di usare qualsiasi eseguibile senza segno. Il motivo per cui è corretto scaricare l'applicazione su una rete intranet è che ci si fida dell'hardware di rete (e delle persone che hanno accesso a tale hardware) che serve il file. Quando chiedi "Server foo.local , inviami bar.exe ", sai che foo.local è una macchina affidabile e anche tutti i router e gli switch tra te e foo.local sono degni di fiducia.

In una configurazione di distribuzione Internet, l'utente chiede foo.com di servire bar.exe . L'utente non ha un buon modo per essere sicuro che:

  • foo.com non ha manomesso il file
  • i suoi record DNS non sono stati manomessi per impedirgli di parlare con l'host giusto
  • che un utente malintenzionato sulla sua rete domestica non ha ARP avvelenato il router per reindirizzare e modificare il suo traffico

L'utente ottiene il file da una fonte fondamentalmente inaffidabile. Le firme digitali sono un modo per fornire fiducia anche quando la fonte di distribuzione è non affidabile . La firma è una garanzia sigillata al destinatario finale che questo file è esattamente quello prodotto dal firmatario originale.

In definitiva, il rischio non è che il file sarà in qualche modo meno affidabile quando raggiunge l'utente; il problema è che l'utente non può mai ricevere il tuo file, ma verrà invece inconsapevolmente fornito con un file diverso. Le firme digitali ti consentono di contrassegnare i tuoi file in modo univoco, in un modo che può essere verificato dall'utente finale. Qualsiasi agente malintenzionato che cerchi di fornire un sosia dannoso non sarà in grado di falsificare la tua firma. Tuttavia, se non hai una firma in primo luogo (o, ancora più importante, l'utente non è in attesa di una firma), allora non c'è modo di verificare che abbia ottenuto il file giusto.

    
risposta data 26.06.2013 - 20:32
fonte

Leggi altre domande sui tag