Очень часто вы можете обратить внимание что к вашим ресурсам поступают запросы, которых быть не должно, вы их и не ждете скажем так. Предположим, ваша API допускает работу с тремя методами запросов – GET, POST, PUT. Было бы логично заблокировать лишние запросы, чтобы снизить нагрузку и повысить безопасность. И это можно сделать с помощью собственных правил детекта, которые пользователи могут добавлять в нашем личном кабинете. Приведу пример такого правила:
![](https://habrastorage.org/getpro/habr/upload_files/4d1/eed/502/4d1eed502c65f109afcf9182452a6e81.png)
Этим правилом с помощью регулярных выражений, описывающих метод запроса, мы указываем доступные методы запроса для всего нашего клиента (правило естественно можно уточнить для определенного URL, но мне лень).
И в результате получаем:
![](https://habrastorage.org/getpro/habr/upload_files/82e/824/83c/82e82483c90f843955f41f497ff47bcf.png)
Блокировку запросов, не соответствующих нашим ожиданиям по методу запроса.
Это, кстати, к нам забегал сканер поиска Битрикса, на предмет проверки наличия уязвимой версии.
![](https://habrastorage.org/getpro/habr/upload_files/f9f/1e9/43c/f9f1e943cf4eabe6a9b2feb00d67c5eb.png)
Все узнали эти URL?
На этом наше исследование применений регулярных выражений клиента не закончено, ждите наших новых статей. Покажем, как ограничивать поля ввода по содержимому, чтобы вместо номера телефона в базу не слали атаку ????
Подписывайтесь на канал. Здесь мы делимся информацией по продукту, нашими находками и наработками, пока они не оформляются в большой статический материал.
olegtsss
Мне кажется мой backend не плохо тоже с этим справляется. Плюс я всегда кастомизирую возвраты, мало ли кто ошибся)
Alexander_Zubritskiy Автор
Это хорошая практика, я привел пример кейса, который часто встречается - на тот случай, если это не закрыто на уровне backenda или балансировщика до него.
И хотел бы добавить, что часто нашим заказчиком является ИБ отдел - которые стараются на своем поле закрыть все лишнее.
olegtsss
Тогда вам надо подробно описать, чем предлагаемое вами решение лучше умолчательного. Может какие-то хитрости вы применяете в них. Или дополнительный функционал. А может даже и плюсов у вашего решения несколько больше, чем у аналогичного ПО.
Alexander_Zubritskiy Автор
Наше решение позволит проанализировать запросы, которые будут отсечены данным правилом, мы можем сперва промониторить события, а потом если правило работает корректно (и разработчики не забыли что у них на старом API живет метод который они забыли передать в ИБ при настройке системы) перевести в боевой режим.