Эта атака называется «разбиение заголовка» или «разбиение ответа» .
Эта ссылка OWASP указывает на то, что удаления CRLF недостаточно.\n может быть столь же опасным.
Чтобы смонтировать успешный эксплойт, приложение должно разрешить ввод, содержащий CR (возврат каретки, также заданный 0x0D или \ r) и LF (перевод строки,также задается 0x0A или \ n) символами в заголовке.
(я не знаю, почему OWASP (и другие страницы) перечисляют \n как уязвимость или относится ли это только к фрагментам запроса до-decode.)
Обслуживание 500 при любой попытке установить заголовок, который содержит символ, недопустимый спецификацией в ключе или значении заголовка, вполне разумно и позволит вам идентифицировать оскорбительные запросы в ваших журналах.,Быстрый отказ, если вы знаете, что ваши фильтры выходят из строя, - это хорошая политика.
Если язык, на котором вы работаете, позволяет, вы можете заключить объект ответа HTTP в тот, который вызывает исключение, когда виден плохой заголовокили вы можете изменить объект ответа, чтобы ввести недопустимое состояние, установить код ответа 500 и закрыть поток тела ответа.
РЕДАКТИРОВАТЬ:
Должен ли я удалить не-Входные данные ASCII?
Я предпочитаю выполнять такую нормализацию в слое, который получает доверенные входные данные, если, как в случае с экранированием сущностей для преобразования простого текста в экранирование HTML, нет явногопреобразование типов.Если это преобразование типов, я делаю это, когда требуется тип вывода, но если это не преобразование типов, я делаю это как можно раньше, чтобы все потребители данных этого типа увидели согласованное значение.Я считаю, что такой подход упрощает отладку и документирование, поскольку слоям ниже обработки ввода не нужно беспокоиться о ненормализованных входных данных.
При реализации обертки ответа HTTP я могу заставить ее работать на всех несимволы ascii (включая не ASCII-символы новой строки, такие как U + 85, U + 2028, U + 2029), а затем убедитесь, что мои тесты приложений включают тест для каждого стороннего ввода URL-адреса, чтобы убедиться, что все заголовки Location имеют правильные значения%-кодированный до того, как местоположение достигнет setHeader, и аналогично для других входов, которые могут достигать заголовков запроса.
Если ваши куки содержат такие вещи, как идентификатор пользователя или адрес электронной почты, я бы позаботился о том, чтобы фиктивные учетные записитесты включают фиктивную учетную запись с идентификатором пользователя или адресом электронной почты, содержащим не-ASCII-письмо.