В части моего кода J2EE/java, я делаю URLEncoding на выходе getRequestURI(), чтобы дезинфицировать его, чтобы предотвратить атаки XSS, но Fortify SCA считает, что это плохое подтверждение.Является ли URLEncoder.encode (строка, «UTF-8») плохой проверкой?
Почему?
Главное, что вам нужно преобразовать специальные символы HTML в объекты HTML. Это также называется «экранирование HTML» или «escape-код XML». В основном, персонажи <, >, ", & и ' должен быть заменен <, >, ", & и '.
URL-код не делает этого. URL-кодирование преобразует специальные символы URL в процентные значения. Это не экранирование HTML.
В случае веб-приложений, экранирование HTML, как правило, должно выполняться со стороны просмотра, точно там, где вы перерисовываете входной сигнал, управляемый пользователем. В случае веб-приложений Java EE это зависит от технологии просмотра, которую вы используете.
Если webapp использует современную технологию просмотра Facelets, вам не нужно ее избегать самостоятельно. Facelets уже неявно это сделает.
Если webapp использует устаревшую технологию просмотра JSP, вам необходимо убедиться, что вы используете тег JSTL <c:out> или функцию fn:escapeXml() для повторного отображения пользовательского ввода.
<c:out value="${bean.foo}" />
<input type="text" name="foo" value="${fn:escapeXml(param.foo)}" />
Если веб-приложение очень наследство или плохо разработаны и с использованием сервлетов или скриптлетов для печати HTML, то у Вас есть большая проблема. Нет встроенных тегов или функций, не говоря уже о методах Java, которые могут выходить из объектов HTML. Вы должны либо написать какой-то метод escape(), либо использовать Apache Commons Lang StringEscapeUtils#escapeHtml() для этого. Затем вам нужно убедиться, что вы используете его везде, где вы печатаете вход, управляемый пользователем.
out.print("<p>" + StringEscapeUtils.escapeHtml(request.getParameter("foo")) + "</p>");
Намного лучше было бы перепроектировать это устаревшее webapp для использования JSP с JSTL.
Обратите внимание, что кодировка HTML обычно также будет отмечена как плохая проверка. Поскольку SCA - это автоматизированный инструмент, он не может много знать о контексте самого кода, поэтому он не может знать, что он будет защищать от XSS в каждом экземпляре. Пример будет заключаться в том, что вы помещаете пользовательский ввод непосредственно в сценарий специально (JavaScript, Python, Ruby, что угодно. язык сценария - это XSS-склонный). – lavamunky
URL кодирование не влияет на некоторые существенные признаки, включая одинарные кавычки (') и скобки, поэтому кодирование URL будет проходить через неизменные определенные полезные нагрузки.
Например,
onload'alert(String.fromCharCode(120))'
будет рассматриваться некоторыми браузерами, как действительный атрибут, который может привести к выполнению кода при введении внутри тега.
Лучший способ избежать XSS - обработать все ненадежные входы как обычный текст, а затем при составлении вывода правильно закодировать весь текст на соответствующий тип на выходе.
Если вы хотите отфильтровать входы как дополнительный уровень безопасности, убедитесь, что ваш фильтр обрабатывает все кавычки (включая обратную галочку) и круглые скобки в качестве возможного кода и запрещает их, если не имеет смысла для этого ввода.
sanitize! = Validate –
Это зависит от контекста, который вы хотите использовать в этой строке. Итак, где вы его выводите? – Gumbo
Основная причина, по которой HP Fortify SCA перечисляет это как «плохую проверку», заключается в том, что кодирование НЕ является валидацией. Вы должны увидеть это как проблему Fortify Medium ", потому что он признает, что были предприняты некоторые усилия для смягчения проблемы. – LaJmOn