Когда мы развернули систему защиты от атак на веб-приложения SolidWall WAF для наших клиентов, у нас появилась мысль посмотреть, как будут обнаруживаться и блокироваться атаки на тестовый сервис, например, тренажера Juice Shop - приложения, в котором намеренно реализованы наиболее частые уязвимости.

Мы хотели сделать разбор всех простых загадок (с одной звездой) Juice Shop, но с учетом скриншотов в формат статьи влезла только одна: «Zero Stars Give a devastating zero-star feedback to the store. Improper Input Validation». Она интересна тем, что от нее сложно защититься негативной моделью (сигнатурами), но легко - позитивной моделью, хорошо развитой у SolidWall.

Juice Shop развернули легко по инструкции https://hub.docker.com/r/bkimminich/juice-shop#docker-container

Настраиваем SolidWall. Сначала фильтрующие ноды, публикуем приложение в конфиге nginx: /etc/solidwall/nginx/sites-enabled/juiceshop

sudo solidwall-nginx test

sudo solidwall-nginx reload

Далее добавляем приложение в веб-интерфейсе SolidWall:

В нашем случае перед фильтрующими нодами стоит балансировщик. Поэтому в рамках «тройки» будем определять приложение только по имени.

Трафик пошел, корректно определилось приложение.

Итак, приступаем к тестированию

Задача: Give a devastating zero-star feedback to the store (В форме обратной связи оставить отзыв с 0 звездами). Классическая задача по валидации входных данных.

Эксплуатируем

Решается предельно просто: создаем запрос с нужным телом (JSON), например, в BurpSuite Repeater.

Защищаем

Теперь вопрос, как защититься на уровне SolidWall? Очевидно, нужно ввести валидацию входных значений.

Находим нужную нам транзацию в журнале SolidWall.

В первую очередь нам надо убедиться, что разбор запроса на стороне WAF осуществляется корректно. Идем в раздел «Запрос». Как мы видим ниже, структура полностью соответствует запросу, который мы видим в свойствах транзакции. Это означает, что он будет разбираться корректно, и можно переходить к правилам.

Возвращаемся в транзакцию, переходим на вкладку «Действие» и нажимаем кнопку «Создать действие на основе этой транзакции».

Переходим в раздел действия и видим действие вот такого вида:

url->path->0 == api
url->path->1 == Feedbacks
url->path->2 ==
method == POST
body->rating, body->captcha, body->captchaId, body->comment (любое значение)

Редактируем созданное действие:

*Нужно нажимать на верхний карандаш, отметил на картинке*

Параметры (из JSON) появились при создании правила из транзакции, а вот в поле «Модель» было указано «по умолчанию». Изменяем ее для каждого из параметров и сохраняем изменения.

Проверяем...

Неправильный рейтинг

Правильный рейтинг

Неправильный тип id капчи

Неправильный комментарий

Вообще в строковый тип сложно закинуть некорректные данные… те же числа он просто конвертирует в строки. Пусть будет еще один вложенный JSON:

Лишний параметр

А вот с лишним параметорм нормально проходит, но он теряется при обработке приложением.

Журнал SolidWall

В журнале SolidWall видим, что появились ошибки «Параметр не соответствует модели»

Видим, что не прошла валидация параметров:

Заключение

Итак, нам удалось провести валидацию входных данных и блокировать запросы, не соответствующие модели.

На этом на сегодня все, спасибо за внимание. Если интересно почитать разбор конкретного кейса – напишите в комментариях.

Блокирование веб-атак на тестовый сервис: опыт использования SolidWall для защиты позитивной моделью