Est EnableHeaderChecking = true suffisant pour éviter d'en-tête Http attaques par injection?

Question

Est-il suffisant d'avoir [System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking] ( http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking (VS.85) .aspx) ensemble à true (par défaut) pour empêcher complètement Http tête attaques par injection comme Response Splitting etc.?

Je demande parce que un outil de test de pénétration de boîte blanche (renforcer) signale des problèmes d'injection d'exploitable en-tête http avec HttpResponse.Redirect et les cookies, mais je ne l'ai pas trouvé un moyen de réaliser avec succès une attaque. ( modifier : .. et nous avons EnableHeaderChecking activé ..)

Answer 1

J'ai regardé depuis un certain temps maintenant et d'en tirer la conclusion que la mise en EnableHeaderChecking true est en fait assez bon pour prévenir les attaques par injection d'en-tête http.

Regarder le code ASP.NET 'reflète', je trouve que:

1. Il n'y a qu'une seule façon d'ajouter des en-têtes HTTP personnalisés à une réponse HTTP, à savoir en utilisant le méthode HttpResponse.AppendHeader
2. HttpResponse.AppendHeader soit
   • crée des instances de HttpResponseHeader (interne)
   • ou les appels HttpResponseHeader.MaybeEncodeHeader (pour IIS7WorkerRequests)
   • ou attribue ses propriétés respectives (en-têtes connus comme RedirectLocation ou ContentType )
3. instances de HttpResponseHeader sont créés en-têtes avant connus comme RedirectLocation ou ContentType sont envoyés (HttpResponse.GenerateResponseHeaders )
4. Le constructeur HttpResponseHeader vérifie la EnableHeaderChecking off:

   <httpRuntime enableHeaderChecking="false"/>

   Fortify ne prend pas simplement la configuration en compte (réglage EnableHeaderChecking avait explicitement aucun effet) et donc toujours rapporte ce type de questions.

Answer 2

AFAIK il suffit et il doit être activé par défaut.

Je pense que Fortify est juste de penser à la défense en profondeur comme si vous modifiez la configuration dans le déploiement, etc.

Je suppose que vous ne l'avez pas strictement défini sur dans votre configuration, si vous avez peut-être Fortify est pas intelligent pour que notre.

La meilleure façon de confirmer est l'exploiter:)

• Procurez-vous une copie de Fiddler
• Intercept la demande
• Essayez d'injecter une nouvelle ligne
• Voir si la nouvelle ligne que vous venez injecter est dans la réponse HTTP ou non.

Answer 3

EnableHeaderChecking est uniquement pour les données non fiables. Si vous transmettre des données directement à partir d'un cookie dans un Redirect, peut-être les en-têtes qui en résultent sont considérés comme des valeurs de confiance et \ r \ n ne sont pas échappés.

Answer 4

Josef, HttpResponse.AppendHeader () n'est pas le seul endroit où les données non fiables peuvent entrer dans la têtes de réponse HTTP.

Les données de l'attaquant qui se termine dans les cookies ou redirections HTTP peuvent écrire de nouveaux en-têtes si les données contiennent un retour chariot (ou tout ce qui est interprété comme un retour chariot).

En général, il est un bien meilleur usage de votre temps pour valider vos données plutôt que de s'asseoir et essayer de trouver des exploits. Les chances sont, les pirates vont être mieux à ce que vous ou moi sommes.