2009-05-13 10 views

risposta

8

vi consiglio di leggere Strong name assemblies can keep you out of DLL Hell:

assemblee nome sicuro consentono agli sviluppatori di semplificare componenti aggiornamenti ed evitare la famigerata DLL Inferno. Scopri l'anatomia dei nomi forti e scopri come utilizzare per garantire la compatibilità della versione e la sicurezza nelle app .NET.

Vedere anche this article per un breve tutorial su come assegnare un nome sicuro a un assembly.

+3

Primo collegamento interrotto –

2

Può anche essere utilizzato per garantire che l'assembly non venga manomesso poiché è stato rilasciato dall'editore originale.

+1

Ma manca un modo per verificare l'editore originale. Per quello dovresti usare una tecnologia come AuthentiCode in aggiunta. Lo scopo principale è tuttavia quello di creare nomi univoci ("forti") per identificare una versione specifica di un assembly (per risolvere i problemi di "DLL Hell" http://msdn.microsoft.com/en-us/library/ms811694 .aspx) –

+0

@divo: Certamente. Questo è menzionato nella risposta di Andrew. Non ho visto la necessità di duplicare. Volevo solo aggiungere questa possibilità. Ho menzionato questo fatto in dettaglio in questa risposta: http://stackoverflow.com/questions/369248/can-strong-naming-an-assembly-be-used-to-verify-the-assembly-author/369268#369268 –

1

Ho scritto una lunga risposta delineando quanto fortemente la denominazione di un assembly impedisca a terzi di manomettere l'assembly come risposta a questo question. Può essere utile se vuoi il come pure e il perché.

+1

Questo è vero. Tuttavia questo non è stato l'aspetto principale quando è stata progettata una denominazione forte. Nomi forti non hanno caratteristiche importanti come l'autenticazione e la revoca dell'editore. Se si desidera una distribuzione a prova di manomissione degli assembly, è molto meglio fare affidamento sui certificati digitali (come Authenticode) –

0

Penso che una delle caratteristiche importanti che evita il dirottamento della DLL (o qualsiasi altra cosa si chiami) a causa di potenziali autorizzazioni deboli.

Si supponga che una delle DLL nella propria applicazione possa essere scritta da "tutti" in quel caso qualcuno può semplicemente modificarlo e quando un utente con privilegi elevati esegue l'attacco di un'applicazione .NET può elevare i propri privilegi.

Questo è piuttosto interessante perché nel mondo reale è possibile vedere questi attacchi contro applicazioni quali Anti virus e altre app complesse che si basano su diverse DLL in diverse posizioni.

Problemi correlati