Livello di Full Trust: dovrebbe essere una preoccupazione?

Assegna sempre solo i privilegi di cui hai veramente bisogno.

Diciamo che lavori in un'azienda. Il tuo lavoro è limitato alla stanza A e B e potresti, a volte, andare nella stanza E. Se ti viene dato l'accesso alla stanza C, D e F, significa che se succede qualcosa di sbagliato in quelle stanze, sarà tra i sospetti. Per limitare i rischi per l'azienda e, allo stesso tempo, renderti più sicuro lavorare lì, ti verranno forniti solo gli accessi di cui hai effettivamente bisogno o potrebbero averne bisogno, ma solo quelli.

Il codice sorgente è la stessa cosa. Quando tutto ha accesso completo e succede qualcosa di sbagliato, non hai idea di cosa sia successo. Se, d'altra parte, il file protetto è stato modificato mentre il file può essere modificato solo da due persone nell'azienda e da un'applicazione specifica, sai che una di quelle persone ha fatto qualcosa di sbagliato, o che i loro account sono stati compromessi o che l'applicazione specifica è stata compromessa. Diventa molto più facile trovare la causa principale del problema e essere molto reattivo verso una minaccia alla sicurezza .

Esistono altri motivi per utilizzare il trust parziale:

• Il codice che scrivi potrebbe essere diverso da quello che intendevi. Immagina di creare uno strumento che sincronizzerà i file in alcune directory mission-critical ogni dieci minuti dalla macchina A alla macchina di backup B. Hai finito la versione n ⁱ della app in ritardo la sera e chiedi erroneamente allo strumento di rimuovere i file di origine dalla macchina A. Fai anche alcuni errori in modo che non copi i file da A a B. Se lavori in un trust parziale dove l'applicazione non può rimuovere alcun file da nessuna parte, mai, fallirà con grazia. Invece, in piena fiducia, farà del male, poi dirà che ci è riuscito, permettendoti di scoprire le conseguenze giorni dopo.

• Puoi utilizzare componenti di terze parti che non sempre ti fidi o non puoi verificare. Steven ha già discusso di questo punto.

• Le applicazioni di trust parziali possono essere eseguite nel contesto in cui l'utente, eseguendo l'applicazione, ha anche un trust parziale. Si applica agli utenti ordinari, così come a IIS, demoni (servizi Windows), ecc. Se scrivi la tua app per un trust parziale, sei consapevole delle insidie. Se la tua applicazione è progettata per essere eseguita con piena fiducia e viene avviata da un utente con un set di autorizzazioni molto limitato, cosa succederà?

• Lavorare in un trust parziale ti costringe a imparare cose che di solito non usi in pieno contesto di fiducia. Ad esempio, che dire di IsolatedStorage ? I vantaggi dell'archiviazione isolata non sono limitati al contesto di fiducia parziale (astrazione del modo in cui le informazioni vengono archiviate, assicurandosi che altre applicazioni non dannose non accedano o sovrascrivano mai le informazioni inserite, ecc.), Ma la funzionalità è spesso ignorato da persone che lavorano in completa fiducia.

• Alcuni contesti ti costringono a usare un trust parziale. Silverlight è un esempio.

• Se il tuo codice a piena fiducia accetta plug-in, è una minaccia per la sicurezza. A meno che non determini in modo specifico le autorizzazioni concesse al codice plugin che viene eseguito nella sandbox (che presenta anche alcuni problemi , ad esempio, non è ovvio per i plug-in sandbox modificare l'interfaccia utente , così come potresti incontrare Alcuni problemi quando si utilizza la cache ), il codice dei plugin viene eseguito con gli stessi privilegi dell'applicazione. Dato che questi plugin possono essere scritti da una terza parte e contenere codice dannoso, l'utente incolperà la tua app e non il plug-in di fare del male.

L'esecuzione in completa attendibilità è in genere un problema solo quando si consente all'applicazione di eseguire codice che è stato scritto fuori dal proprio controllo. Ad esempio, quando scarichi il codice da Internet, ti piace questo sandbox e questo è il motivo per cui si ha fiducia parziale. Per il tuo ISP, non conoscono il tuo codice e amano essere in grado di eseguire la sandbox, dal momento che non hanno idea di che tipo di cose pazze stai facendo, o di consentire ad altri di fare. Ad esempio, l'applicazione potrebbe eseguire la compilazione al volo del codice C # (estratto dal database) ed eseguirlo. Quando un hacker è in grado di (SQL) iniettare questo codice C # nel tuo database, sarà in grado di fare assolutamente qualsiasi cosa all'interno di quel processo (che è parecchio).

Ma ho una domanda per te:

Do you trust your 3rd party components?

Ti piace correre in piena fiducia. Perché? Quale codice hai scritto ha bisogno di piena fiducia? O sono i componenti di terze parti che hanno bisogno di piena fiducia? Perché hanno bisogno di piena fiducia? Forse stai usando un componente di terze parti che è in grado di convertire documenti Word in PDF o viceversa e ha bisogno di piena fiducia. Ciò mi sembra piuttosto spaventoso, dal momento che un hacker potrebbe essere in grado di iniettare un documento non valido che attiva un'eccezione di sovraccarico del buffer, cosa che potrebbe essere possibile quando il componente utilizza il codice unsafe (che richiede piena attendibilità). In tale scenario, preferirei non utilizzare un componente del genere, poiché potrebbe costituire una seria minaccia per la tua applicazione. O dovresti eseguire il sandbox su quel componente da eseguire con fiducia parziale in un diverso AppDomain.

Il miglior consiglio che posso darti è di fare la modellazione del filo. Guarda attentamente i confini del tuo sistema. Quali sono gli input Quali sono le uscite. Quali sono i rischi. Questa è un'informazione essenziale per sapere come mitigare il rischio.