Очень часто вы можете обратить внимание что к вашим ресурсам поступают запросы, которых быть не должно, вы их и не ждете скажем так. Предположим, ваша API допускает работу с тремя методами запросов – GET, POST, PUT. Было бы логично заблокировать лишние запросы, чтобы снизить нагрузку и повысить безопасность. И это можно сделать с помощью собственных правил детекта, которые пользователи могут добавлять в нашем личном кабинете. Приведу пример такого правила:
Этим правилом с помощью регулярных выражений, описывающих метод запроса, мы указываем доступные методы запроса для всего нашего клиента (правило естественно можно уточнить для определенного URL, но мне лень).
И в результате получаем:
Блокировку запросов, не соответствующих нашим ожиданиям по методу запроса.
Это, кстати, к нам забегал сканер поиска Битрикса, на предмет проверки наличия уязвимой версии.
Все узнали эти URL?
На этом наше исследование применений регулярных выражений клиента не закончено, ждите наших новых статей. Покажем, как ограничивать поля ввода по содержимому, чтобы вместо номера телефона в базу не слали атаку ????
Подписывайтесь на канал. Здесь мы делимся информацией по продукту, нашими находками и наработками, пока они не оформляются в большой статический материал.
olegtsss
Мне кажется мой backend не плохо тоже с этим справляется. Плюс я всегда кастомизирую возвраты, мало ли кто ошибся)
Alexander_Zubritskiy Автор
Это хорошая практика, я привел пример кейса, который часто встречается - на тот случай, если это не закрыто на уровне backenda или балансировщика до него.
И хотел бы добавить, что часто нашим заказчиком является ИБ отдел - которые стараются на своем поле закрыть все лишнее.
olegtsss
Тогда вам надо подробно описать, чем предлагаемое вами решение лучше умолчательного. Может какие-то хитрости вы применяете в них. Или дополнительный функционал. А может даже и плюсов у вашего решения несколько больше, чем у аналогичного ПО.
Alexander_Zubritskiy Автор
Наше решение позволит проанализировать запросы, которые будут отсечены данным правилом, мы можем сперва промониторить события, а потом если правило работает корректно (и разработчики не забыли что у них на старом API живет метод который они забыли передать в ИБ при настройке системы) перевести в боевой режим.