Угроза безопасности / атака на приложение JSF после включения HTTPS

Question

У меня есть веб-приложение на основе JSF2.0 на RF3.3, работающее на JBoss. Я очень обеспокоен безопасностью веб-приложения.

Хотя связь с моим веб-приложением из внешнего мира будет осуществляться по протоколу HTTPS, после включения HTTPS для моего веб-приложения я все еще не знаю, какие возможны другие атаки безопасности.

По крайней мере, существует целый ряд атак безопасности для веб-приложений, но я сосредоточен на 10 атаках безопасности OWASP.

JSF автоматически обрабатывает атаки XSS и CSRF (я также использовал jar ESAPI, чтобы избежать атаки CSRF), и я уже позаботился об атаке с использованием SQL-инъекций.

Я чувствую, что даже после включения https будет слишком много известных и потенциальных угроз / атак на веб-приложение.

Еще одна вещь, которую я хотел бы сообщить: - Клиент будет получать доступ к приложению по HTTPS. Но мое приложение будет выдавать определенный вид запросов другому внутреннему веб-приложению, и это сообщение HTTP. Таким образом, произойдет изменение протокола с HTTPS на HTTP, но, поскольку это изменение относится к интрасети, я думаю, что это не сильно повлияет.

Пожалуйста, ведите меня.

Answer 1

JSF автоматически обрабатывает XSS

Это не правда. Да, JSF по умолчанию выполняет автоматическое экранирование, поэтому h:outputText и другие будут корректно экранировать специальные символы HTML:

escape Boolean

Атрибут escape - это логический флаг, который определяет , следует ли экранировать чувствительные символы HTML и XML в выходных данных, генерируемых этим компонентом. Значением по умолчанию для этого атрибута является "true".

Блокирует внедрение тегов <script>, но не влияет на другие основные векторы XSS. javascript: URL-адреса не должны содержать никаких «чувствительных символов HTML или XML», а чувствительные к HTML-символам в javascript: URL-адреса, введенные в <img src=...> и <a href="...">, будут просто правильно экранированы, что облегчит атаку.

Любые URL, которые составлены из ненадежных данных, должны быть проверены на корректность, а их протокол должен быть занесен в белый список с небольшим набором. «http», «https» и «mailto» являются хорошими значениями по умолчанию для большинства приложений.

---

Я чувствую, что даже после включения https было бы слишком много известных и потенциальных угроз / атак на веб-приложение.

HTTP для всего сайта - отличный шаг. Если вы заблокировали XSS, XSRF и подслушивание, я бы попробовал следующий вектор атаки: разбиение заголовка .

Если я могу вставить заголовок Location на вашу страницу, я могу вызвать перенаправление, возможно, перенося информацию о реферере с параметрами GET на сайт, которым я управляю.