Достаточно ли EnableHeaderChecking=true для предотвращения атак путем внедрения заголовка Http?

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

  •  22-08-2019
  •  | 
  •  

Вопрос

Достаточно ли иметь [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, я обнаружил, что:

  1. Существует только один способ добавить пользовательские заголовки HTTP в ответ HTTP, а именно с помощью HttpResponse.AppendHeader метод
  2. HttpResponse.AppendHeader или
  3. HttpResponseHeader экземпляры создаются до известных заголовков, таких как ПеренаправлениеМестоположение или Тип содержимого посланы (HttpResponse.GenerateResponseHeaders)
  4. А HttpResponseHeader конструктор проверяет EnableheaderChecking настройка и звонки HttpResponseHeader.MaybeEncodeHeader когда установлено true
  5. 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, могут записать новые заголовки, если данные содержат возврат каретки (или что-либо, что интерпретируется как возврат каретки).

В общем, гораздо эффективнее использовать время для проверки данных, чем сидеть сложа руки и пытаться найти уязвимости.Скорее всего, хакеры справятся с этим лучше, чем вы или я.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top