Безопасность веб-приложений на Java. Часть V. Проникновение с помощью Zed Attack Proxy

Другой вариант (вместо удаления localhost) — добавить в файл hosts запись с именем вашего производственного домена. Это то, что я сделал для этой демонстрации.

127.0.0.1       demo.raibledesigns.com

Я также настроил Apache для запросов прокси к Jetty со следующими настройками mod_proxy в моем httpd.conf:

<IfModule mod_proxy.c>
    ProxyRequests Off 
    ProxyPreserveHost Off 

    <VirtualHost *:80>
       ProxyPass  /  http://localhost:8080/
    </VirtualHost>

    <VirtualHost *:443>
        SSLEngine on
        SSLProxyEngine on
        SSLCertificateFile "/etc/apache2/ssl.key/server.crt"
        SSLCertificateKeyFile "/etc/apache2/ssl.key/server.key"

        ProxyPass  /  https://localhost:8443/
    </VirtualHost>
</IfModule>

Выполните сканирование
Теперь вам нужно предоставить ZAP некоторые данные для работы. Используя Firefox, я перешел на http://demo.raibledesigns.com и немного просмотрел список пользователей, добавил нового и удалил существующего. После этого я заметил несколько флагов в пользовательском интерфейсе ZAP в разделе Сайты. Затем я щелкнул правой кнопкой мыши по каждому сайту (один для http и один для https) и выбрал Attack> Active Scan site. Это можно сделать на вкладке «Активное сканирование» в нижней части ZAP, но при одинаковых URL-адресах возникает ошибка . После этого я получил несколько предупреждений: от высокого (межсайтовый скриптинг) до низкого (автозаполнение пароля). На скриншоте ниже показаны различные проблемы.

Теперь давайте посмотрим, как их исправить.

Исправление уязвимостей
Одна из вещей, не упомянутых при сканировании, но № 1 в Семи конфигурациях безопасности (неправильных) в файлах Java web.xml , — это страницы пользовательских ошибок, не настроенные. Пользовательские страницы ошибок настроены в этом приложении, но error.jsp содержит следующий код:

<% if (exception != null) { %>
    <% exception.printStackTrace(new java.io.PrintWriter(out)); %>
<% } else { %>
    Please check your log files for further information.
<% } %>

Отслеживание стека может быть очень полезным для злоумышленника, поэтому важно начать с удаления приведенного выше кода из src / main / webapp / error.jsp .

Остальные проблемы связаны с XSS, автозаполнением и файлами cookie. Давайте начнем с простых. Исправить автозаполнение достаточно просто; просто изменили HTML в login.jsp и userform.jsp, чтобы autocomplete = «off» было частью тега <form>.

Затем измените файл web.xml, чтобы использовать только http и безопасные файлы cookie. Пока вы это делаете, добавьте время ожидания сеанса и режим отслеживания, как рекомендовано в вышеупомянутой статье о неправильной конфигурации web.xml.

<session-config>
    <session-timeout>15</session-timeout>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
    <tracking-mode>COOKIE</tracking-mode>
</session-config>

Затем измените конфигурацию Spring Me «Запомнить меня», чтобы она использовала безопасные файлы cookie. Для этого добавьте use-secure-cookies = «true» к элементу <запомнить-me> в security.xml .

<remember-me user-service-ref="userService" key="e37f4b31-0c45-11dd-bd0b-0800200c9a66"
             use-secure-cookie="true"/>

К сожалению, Spring Security не поддерживает файлы cookie HttpOnly , но появится в будущем выпуске.

Следующая проблема, которую нужно решить, это отключение просмотра каталогов. Вы можете сделать это, скопировав webdefault.xml Jetty (из JAR org.eclipse.jetty: jetty-webapp) в src / test / resources и изменив его <dirAllowed «<init-param> на false:

<servlet>
  <servlet-name>default</servlet-name>
  <servlet-class>org.mortbay.jetty.servlet.DefaultServlet</servlet-class>
  <init-param>
    <param-name>acceptRanges</param-name>
    <param-value>true</param-value>
  </init-param>
  <init-param>
    <param-name>dirAllowed</param-name>
    <param-value>false</param-value>
  </init-param>
  <init-param>

