Fortify и AntiXSS

Question

Моя компания требует, чтобы наш код ASP.NET прошел проверку Fortify 360 перед выпуском кода. Мы используем AntiXSS везде для очистки вывода HTML. Мы также проверяем ввод. К сожалению, недавно они изменили «шаблон», который использовал Fortify, и теперь он помечает все наши вызовы AntiXSS как «Плохая проверка». Эти вызовы делают такие вещи, как AntiXSS.HTMLEncode (sEmailAddress).

Кто-нибудь точно знает, что удовлетворит Fortify? Многое из того, что он помечает, выводится там, где значение поступает из базы данных, а не от пользователя вообще, поэтому, если HTMLEncode недостаточно безопасен, мы понятия не имеем, что это!

Answer 1

Я являюсь членом Исследовательской группы безопасности Fortify, и я прошу прощения за путаницу, которую эта проблема вызывает у вас. Мы не очень хорошо представили этот тип проблемы. Я думаю, что часть проблемы заключается в названии категории - мы не пытаемся сказать, что с механизмом валидации что-то не так, просто мы не можем сказать, подходит ли он для этой ситуации.

Другими словами, мы не знаем, какова правильная проверка для вашего конкретного контекста. По этой причине мы не распознаем какие-либо функции кодирования HTML как проверяющие по XSS из коробки, даже те, которые есть в библиотеке Microsoft AntiXSS.

Что касается правильного решения, если вы используете HtmlEncode для вывода имени пользователя в тело HTML-страницы, ваш исходный код в порядке. Если закодированное имя пользователя используется в URL-адресе, оно может быть уязвимо для XSS. В Fortify, когда мы обнаруживаем подобные проблемы в нашем собственном коде, если проверка соответствует контексту, мы помечаем ее как «Не проблема».

Мы знаем о проблемах, связанных с этими проблемами, и впредь вносим изменения в наши правила, чтобы сделать их более точными и понятными. Мы выпускаем новые правила каждые три месяца и планируем внести пару изменений в будущих выпусках. На четвертый квартал мы планируем разделить проблемы на неадекватную проверку (для кодирования в черном списке и других слабых схем проверки) и проверку с учетом контекста (тип проблемы, которую вы видите). Пожалуйста, дайте нам знать, если мы можем помочь больше.

(ссылка на объяснение OWASP о том, почему кодировка HTML не решает все проблемы: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Why_Can.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F)

Answer 2

fd_dev, я бы добавил, что вам не следует сосредотачиваться на том, чтобы сжать код, чтобы он прошел через статические аналитические циклы.Если вы квалифицированы и уверены, что результаты не применимы, используйте инструменты графического интерфейса Fortify для записи комментария и устранения проблемы.

Если вы не уверены, сделайте небольшой снимок экрана и отправьте его по электронной почте для Fortify TechnicalСлужба поддержки.Они имеют высокую квалификацию, чтобы проконсультировать вас о том, как интерпретировать ваши выводы по безопасности Fortify.

Удар на месте.См. http://www.schneier.com/blog/archives/2008/05/random_number_b.html для наихудшего случая того, что может произойти, если вы будете гоняться за результатами статического анализа, не понимая цели кода и причины / механизмы, лежащие в основе результатов.(Одним словом, вы могли бы сделать код хуже, а не лучше) -:

Answer 3

Мы нашли решение. Хотите верьте, хотите нет, но Fortify360 принимает код.

string sSafeVal = Regex.Replace(sValue, @"[\x00-\x1F\x7F]+", "");
Response.Write AntiXSS.HTMLEncode(sSafeVal);

Так что, если только AntiXSS.HTMLEncode не работает, замена непечатаемых символов работает. Не говоря уже о том, что HTMLEncode будет делать это в любом случае. Я предполагаю, что они просто запускают Regex.Replace, и я думаю, что любой шаблон будет работать.