Статьи

AppSensor — обнаружение вторжений

Февраль 3, 2019
Представьте, что вы создали красивое веб-приложение и обеспечили его наилучшим образом. Пришли пользователи, использовали его, и все было в порядке, пока кто-то не наткнулся на уязвимость в вашем приложении и не использовал его. Конечно, вы проанализировали журналы и обнаружили, что плохой парень искал уязвимость в течение нескольких недель, пока не нашел ее.

Создатели инфраструктуры обнаружения вторжений AppSensor считают, что вышеупомянутой ситуации быть не должно. Приложение не должно просто лежать там и позволить себе биться с SQL-инъекциями, XSS-атаками и всем остальным. Следует принять активные меры для защиты себя. Поскольку средний злоумышленник должен предпринять несколько попыток найти уязвимость в приложении, он должен по возможности обнаруживать попытки взлома.

Идея фреймворка для обнаружения вторжений в приложение кажется довольно оригинальной. Хотя системы обнаружения вторжений широко распространены в мире сетевой безопасности, мы не нашли альтернативы AppSensor. Если вы знаете об этом, пожалуйста, дайте нам знать.

AppSensor Project

AppSensor является частью проекта Open OWASP. Все началось с концептуальной основы и превратилось в настоящую библиотеку. Проект в настоящее время находится в бета-версии.

AppSensor находится в двух местах:

Создатель написал короткую и легко читаемую книгу с обзором проекта, рекомендациями и лучшими практиками. Книгу стоит прочитать, даже если вы решите реализовать собственное решение. Если вы решите использовать AppSensor, руководство по началу работы для разработчиков доступно в коде Google.

обзор

Дизайн высокого уровня приятен и прост. AppSensor имеет точки обнаружения, ответные действия и детектор вторжений. Точки обнаружения способны обнаруживать продолжающиеся или вероятные атаки. Они распространяются через приложение и вызывают исключения датчика приложения при каждом выполнении условия вторжения.

Например, точка обнаружения «GET When Expecting POST» вызывает предупреждение всякий раз, когда страница, ожидающая только POST-запросов, запрашивается методом HTTP GET. Или точка обнаружения «Попытка межсайтового скриптинга» вызывает исключение, если запрос содержит общий шаблон атаки XSS.

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

AppSensor является частью проекта Enterprise Security API (ESAPI) . Стандартная версия поддерживает только проекты, защищенные ESAPI. Тем не менее, наш пример приложения защищен с помощью Shiro Framework. Интеграция между обеими платформами описана в другом сообщении в блоге .

Не навреди

Хотя весь смысл системы обнаружения вторжений заключается в обнаружении и остановке продолжающейся хакерской атаки, одинаково важно не причинять вреда ни в чем не повинным пользователям. Книга AppSensor предлагает разделить точки обнаружения на две категории:

  • события атаки,
  • подозрительные события.

Если скрытая переменная формы внезапно содержит «ИЛИ 1 = 1», нет сомнений, что кто-то взломал приложение. Событие считается событием атаки, и система может предпринять сильные действия (выйти из системы, отключить учетную запись) против пользователя.

С другой стороны, неожиданное «;» в параметре запроса считается только подозрительным. Может быть, это была опечатка. Возможно, это был злонамеренный хакер, пытающийся вести себя сдержанно Поскольку мы не знаем, мы можем сделать вывод, что система подвергается атаке, только если событие происходит несколько раз на нескольких полях. В этом случае система должна записать событие и повысить уровень журнала для текущего пользователя. Более сильные действия будут предприняты только после повторных событий.

Конечно, контекст приложения тоже имеет значение. Неожиданный HTML-тег <img>, отправленный в поле «Фамилия» торговых приложений, следует воспринимать серьезно. Тот же запрещенный тег <img> в дискуссионном форуме можно воспринимать легкомысленно. Пользователь может пытаться добавить анимацию или что-то еще к своему имени пользователя. Это раздражает, но вряд ли нападение.

Пример приложения

Мы тестировали AppSensor на SimpleShiroSecuredApplication, созданной в рамках серии Apache Shiro . Вы можете скачать пример из ветки intrusion_detection на Github. Используйте тестовый класс RunTestWait тестового класса для запуска веб-сервера с приложением, развернутым по адресу https: // localhost: 8443 / simpleshirosecuredapplication / URL.

Приложение имеет семь пользователей: администратор, дружественный ремонтник, недружелюбный ремонтник, математик, физик, продукт, продавец и продавец. Все они используют один и тот же пароль: «heslo».

Добавить AppSensor

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

Добавьте зависимость AppSensor в pom.xml:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
org.owasp.appsensor
 
 
 
AppSensor
 
 
 
0.1.3.2
 
 
 
jar
 
 
 
compile