Вам также нужно будет изменить конфигурацию плагина, чтобы он указывал на этот файл, добавив его в раздел <webAppConfig> в pom.xml.

<configuration>
    <webAppConfig>
        <contextPath>/</contextPath>
        <defaultsDescriptor>src/test/resources/webdefault.xml</defaultsDescriptor>
    </webAppConfig>

Конечно, если вы работаете в рабочей среде, вам нужно настроить это в настройках вашего сервера, а не в файле pom.xml.

Затем я решил исправить проблемы с кешем браузера . У меня были следующие настройки в моем декораторе SiteMesh:

<meta http-equiv="Cache-Control" content="no-store"/>
<meta http-equiv="Pragma" content="no-cache"/>

Однако, согласно ZAP, первый метатег должен иметь «no-cache» вместо «no-store», поэтому я изменил его на «no-cache».

После внесения всех этих изменений я создал новый сеанс ZAP и снова запустил активное сканирование на обоих сайтах. Ниже приведены результаты:

Я считаю, что первая проблема (подделка параметров) заключается в том, что я показываю страницу с ошибкой, когда существует дублирующий пользователь. Чтобы это исправить, я изменил UserFormController, чтобы он перехватывал исключение UserExistsException и отправлял пользователя обратно в форму.

try {
    userManager.saveUser(user);
} catch (UserExistsException uex) {
    result.addError(new ObjectError("user", uex.getMessage()));
    return "userform";
}

Тем не менее, это, похоже, все еще не заставляет тревогу исчезнуть. Это вероятно потому, что я не фильтрую / не экранирую HTML, когда он впервые представлен. Я считаю, что лучшим решением для этого было бы использовать что-то вроде ESAPI OWASP для фильтрации значений параметров. Однако я не смог найти интеграцию с привязкой данных Spring MVC, поэтому решил не пытаться исправить эту уязвимость.

Наконец, я попытался отключить jsessionid в URL, используя предложения из Stack Overflow . Предыдущий параметр в файле web.xml (<tracking-mode> COOKIE </ tracking-mode>) должен сделать это, но, похоже, он не работает с Jetty 8. Другие проблемы (безопасный кеш браузера страниц, куки HttpOnly и безопасный печенье), я не смог решить. Насколько я могу судить, последние две проблемы вызваны Spring Security.

Резюме
В этой статье я показал вам, как выполнить тестирование веб-приложения с использованием Firefox и ZW Attack Proxy (ZAP) OWASP. Я нашел ZAP хорошим инструментом для выявления уязвимостей, но было бы неплохо, если бы у него была функция «повторного тестирования», чтобы увидеть, исправили ли вы проблему для определенного URL. У него есть функция «повторной отправки», но запуск его, похоже, не снимал оповещения после того, как я их исправил.

Проблемы, которые я не смог решить, в основном касались фреймворков (например, файлов cookie Spring Security и HttpOnly) или серверов (Jetty не использует куки для отслеживания). Я подозреваю, что проблемы с Jetty связаны с тем, что он не поддерживает Servlet 3, а также рекламирует. Я считаю, что это справедливо; Я использую вехой релиз в конце концов. Я попытался сканировать http://demo.raibledesigns.com/ajax-login (который работает на Tomcat 7 в Contegix ) и подтвердил, что jsessionid не существует.

Надеемся, что эта статья помогла вам понять, как определить уязвимости в ваших веб-приложениях. Я верю, что ZAP будет становиться все более популярным, когда разработчики узнают об этом. Если вы чувствуете себя честолюбивым и хотите попытаться решить все проблемы в моем приложении Ajax Login, не стесняйтесь размещать его на GitHub .

Если вы хотите больше поговорить о безопасности Webapp, оставьте комментарий, встречайтесь со мной в
Jazoon позже на этой неделе или давайте поговорим в июле на
Über Conf .

От http://raibledesigns.com/rd/entry/java_web_application_security_part4