Questo uso di System.Security.Principal.WindowsIdentity è ragionevolmente sicuro?

Question

È System.Security.Principal.WindowsIdentityragionevolmente al sicuro da essere violato in modo tale che un caso mi da Thread.CurrentPrincipal s' Identity o WindowsIdentity.GetCurrent() che ha true per IsAuthenticated dà il mio assemblaggio informazioni di identità falsa? Nulla, naturalmente, è completamente a prova di manomissione, ma dato l'impegno e la dipendenza di Microsoft da parte di .Net, mi aspetterei che API critiche come questa siano Locked Down Hard e difficili da manomettere. È un'ipotesi valida da parte mia?

Il mio obiettivo qui è quello di fornire un SSO ragionevole delle best-practice nel mio assieme. Se Windows è compromesso, questo è fuori dal mio controllo, ma se (per esempio) è una questione semplice per un'app che si collega al mio assembly per fornirmi informazioni false, sarebbe su di me per non aver fatto la dovuta diligenza. Questa è una grande area di ignoranza per me.

Per essere chiari, sto cercando informazioni difficili, non opinioni off-the-polsino. Quindi, exploit pubblicati, o uso dimostrativo di un costruttore WindowsIdentity in un modo che potrebbe ingannare il mio codice, ecc. O sul lato "questo è un presupposto valido", articoli solidi che lo supportano, usi noti che fanno affidamento su di esso, ecc. Ho avuto molta fortuna a trovarli, ma ho incluso quello che ho trovato finora sotto il divisorio.

Ecco come ho intenzione di usare WindowsIdentity:

using System.Security.Principal; 
using System.Threading; 
// ... 

// I only want Windows-authenticated users 
WindowsIdentity identity = Thread.CurrentPrincipal == null 
    ? null 
    : Thread.CurrentPrincipal.Identity as WindowsIdentity; 
SecurityIdentifier sid; 

// I can't imagine how an authenticated account would be anonymous, but... 
if (identity != null && identity.IsAuthenticated && !identity.IsAnonymous) { 
    // SSO success from thread identity 
    sid = identity.User; 
    // ...check that that SID is allowed to use our system... 
} else { 
    identity = WindowsIdentity.GetCurrent(); 
    if (identity != null && identity.IsAuthenticated && !identity.IsAnonymous) { 
     // SSO success from current Windows user 
     sid = identity.User; 
     // ...check that that SID is allowed to use our system... 
    } else { 
     // SSO fail 
    } 
} 

Questo è in un assembly DLL   — purtroppo siamo bloccati su .Net 3.5   — che fornisce un'API pubblica per le risorse che possono essere limitata dalla diritti utente. Potrebbe essere utilizzato nelle app desktop o in un'app di IIS di ASP.Net con autenticazione di Windows (ASP.Net imposta un'istanza WindowsIdentity su Thread.CurrentPrincipal.Identity quando si utilizza l'autenticazione di Windows, non supportiamo attualmente altri tipi di autenticazione di IIS).

Posso fidarmi ragionevolmente di un SID da un'istanza WindowsIdentity da quelle fonti che affermano di essere autenticati in questo modo?

E non si è verificato a me a chiedermi se andava più che bene (doh!) fino a quando nel this question utente lc. sollevato una preoccupazione che l'assemblea sarebbe suscettibile di essere ingannato da un'applicazione dannosa che collegava con esso e " falsificato "quell'informazione. Non aveva alcuna prova specifica per indicare perché potrebbe essere una preoccupazione significativa, però, quindi questa domanda.

---

Cosa (poco) che ho trovato finora:

• This answer fa l'affermazione

  ci si può fidare che l'attuale WindowsIdentity è che si dice che è, nella misura in cui dato che puoi fidarti di qualsiasi dato dato nella tua applicazione.

• Il libro sostiene che Hacking the Code ASP.Net richiede un WindowsIdentity essere associato a una richiesta quando si fa il controllo del file AUTORIZZO, che, se vero sembra una base abbastanza solida per dire Microsoft, almeno, lo considera abbastanza buono .

• Sono in grado di trovare molti esempi di persone che utilizzano felicemente le informazioni WindowsIdentity nel loro codice, ma la maggior parte di esse non pone la domanda se sono sicuri. C'è un implicazione, ma ...

Answer 1

Non ti puoi fidare l'uno da Thread.CurrentPrincipal, n. Non c'è niente che impedisca al codice di funzionare con piena fiducia dallo spoofing.

sono stato in grado di falsificare nel mio ambiente come questo:

var admin = new WindowsIdentity(@"Administrator"); 
var princ = new WindowsPrincipal(admin); 
System.Threading.Thread.CurrentPrincipal = princ; 

... prima di richiamare il codice. Sulla mia macchina, l'oggetto WindowsIdentity creato ha IsAuthenticated come true e IsAnonymous falso, e così, ovviamente, il codice estrae il SID dell'amministratore del mio dominio.

che non funziona in tutti gli ambienti, ma questo dovrebbe, a condizione che il codice in esecuzione ha autorizzazioni sufficienti per utilizzare riflessione: (. Ancora una volta, fatto prima di chiamare il codice)

var ident = WindowsIdentity.GetCurrent(); 
Thread.CurrentPrincipal = new WindowsPrincipal(ident); 
var userSid = ident.User; 

var fakeSid = new SecurityIdentifier("S-1-3-0"); 

typeof (WindowsIdentity).GetField("m_user", 
    BindingFlags.Instance | BindingFlags.NonPublic).SetValue(ident, fakeSid); 

---

Fondamentalmente, non c'è nulla per impedire che due pezzi di codice in esecuzione in Full Trust all'interno dello stesso processo si mentano l'uno sull'altro.