Создайте папку «.esapi» внутри папки src / main / resources . Подсказка для пользователей Eclipse: eclipse package explorer не показывает файлы и папки, имена которых начинаются с a. (период). Чтобы показать их, перейдите в представление проводника пакетов и нажмите маленькую стрелку вниз в верхнем правом углу представления. Нажмите «Фильтры» и снимите флажок «. * Resources».

Распакуйте файл jar AppSensor и скопируйте три файла конфигурации

  • .esapi / appsensor.properties — конфигурация AppSensor,
  • .esapi / validation.properties — конфигурация проверки входных данных ESAPI,
  • .esapi / ESAPI.properties — конфигурация ESAPI

в папку ресурса / .esapi. Кроме того, вы можете скачать их из репозитория кода Google . Измените запись ESAPI.IntrusionDetector в файле ESAPI.properties, чтобы использовать AppSensor в качестве детектора вторжения:

1
ESAPI.IntrusionDetector = org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector

интеграция

Некоторые действия пользователя считаются угрозой, только если они повторяются одним и тем же пользователем слишком много раз. Более того, детектор вторжений может решить, что необходимы ответные действия «выйти из системы» или «отключить учетную запись». Все это требует доступа к базовым данным приложения и API.

Конфигурация AppSensor по умолчанию предполагает, что приложение поддерживает интерфейсы ESAPI. Однако SimpleShiroSecuredApplication защищено платформой Shiro, которая имеет другой набор функций. Поскольку интеграция между двумя фреймворками больше связана с Shiro, чем с AppSensor, мы перенесли ее в отдельный пост .

Точки обнаружения

Страница OWASP содержит обширный список предлагаемых точек обнаружения . Он содержит почти все возможное. Точки обнаружения делятся на несколько категорий:

  • request и session — манипулирование с URL, запросом, куки,…
  • input — пользовательский ввод содержит обычную XSS-атаку, необычный символ, введенный текст длиннее размера поля ввода,…
  • медовая ловушка — в противном случае неиспользуемое скрытое поле или переменная запроса с заманчивым именем is_admin изменяется, запрашивается URL, доступный только в html-комментарии,…
  • тенденция пользователя или системы — слишком много выходов из системы по всему сайту, пользователь щелкает быстрее, чем это возможно, пользователь слишком часто меняет свое имя,…
  • …

Много усилий было уделено поиску точек обнаружения, которые могут быть вызваны невинной деятельностью. Большинство из этих точек обнаружения еще не реализованы. Класс AttackDetectorUtils содержит большинство реализованных точек обнаружения:

  • метод неожиданного запроса,
  • атака xss,
  • впрыск sql,
  • нулевой байт в параметре запроса,
  • наличие печенья,
  • возврат каретки или перевод строки.

Дополнительно доступны два фильтра сервлетов:

Будьте осторожны : точки обнаружения инъекций xss и sql необходимо перенастроить перед использованием (подробнее об этом позже ).

Добавление точек обнаружения

Каждая точка обнаружения имеет уникальный код. Если приложение обнаруживает вторжение или подозрительное событие, оно может использовать код для вызова исключения AppSensorException:

1
2
3
if (intrusionDetected()) {
  new AppSensorException("CODE", "Message to user.", "Log message.");
};

Примечание: пункт «throw» отсутствует. Конструктор исключений автоматически запускает его.

Кроме того, подготовленные точки обнаружения доступны в классе AttackDetectorUtils :

1
AttackDetectorUtils.verifyXSSAttack(inputValue)

или вы можете настроить фильтры сервлетов в web.xml:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
IpChangedDetectionPoint
 
 
 
 org.owasp.appsensor.filters.IpAddressChangeDetectionFilter
 
 
 
 
 
 
 
 
IpChangedDetectionPoint
 
 
 
/*

Каждая точка обнаружения имеет порог проникновения и соответствующие ответные действия. Порог — это количество событий, необходимых в течение периода времени, прежде чем будет предпринято соответствующее действие.

Например, CODE-исключение вторжения считается атакой, если оно вызывается четыре раза в течение десяти минут. Если порог достигнут в первый раз, событие регистрируется только в журнале. Пользователь вышел после второго нарушения. Третье нарушение (например, исключение было возбуждено двенадцать раз в течение десяти минут) полностью отключит учетную запись пользователя:

1
2
3
4
5
6
# number of intrusions in a specified segment of time that constitutes the upper threshold - once crossed, it's considered an "attack"
IntrusionDetector.CODE.count=4
# time period (in seconds)
IntrusionDetector.CODE.interval=600
# list of actions you want executed in the specified order
IntrusionDetector.CODE.actions=log, logout, disable

Обнаружение XSS-атак и SQL-инъекций

Мы начнем с точек обнаружения, которые обнаруживают две популярные атаки на веб-приложения: внедрение SQL и XSS-атаку. Всякий раз, когда приложение считывает значение из параметра запроса, оно передается в точки обнаружения:

01
02
03
04
05
06
07
08
09
10
11
12
/**
 * Reads sanitized request parameter value from request.
 */
