Достаточно ли EnableHeaderChecking=true для предотвращения атак путем внедрения заголовка Http?
Вопрос
Достаточно ли иметь [System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking
](http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx) установлен в true
(по умолчанию), чтобы полностью предотвратить атаки с внедрением заголовка Http, такие как разделение ответов и т. д.?
Я спрашиваю, потому что инструмент тестирования на проникновение белого ящика (fortify) сообщает об уязвимых проблемах с внедрением HTTP-заголовка с помощью HttpResponse.Redirect
и файлы cookie, но я не нашел способа успешно провести атаку.(редактировать:..и у нас включен EnableHeaderChecking..)
Решение
Я смотрю на это уже некоторое время и пришел к выводу, что настройка EnableHeaderChecking к true
на самом деле достаточно хорошо, чтобы предотвратить атаки с внедрением HTTP-заголовка.
Посмотрев на «отраженный» код ASP.NET, я обнаружил, что:
- Существует только один способ добавить пользовательские заголовки HTTP в ответ HTTP, а именно с помощью HttpResponse.AppendHeader метод
- HttpResponse.AppendHeader или
- создает экземпляры
HttpResponseHeader
(внутренний) - или звонки
HttpResponseHeader.MaybeEncodeHeader
(дляIIS7WorkerRequests
) - или присваивает соответствующие свойства (для известных заголовков, таких как ПеренаправлениеМестоположение или Тип содержимого)
- создает экземпляры
HttpResponseHeader
экземпляры создаются до известных заголовков, таких как ПеренаправлениеМестоположение или Тип содержимого посланы (HttpResponse.GenerateResponseHeaders
)- А
HttpResponseHeader
конструктор проверяет EnableheaderChecking настройка и звонкиHttpResponseHeader.MaybeEncodeHeader
когда установленоtrue
HttpResponseHeader.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 явно не имело никакого эффекта) и, таким образом, всегда сообщает о подобных проблемах.
Другие советы
AFAIK, этого достаточно, и он должен быть включен по умолчанию.
Я думаю, что Fortify просто думает о глубокоэшелонированной защите, как если бы вы изменили конфигурацию при развертывании и т. д.
Я предполагаю, что вы не включили его строго в своей конфигурации, если у вас есть, возможно, Fortify не настолько умен, чтобы понять, что это наш.
Лучший способ подтвердить это использовать его :)
- Просто получите копию скрипача
- Перехватить запрос
- Попробуйте ввести новую строку
- Посмотрите, находится ли новая строка, которую вы только что ввели, в ответе HTTP или нет.
EnableHeaderChecking предназначен только для ненадежных данных.Если вы передаете данные непосредственно из файла cookie в Redirect, возможно, полученные заголовки считаются доверенными, а значения не экранируются.
Йозеф, HttpResponse.AppendHeader() — не единственное место, где ненадежные данные могут попасть в заголовки HTTP-ответа.
Любые данные злоумышленника, которые попадают в файлы cookie или перенаправления HTTP, могут записать новые заголовки, если данные содержат возврат каретки (или что-либо, что интерпретируется как возврат каретки).
В общем, гораздо эффективнее использовать время для проверки данных, чем сидеть сложа руки и пытаться найти уязвимости.Скорее всего, хакеры справятся с этим лучше, чем вы или я.