Я смотрел на это в течение некоторого времени, и сделать вывод о том, что установка EnableHeaderChecking к true фактически является достаточно хорошим, чтобы предотвратить атаки инъекционного заголовка HTTP.
Глядя на «отражение» ASP.NET код, я обнаружил, что:
- Существует только один способ добавить пользовательские заголовки HTTP в ответ HTTP, а именно с использованием HttpResponse.AppendHeader метода
- HttpResponse.AppendHeader либо
- создает экземпляры
HttpResponseHeader (внутренний)
- или вызывает
HttpResponseHeader.MaybeEncodeHeader (для IIS7WorkerRequests)
- или присваивает свои соответствующие свойства (для известных заголовков, как RedirectLocation или ContentType)
HttpResponseHeader экземпляры, созданные до известных заголовки, как RedirectLocation или ContentType посылаются (HttpResponse.GenerateResponseHeaders)HttpResponseHeader конструктор проверяет настройки EnableheaderChecking и вызывает HttpResponseHeader.MaybeEncodeHeader при установке на trueHttpResponseHeader.MaybeEncodeHeader правильно кодирует символы новой строки что делает попытки HTTP-заголовка инъекций невозможными
Вот фрагмент, чтобы примерно показать, как я тестировал:
// 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>"
);
выше работает только если вы явно включить EnableHeaderChecking выключить:
<httpRuntime enableHeaderChecking="false"/>
Fortify просто не принимает во внимание конфигурацию (настройки EnableHeaderChecking явно не имеет эффекта), и поэтому всегда сообщает об этих типах проблем.
Привет, Йозеф, код для тестирования инъекции, который вы написали выше Мне нужно, чтобы мы могли вставить этот код для тестирования моего приложения. Мне также нужно проверить приложение. Thnx – alice7