protected String getField(HttpServletRequest request, String parameter) {
  String dirtyValue = request.getParameter(parameter);
   
  // detection point: XSS, SQL injection
  AttackDetectorUtils.verifySQLInjectionAttack(dirtyValue);
  AttackDetectorUtils.verifyXSSAttack(dirtyValue);
   
  return sanitizer.sanitize(dirtyValue);
}

Согласно книге AppSensor, эти точки обнаружения обнаруживают вторжение всякий раз, когда злоумышленник пытается внедрить SQL-инъекцию или XSS-атаку. Если это так, система должна принять решительные меры против пользователя. Мы настроили это в файле appsensor.properties:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
# XSS attack -- be careful about these settings
# clear attack event, taking action immediately
IntrusionDetector.IE1.count=1
# clear log after 20 minutes
IntrusionDetector.IE1.interval=1200
# first offense log user out, second disable account 
IntrusionDetector.IE1.actions=logout, disable
 
# SQL injection -- be careful about these settings
# clear attack event, taking action immediately
IntrusionDetector.CIE1.count=1
# clear log after 20 minutes
IntrusionDetector.CIE1.interval=1200
# first offense log user out, second disable account 
IntrusionDetector.CIE1.actions=logout, disable

Тем не менее, мы предлагаем быть очень осторожными с этим. Откройте «страницу личного аккаунта» SimpleShiroSecuredApplication и поместите одну из этих строк в любое поле:

1
The dog should fetch the stick as soon as possible.
1
please delete all unused configuration files
1
Any text with ; in it.

Точка обнаружения SQL-инъекции вызывает исключение после любого из них.

Проблема вызвана словом fetch в первом сообщении, словом delete во втором сообщении и символом ‘;’ в последнем сообщении. Они довольно распространены в стандартных текстах на английском языке, но все они вызывают исключение SQL-инъекций.

Точка обнаружения атаки XSS также может привести к ложным срабатываниям (однако менее вероятно):

1
2
3
4
Hi,
thank you for installation scripts and requirements document.cookies has been delicious, please bring them again :)).
See you soon,
Andy

Шаблоны атак по умолчанию настраиваются в файле appsensor.properties. Используйте стандартные регулярные выражения Java:

1
2
3
4
5
6
7
# This collection of strings is the XSS attack pattern list
xss.attack.patterns=\"><script>,script.*document\\.cookie,<script>,<IMG.*SRC.*=.*script,<iframe>.*</iframe>
 
# This collection of strings is the SQL Injection attack pattern list
sql.injection.attack.patterns=\\-\\-,\\;,\\/\\*,\\*\\/,\\@\\@,\\@,nchar
,varchar,nvarchar,
alter,cursor,delete,drop,exec,fetch,insert,kill,sysobjects,syscolumns

Мы настоятельно рекомендуем изменить эти списки на что-то менее строгое.

Ответные действия

Проект содержит также список возможных ответных действий . Предлагаемые действия делятся на следующие категории:

  • тихий — изменение регистрации, уведомление администратора,…
  • пассивный — показывать предупреждение, замедлять работу приложения для пользователя,…
  • active — выйти из системы, отключить модуль, требовать дополнительной проверки (капча),…
  • навязчивый — будьте осторожны, чтобы остаться на юридической стороне

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

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

Оба отключают действия ответа компонента, блокируют доступ к последнему вызываемому URL. Они оба требуют дополнительной настройки.

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

Отключить компонент

Если вы хотите использовать ответные действия «отключить компонент» или «отключить компонент для пользователя», вам нужно создать страницу, которая будет отображаться вместо заблокированной страницы:

1
2
3
4
5
6
<title>Access Denied</title>
</head>
<body>
Sorry, you do not have access rights to that area.
</body>
</html>

Блокируются только те URL-адреса, которые заканчиваются суффиксами, настроенными в appsensor.properties. Мы будем использовать только страницы jsp и html. Все наши сервлеты будут иметь суффикс сервлет:

1
2
# This is the list of extensions to check for disabling, ie. jsp (for jsp's), do (for struts 1), UpdateProfile (for the UpdateProfile servlet)
disable.component.extensionsToCheck=jsp,html,servlet,

Невозможно настроить «суффикс всех страниц не имеет значения». Вы должны перечислить все возможные суффиксы. Однако вы можете настроить исключения, которые никогда не будут заблокированы. Поскольку мы не используем его, мы оставим там конфигурацию по умолчанию:

