Come proteggere le DLL .NET

Question

Qual è la procedura migliore per proteggere le DLL dei progetti su cui si sta lavorando? Alcune DLL che sono interessato allo sviluppo avranno funzionalità DAL (data access layer) e BLL (business logic layer). Potrebbero esserci diverse app che possono eventualmente colpire queste DLL per eseguire funzioni specifiche di business.

Qual è il modo migliore per proteggere queste DLL in modo che possano essere utilizzate solo dalle applicazioni del creatore?

Sia per il blocco che per l'uso non autorizzato delle DLL e per la sicurezza contro l'eventuale decompilazione sono entrambi desiderabili.

Answer 1

Un'opzione potrebbe essere quella di contrassegnare tutte le classi esposte nella DLL come "interne" anziché "pubbliche", quindi utilizzare l'attributo "InternalsVisibleTo" nella DLL per denominare esplicitamente le DLL (ed eventualmente gli ex) che sono autorizzati a utilizzare i tuoi tipi interni Ciò potrebbe richiedere che tutti i partecipanti siano chiamati con il nome forte, ma è comunque una buona cosa da fare.

In definitiva, non esiste un modo assoluto per impedire a un determinato hacker di accedere al codice quando il codice è in esecuzione sul computer dell'hacker. Tutto il codice che può essere eseguito dalla macchina può essere smontato e riassemblato in qualcos'altro con strumenti ed esperienze sufficientemente avanzati.

Il modo migliore per avvicinarsi alla sicurezza del codice è porre la domanda "Quanto è difficile fare in modo che qualcuno usi questo codice senza licenza o autorizzazione e quanto tempo/denaro siamo disposti a spendere per raggiungere tale ?" Se non fai niente, è molto facile per qualcuno usare le tue DLL in qualche altro progetto. Se fai alcune semplici cose, puoi rendere scomodo per qualcuno usare le tue DLL altrove. Se investi mesi di sforzi, potresti essere in grado di rendere molto difficile per qualcuno abusare del tuo codice, ma non puoi mai renderlo impossibile.

Una tecnica che è il più vicino assolutamente sicuro che posso immaginare è: non eseguire il codice sul computer del cliente (o degli hacker). Esegui invece un servizio web e mantieni il tuo codice sul server dove un hacker non può licenziare casualmente un debugger sul tuo processo o smontare il tuo codice. La sicurezza del codice viene quindi definita dalla sicurezza fisica nella posizione del server e dalla sicurezza di accesso alla rete alle porte del server. Questi vettori di attacco sono molti ordini di grandezza più difficili da aggirare di qualsiasi cosa tu possa fare per eseguire codice sulla macchina dell'hacker.

Per alcune società di software, spostare una parte delle loro applicazioni dal client al cloud non significa ottenere una scalabilità migliore o aggiornamenti più semplici o costi inferiori, si tratta di sicurezza del codice e prevenzione della pirateria.

Answer 2

Stabilire l'autenticazione utilizzando il meccanismo Chiave aperta. Le funzioni nella DLL funzioneranno solo se fornisci una chiave valida e il token.

Answer 3

Se qualcuno ha accesso alla macchina con tutti quegli assembly, è necessario preoccuparsi più di qualcuno che li riutilizzi, potrebbero semplicemente accedere direttamente al database anziché utilizzare l'assembly.

Se si tratta di un'applicazione desktop o qualcosa del genere e si accede direttamente al database, è necessario ripensare la propria applicazione, accedere ai dati tramite servizi Web o altro anziché accedere direttamente al database.

Answer 4

La protezione della proprietà intellettuale non è realmente possibile se la spedisci nel formato DLL di .NET a un client. È possibile ospitare la logica dell'applicazione nel cloud, sebbene ciò potrebbe non essere adatto allo scenario.

Anche i "migliori" offuscatori non sono infallibili.Probabilmente potresti rimandare un hacker occasionale, ma come dice dthorpe, se qualcuno vuole veramente decompilare i tuoi assemblaggi, lo faranno.