Fortify и AntiXSS

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

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


c# asp.net fortify antixsslibrary html-encode
person fd_dev    schedule 15.07.2010    source источник
comment
О боже, в этом проблема автоматических инструментов - ложные срабатывания. Я бы посоветовал зарегистрировать заявку в службу поддержки с помощью Fortify - AntiXSS не следует отмечать таким образом. Сейчас я владелец AntiXSS, поэтому, если Fortify хочет, чтобы с кем-то поговорили, вы можете указать его мне, bdorrans @ thatbigborgdomainname :)   -  person blowdart    schedule 15.07.2010
comment
Мы действительно это сделали, они сказали, что AntiXSS недостаточно хорош. Мы спросили, что это такое, и все еще ждем ответа. Я хотел посмотреть, как другие люди обходят эту ерунду.   -  person fd_dev    schedule 15.07.2010
comment
Ха, здорово. Если подумать об этом подробнее, хотя формулировка интересна, AntiXSS, конечно, не проверяет, он просто берет то, что вы ему даете, и кодирует это. Возможно, он ожидает некоторого подтверждения до этого момента.   -  person blowdart    schedule 15.07.2010

Ответы (3)


arrow_upward
7
arrow_downward

Я являюсь членом исследовательской группы по безопасности 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)

person Joy Forsythe    schedule 20.07.2010
comment
Мне очень жаль, но это просто прекрасный пример проблем с автоматизированными инструментами, использующими тип сканирующего механизма. AntiXss ЯВЛЯЕТСЯ правильным решением для ВСЕХ контекстов, несмотря на статью OWASP - в ней явно указано, что, хотя кодировки HTML недостаточно, кодирование в соответствии с правильным контекстом является - и это предоставлено AntiXss. Проблема в том, что Fortify не может определить правильный контекст и в результате не может определить, какой метод использовать (как вы заявили). - person AviD; 04.11.2010
comment
Таким образом, использование метода кодирования правильного не является даже контекстно-зависимой проверкой, его даже не следует использовать с плавающей точкой. Только при использовании неправильного метода в соответствии с контекстом должно подходить к этой категории. - person AviD; 04.11.2010
comment
Не проблема - это именно то, что я делал, когда использовал Fortify (и, кстати, Microsoft AntiXSS) в HP. И да, слишком много ложных срабатываний, часть торговли автоматическими инструментами. - person gmaran23; 22.12.2013

arrow_upward
4
arrow_downward

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

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

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

person Douglas Held    schedule 03.09.2010

arrow_upward
1
arrow_downward

Мы нашли решение. Вы не поверите, но это заставляет Fortify360 принять код.

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

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

person fd_dev    schedule 15.07.2010
comment
Пробовал, но он все еще не работает. Он по-прежнему отмечает мой код как имеющий средние уязвимости (межсайтовый скриптинг: плохая проверка). Я понятия не имею, как это решить. - person rcs; 23.04.2019