1
2
3
4
# This is the list of exceptions to disabling components,
ie this list should never be disabled
disable.component.exceptions=/AppSensorDemo/appsensor_locked.jsp,
/AppSensorDemo/login.jsp,/AppSensorDemo/updateProfile.jsp

Включите отключение действий компонента в файле web.xml :

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
AppSensorBlockComponent
 
 
 
 org.owasp.appsensor.filters.AppSensorRequestBlockingFilter
 
 
 
 
 
 redirectURL
 
 
 /simpleshirosecuredapplication/account/accessdenied.jsp
 
 
 
 
 
 
 
 
 
AppSensorBlockComponent
 
 
 
/*

AppSensor перенаправляет заблокированные запросы на redirectURL.

Наконец, действия по отключению ответа компонента настраиваются в конфигурации точки обнаружения в файле appsensor.properties. Конфигурация «Отключить компонент для пользователя» выглядит следующим образом:

1
2
3
4
# some integer - duration of time to disable
IntrusionDetector.ACTION_DOES_NOT_EXISTS.disableComponentForUser.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACTION_DOES_NOT_EXISTS.disableComponentForUser.timeScale=m

Конфигурация «отключить компонент» аналогична. Длительность по умолчанию равна 0, поэтому действие ничего не делает, если вы не настроили его. Используйте константу -1, чтобы навсегда отключить компонент.

Пользовательский ответ

Если вы планируете использовать AppSensor в своем приложении, вы, вероятно, захотите добавить новое действие ответа или изменить действие по умолчанию.

Ответные действия по умолчанию обрабатываются классом DefaultResponseAction . Если вам нужен другой набор ответных действий, вы должны реализовать интерфейс ResponseAction . Следующий класс добавляет действие «Предупредить пользователя»:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
public class CustomResponseAction implements ResponseAction {
  
 private final ResponseAction delegee=DefaultResponseAction.getInstance();
 
  @Override
  public boolean handleResponse(..., AppSensorIntrusion currentIntrusion) {
  if ("warn".equals(action)) {
   Exception securityException = currentIntrusion.getSecurityException();
   String localizedMessage = securityException.getLocalizedMessage();
    
   ASUtilities asUtilities = APPSENSOR.asUtilities();
   HttpServletRequest request = asUtilities.getCurrentRequest();
   request.setAttribute("securityWarning", localizedMessage);
    
   return true;
  }
    
   return delegee.handleResponse(action, currentIntrusion);
  }
 
}

Включите новый класс в файле appsensor.properties:

1
2
# This is the class that handles the response actions
AppSensor.responseAction = org.meri.simpleshirosecuredapplication.intrusiondetection.responseaction.CustomResponseAction

Примечание. Если вы хотите расширить DefaultResponseAction, вам необходимо переопределить статический метод getInstance (). Класс, ответственный за инициализацию, в противном случае создал бы экземпляр DefaultResponseAction.

Магазин вторжений

Все обнаруженные вторжения хранятся в объекте хранилища вторжений. Хранилище вторжений по умолчанию обеспечивает очень простую реализацию: все вторжения хранятся в статической карте памяти. Он не подходит для кластерной среды, и все сохраненные данные теряются после перезапуска системы.

Если у вас есть особые потребности, вы можете заменить его собственным решением. Реализуйте интерфейс IntrusionStore и настройте его в файле appsensor.properties:

1
2
# This is the class that handles the intrusion store
AppSensor.intrusionStore = org.owasp.appsensor.intrusiondetection.reference.DefaultIntrusionStore

Общие впечатления

AppSensor — отличная идея и единственная структура обнаружения вторжений, о которой я знаю. Проект выпустил легко читаемую бесплатную электронную книгу и стоит потратить некоторое время на игры. Проектирование структуры, например, разделение на точки обнаружения, детектор вторжения и ответные действия, является надежным и практичным

Проект все еще находится в бета-версии, и это иногда показывает. Конфигурация по умолчанию для точек обнаружения XSS-атак и SQL-инъекций слишком строгая, и мы обнаружили несколько небольших ошибок при написании этой статьи. Тем не менее, коммиттеры проекта ответили на поставленные вопросы всегда быстро.

Множество ожидаемых мелких особенностей отсутствуют. Невозможно сказать «все URL блокируются». Пользователь должен добавить все суффиксы в extensionsToCheck вручную. Поскольку ответные действия по умолчанию настраиваются в блоках точек обнаружения в файле appsensor.properties, мы также ожидаем поддержки той же конфигурации для настраиваемых действий. Или, некоторые классы (DefaultResponseAction) являются одиночными без веской причины.

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

Ссылка: AppSensor — обнаружение вторжений от нашего партнера JCG Марии Юрковичовой в блоге This Is Stuff .

40
Share: