Я думаю, что Sonar Qube ожидает от вас вывода кодировки , а не только проверки. В конечном счете, большинство валидаторов ESAPI основаны только на регулярных выражениях и не являются надежными в предотвращении XSS. (Например, по крайней мере, концептуально, у вас может быть 2 различных типа пользовательских входных данных, каждый из которых вы отдельно проверяете, используя валидатор ESAPI, который индивидуально не будет представлять никаких опасностей XSS, но если злоумышленник может каким-то образом объединить их, чтобы При совместном использовании XSS-атака все еще возможна.) Однако использование выходной кодировки правильного , особенно в сочетании с настройкой charset в вашем HTTP-ответе, - рок solid. Выходное кодирование является предпочтительной защитой от простой строки XSS с использованием параметризованных операторов SQL (т. Е. В Java, PreparedStatements) является предпочтительной защитой AppSe c от SQLi.
Проблема в том, что вам нужно выводить кодирование в контексте того, как оно в конечном итоге используется. Например, если бы он выводился в контексте HTML, вы бы использовали Encoder.encodeFor HTML () ESAPI (или его эквивалентный тег 'encodeFor * HTML' из библиотеки тегов ESAPI). Если бы вы использовали его в контексте JavaScript, вы бы использовали Encoder.encodeFor JavaScript () или его эквивалентный тег «encodeFor JavaScript» JSP. Но обычно это означает, что вы НЕ хотите применять выходную кодировку в то время, когда вы просто сохраняете ее в атрибут HttpSession. Почему бы нет? Хорошо, давайте предположим, что вы предполагаете, что он будет использоваться в контексте HTML, поэтому вы сохраняете что-то вроде:
session.setAttribute("gsaPartnerContactEmail", ESAPI.encoder.encodeForHTML(request.getParameter("name_id")));
Это замечательно, если вы извлекаете и используете атрибут, это ТОЛЬКО используется в контексте HTML (хорошо, я немного соврал; это будет работать и для атрибутов HTML, не относящихся к обработчику событий, если вы правильно указали атрибут values при их вставке). Но что, если кто-то решит извлечь ваш атрибут 'gsaPartnerContactEmail' и затем использовать его в контексте JavaScript? Если это произойдет, кодировка объекта HTML не будет достаточной для предотвращения XSS, поскольку в контексте JavaScript требуется выходное кодирование JavaScript. Конечно, вы могли бы также выходной кодировать его для JavaScript, но тогда он не будет отображаться правильно, потому что он будет дважды кодирован. Или, возможно, более вероятно, что кто-то может sh использовать ваш атрибут 'gsaPartnerContactEmail' в URL-адресе 'mailto:', и в этом случае следует использовать Encoder.encodeForURL (). Но я хочу сказать, что, за исключением очень редких случаев, вы, как правило, не знаете, как и где определенное входное значение будет отображаться при выводе, и это особенно верно для большего количества разработчиков, которые имеют свои руки в вашем приложении.
Когда вы применяете выходную кодировку для предотвращения уязвимостей XSS, общее практическое правило заключается в том, чтобы применять выходную кодировку непосредственно перед к тому, где / когда испорченное значение в конечном итоге будет отображено. Причина этого в том, что если вы сделаете это раньше, это может быть использовано в другом контексте, и тогда вы все равно оставите себя открытым для уязвимости XSS.
Кстати, наконец, это все еще хорошая идея сделайте раннюю проверку при вводе данных пользователем с помощью средства проверки ESAPI, аналогичного тому, что вы делаете (Проверка и выходное кодирование не являются исключительными, а скорее дополняют друг друга.) Вместо того, чтобы молча продолжать, если во входном значении есть ошибка (т. Е. Вход считается «недействительным»), лучше вместо этого направить сообщение об ошибке обратно в пользователи сообщают им как можно раньше, что им нужно повторно ввести свою стоимость, потому что это не был законный ввод. Это хорошая практика, поскольку в большинстве случаев, когда средство проверки ESAPI идентифицирует неверный ввод, как правило, это опечатки, а не что-то со злым умыслом, и нет смысла расстраивать всех тех дружелюбных пользователей, которые значительно превосходят по численности злонамеренных.
Надежда это помогает. --kevin