EnableHeaderChecking=true è sufficiente per prevenire attacchi Http Header Injection?

StackOverflow https://stackoverflow.com/questions/869361

  •  22-08-2019
  •  | 
  •  

Domanda

È sufficiente avere [System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking](http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx) impostato true (impostazione predefinita) per prevenire completamente gli attacchi Http Header Injection come Response Splitting ecc.?

Lo chiedo perché uno strumento di test di penetrazione white box (fortify) segnala problemi di iniezione di intestazioni http sfruttabili con HttpResponse.Redirect e cookie ma non ho trovato un modo per eseguire con successo un attacco.(modificare:..e abbiamo attivato EnableHeaderChecking..)

È stato utile?

Soluzione

Lo sto osservando da un po' di tempo e traggo la conclusione che l'impostazione EnableHeaderChecking A true è infatti abbastanza buono da prevenire attacchi di iniezione di intestazioni http.

Osservando il codice ASP.NET "riflesso", ho scoperto che:

  1. Esiste solo un modo per aggiungere intestazioni HTTP personalizzate a una risposta HTTP, ovvero utilizzare il file HttpResponse.AppendHeader metodo
  2. HttpResponse.AppendHeader O
    • crea istanze di HttpResponseHeader (interno)
    • o chiamate HttpResponseHeader.MaybeEncodeHeader (per IIS7WorkerRequests)
    • o assegna le sue rispettive proprietà (per intestazioni note come Reindirizzamento O Tipo di contenuto)
  3. HttpResponseHeader le istanze vengono create prima delle intestazioni note come Reindirizzamento O Tipo di contenuto sono inviati (HttpResponse.GenerateResponseHeaders)
  4. IL HttpResponseHeader il costruttore controlla il file Abilita controllo intestazione impostazione e chiamate HttpResponseHeader.MaybeEncodeHeader quando impostato su true
  5. HttpResponseHeader.MaybeEncodeHeader codifica correttamente i caratteri di nuova riga che rendono impossibili gli attacchi di iniezione di intestazioni HTTP

Ecco uno snippet per dimostrare approssimativamente come ho testato:

// simple http response splitting attack
Response.AddHeader("foo", "bar\n" + 
    // injected http response, bad if user provided
    "HTTP/1.1 200 OK\n" + 
    "Content-Length: 19\n" +
    "Content-Type: text/html\n\n" +
    "<html>danger</html>"
);

Quanto sopra funziona solo se giri esplicitamente EnableHeaderChecking spento:

<httpRuntime enableHeaderChecking="false"/>

Fortify semplicemente non tiene conto della configurazione (setting EnableHeaderChecking esplicitamente non ha avuto alcun effetto) e quindi Sempre segnala questo tipo di problemi.

Altri suggerimenti

Per quanto ne so, è sufficiente e dovrebbe essere attivato per impostazione predefinita.

Penso che Fortify stia solo pensando alla difesa in profondità come se si cambiasse la configurazione nella distribuzione, ecc.

Presumo che tu non l'abbia impostato rigorosamente nella tua configurazione, se lo hai forse Fortify non è così intelligente da capire che il nostro.

Il modo migliore per confermarlo è sfruttarlo :)

  • Prendi semplicemente una copia di Fiddler
  • Intercetta la richiesta
  • Prova a iniettare una nuova linea
  • Verifica se la nuova riga che hai appena inserito è nella risposta HTTP o meno.

EnableHeaderChecking è solo per i dati non attendibili. Se si sta passando i dati direttamente da un cookie in un reindirizzamento, forse le intestazioni risultanti sono considerati attendibile e \ r \ n valori non sono sfuggiti.

Josef, HttpResponse.AppendHeader () non è l'unico luogo in cui i dati non attendibili possono entrare nel Intestazioni HTTP di risposta.

I dati provenienti da l'attaccante che finisce in cookie o reindirizzamenti HTTP in grado di scrivere nuove intestazioni se i dati contiene un ritorno a capo (o qualsiasi cosa che viene interpretato come un ritorno a capo).

In generale, si tratta di un molto migliore uso del vostro tempo per convalidare i dati rispetto a sedersi intorno e cercare di lavorare fuori exploit. Le probabilità sono, gli hacker stanno per essere meglio a questo di quanto tu o io sono.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top