Когда мы развернули систему защиты от атак на веб-приложения 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 видим, что появились ошибки «Параметр не соответствует модели»
Видим, что не прошла валидация параметров:
Заключение
Итак, нам удалось провести валидацию входных данных и блокировать запросы, не соответствующие модели.
На этом на сегодня все, спасибо за внимание. Если интересно почитать разбор конкретного кейса – напишите в комментариях.