обернуть или не обернуть ESAPI

Хорошо, хотя я в принципе согласен с тем, что мантра "ESAPI должна быть оберткой", я думаю, что вам всегда нужно учитывать более широкие проблемы. Прежде всего, это, вероятно, зависит от того, какую часть ESAPI вы намереваетесь использовать, и насколько широко разбросаны по исходному коду, который он может развернуть. Если вы только собираетесь использовать небольшую часть этого кода в каком-то изолированном коде, то, вероятно, нет смысла обертывать его другим слоем, потому что в случае необходимости он будет относительно простым в изменении. С другой стороны, если вы находитесь на другом уровне, может быть хорошей идеей защитить ваши инвестиции и изолировать их от любых будущих изменений. (Например, предлагаемый ESAPI 3 (см. Https://github.com/ESAPI/esapi-java) планируется иметь очень разные интерфейсы.)

Наконец, хотя мне больно это говорить, поддержка ESAPI в последнее время невелика. Только за последние 2-3 года я сам и еще один человек даже вносили свой вклад в это. Фактически, хотя это не сделанная сделка, ESAPI, скорее всего, потеряет свой флагманский статус OWASP (см. Http://off-the-wall-security.blogspot.com/2014/03/esapi-no-longer-owasp -flagship-project.html). Там даже говорили о том, чтобы обозначить проект как "закат", если мы не начнем получать больше добровольцев. Если все, что вы хотите использовать ESAPI для, - это исключительно выходное кодирование и проверка данных, то я бы посоветовал вам взглянуть на проект OWASP Java Encoder Project и проект OVASP Java HTML Sanitizer. (Извините, у меня нет ссылок, но я уверен, что вы знаете, как использовать поисковые системы так же хорошо, как и я).

-kevin стена/проект ESAPI Java

Цель ESAPI должна быть обертка, что позволяет менять в компонентах, как вы считаете нужным. В этом воплощении текущей версии это просто не жизнеспособный подход, поскольку ESAPI имеет огромный след, и, откровенно говоря, большинство людей используют лишь очень небольшую часть ESAPI.

Тем не менее, ESAPI 3.0 нацелен на решение этой проблемы, но нам (команде ESAPI) было трудно привлечь сообщество к работе над новым материалом. Вы можете проверить репозиторий github для ESAPI 3.0, который направлен на решение проблем, описанных здесь в комментариях, и переместить фокус обратно в API, который предоставляет все ваши средства управления безопасностью, а не пытается быть самими элементами безопасности.

Github: https://github.com/ESAPI/esapi-java

Является ли ESAPI достаточно зрелым, чтобы было безопасно напрямую зависеть от него или было бы разумным придерживаться этой оболочки?

Моя история заключается в том, что мы использовали ESAPI (только канонизацию, прежде чем удалять различные шаблоны символов инъекций из строки ввода, введенной пользователями в форматах html) с двух лет, в зависимости от интерфейса и без каких-либо проблем.

Такая небольшая зависимость реализуется в одном классе java (вызванном из фильтра сервлета): если интерфейс изменится, нам придется изменить только несколько строк кода в этом классе. Поэтому в настоящий момент интерфейс упаковки не даст нам никаких преимуществ в отношении текущей реализации.

Я предлагаю оценить зрелость проекта, просмотрев другие источники, такие как http://www.ohloh.net/p/owasp-esapi-java, или напрямую обратиться к сообществу ESAPI.

Я думаю, что это какой-то оппонент.

Но я использую ESAPI с одного-двух лет (только для вывода с экранами) и не имел проблем с использованием этой библиотеки напрямую.

Я использую методы escape в таблице стилей XSL, поэтому я создал оболочку, но только для лучшего доступа, чем для инкапсуляции.

Если у вас есть лучшее представление об извлечении его из-за интерфейса, сделайте это.