Если вы показываете полный стек исключений, я мог бы помочь.Скорее всего, это потому, что ESAPI не может найти ваш файл ESAPI.properties .
Однако у меня есть вопрос.То, что вы говорите, звучит так: вы планируете исходить из браузера пользователя, пропускаете его через приложение, заставляете ваше приложение принять этот браузер и передать его в Encoder.encodeForXML(String), а затем сохранить , что в вашей базе данных?Это верно?Если это действительно то, что вы делаете, то это в точности наоборот.
Класс ESAPI Encoder (ну, технически, интерфейс) - это кодировщик output .Это означает, что целью является сделать кодирование вывода на стороне ответа HTTP, а не на стороне ввода.
Почему это так?Что ж, в будущем, что если вы когда-нибудь намного позже решите, что хотите использовать этот сохраненный элемент БД и вывести его где-нибудь еще, например, в контексте JavaScript или в контексте атрибута HTML?Эти вещи используют очень разные контекстные кодировки.Но вы уже закодировали его для XML.Поэтому, если вы (скажем) в будущем выведите его в контекст JavaScript, вы все равно будете восприимчивы к XSS, потому что вы использовали выходную кодировку WRONG (контекст XML вместо контекста JavaScript).Конечно, вы можете помнить - ой, мне нужно использовать Encoder.encodeForJavaScript () здесь.Но вы уже выполнили кодирование вывода для контекста XML, поэтому есть вероятность, что вы случайно сделаете некоторую двойную кодировку на стороне вывода, и это может испортить рендеринг.
Итак, вы действительно не хочу этого делать, то есть хранить закодированный вывод в вашей БД.Это делает ваше решение очень жестким.Вместо этого способ, которым следует использовать выходную кодировку ESAPI, максимально приближен к фактическому рендерингу, потому что если вы сделаете это там, вы будете знать предполагаемый контекст вывода.Обычно это означает, что в ваших JSP (где библиотека тегов ESAPI наиболее полезна).
Надеюсь, все это имеет смысл.Если нет, не стесняйтесь задавать вопросы.Я работаю над тем, чтобы выпустить ESAPI 2.2.0.0 за дверь (борюсь с проблемами Maven; вздох), поэтому я или Мэтт Сеил, сопредседатель ESAPI, можем задержаться, чтобы вернуться к вам.
Надеюсь, это поможет, со-ведущий проекта -kevin / ESAPI