Perché le mie pagine ASP.NET restituiscono `200 OK` senza che vengano inviate intestazioni di autenticazione?

Question

Nota:

  

Questa domanda si è ampliata nell'ambito delle revisioni precedenti. Ho cercato di semplificare il problema in modo che possa essere facilmente riprodotto da chiunque.

Utilizzando Fiddler , posso riprodurre una richiesta arbitraria sulla mia pagina predefinita dopo aver cancellato il mio Autorizzazione dalla richiesta HTTP e sono in grado di ottenere una risposta di 200 OK con dati validi.

Aggiornamento di taglie

Ecco i passaggi per riprodurre questo comportamento esatto:

1. Crea un " Nuovo sito web " in ASP.NET, sentiti libero di nominarlo " Sito web insicuro "

2. Modifica web.config per negare a tutti gli utenti non autenticati:

<authentication mode="Windows" />
  <authorization>
    <deny users="?"/>
  <allow users="*"/>
</authorization>

3. Pubblica il sito Web in una directory arbitraria su un server DEV e crea una directory virtuale per l'applicazione

4. Assicurati che l'applicazione abbia accesso agli script (.ASP) e autenticazione integrata di Windows abilitata

5. Apri Fiddler per acquisire il traffico

6. Carica la pagina nel tuo browser preferito e guarda " Inspector " nella scheda Fiddler , vedrai una richiesta simile a:

GET /InsecureWebsite/ HTTP/1.1
Host: dev.subdomain.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Authorization: NTLM
{Base64-encoded authentication data}

La richiesta iniziale di Default.aspx restituirà un 401 non autorizzato , entrerà in negoziazione e infine restituirà un 200 OK .

In Fiddler posso quindi cancellare l'intestazione Autorizzazione direttamente da una richiesta riprodotta su Default.aspx e ottenere ancora un 200 OK . Com'è possibile?

Soluzione

Si scopre che Fiddler usa la stessa connessione sottostante quando effettua le richieste, quindi una volta che la connessione è autenticata, anche qualsiasi richiesta sulla stessa connessione verrà autenticata come lo stesso utente della richiesta iniziale. Puoi disattivare questa funzione in Fiddler qui:

Schermata delle opzioni di Fiddler http://john.cognitivedelay.com/images/fiddler -options.gif

Una volta deselezionata, tutte le richieste riprodotte da Fiddler restituiranno un 401 non autorizzato come mi sarei aspettato.

Grazie a tutti coloro che hanno offerto il loro tempo per rispondere!

Answer 1

Modifica: per domanda aggiornata:

Stai eseguendo il replay in Fiddler stesso o effettuando una connessione diretta al server web? È possibile che Fiddler stia riutilizzando una connessione HTTP esistente (cosa che può fare, come proxy) ... Penso che IWA potrebbe contrassegnare l'intera connessione come autenticata, non solo la richiesta corrente, il che significa che eventuali richieste future sulla stessa connessione riutilizzare l'autorizzazione e l'autenticazione dalla prima negoziazione ...

Risposta originale: Prova

[WebMethod(EnableSession=true)]  
[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]

e vedere se questo aiuta?

(Forse [PrincipalPermission (SecurityAction.Demand, Role = " myDevRole ")] se è più appropriato per te ...)

Answer 2

La chiamata Ajax viene eseguita su un nuovo thread per una sessione autenticata esistente, ecco perché non vedi alcuna informazione di autenticazione nelle intestazioni. La sessione è già autenticata.

È possibile ottenere l'identità dell'utente autenticato, quindi passarla a qualsiasi routine di gestione dei ruoli, facendo riferimento a System.Threading.Thread.CurrentPrincipal.Identity.Name:

[WebMethod(EnableSession = true)]   
public static string WhoAmI()
{
    // Return the identity of the authenticated windows user.
    Return System.Threading.Thread.CurrentPrincipal.Identity.Name;
 }

Answer 3

Potresti potenzialmente aggiungere informazioni di autenticazione all'intestazione del messaggio, quindi autenticarti nel metodo web.

oppure potresti provare qualcosa del tipo questo o questo

Answer 4

Aggiungi questo attributo al metodo web [PrincipalPermissionAttribute (SecurityAction.Demand, Role = " myDevRole ")] .

Quindi, nell'evento Global.asax Application_AuthenticateRequest puoi assicurarti che l'attuale utente del thread sia autenticato correttamente, ovvero fare ciò che è necessario per evitare cookie o sessioni fraudolenti.

Answer 5

Utilizzando l'autenticazione di Windows sul tuo computer di sviluppo locale, ogni richiesta proviene da un utente autenticato. Quindi, nega gli utenti = "? & Quot; non negherà mai alcuna richiesta a livello locale.

Se lo colpissi su un computer IIS remoto con il quale non sei autenticato o dovessi utilizzare Forms Authentication, richiederebbe l'autenticazione prima che tu possa richiedere correttamente Default.aspx o il metodo page.