Всем привет. Сегодня решил написать про такую уязвимость, как DoS, которую многие недооценивают и часто автоматически приравнивают к DDoS. Как по мне, это довольно грубая ошибка.

━━━━━━━━━━ Вводная часть ━━━━━━━━━━

Когда слышат про отказ в обслуживании, многие сразу представляют ботнет из тысяч машин, гигантский поток запросов и “положили сервис трафиком”.

Но это уже скорее история про DDoS.

DoS отличается тем, что для нарушения доступности сервиса не всегда нужен распределённый трафик, большое количество узлов или сложная инфраструктура атакующего. Иногда достаточно одного клиента и “сырого” функционала, который потребляет слишком много ресурсов.

• DoS — отказ в обслуживании из одной или ограниченного числа точек • DDoS — тот же отказ в обслуживании, но уже из множества распределённых источников

➤ DoS возникает там, где клиент может заставить систему потреблять избыточный объём ресурсов из-за слабых ограничений, отсутствия валидации или неудачной логики реализации.

Именно поэтому DoS — это не только про сеть. Это ещё и про бизнес-логику, лимиты, объёмы, валидацию и стоимость обработки одного запроса.

━━━━━━━━━━ Как я обычно ищу DoS ━━━━━━━━━━

Как и любая другая уязвимость, DoS может встретиться где угодно и в разной форме: от комментария до загрузки аватарки.

Основной функционал, где я чаще всего встречал такие проблемы:

➤ Создание статьи / поста / комментария / сообщения Когда нет нормальной валидации на объём текста, количество символов, вложенность или число элементов в запросе.

➤ Загрузка изображений и файлов Если не ограничены размер, формат, разрешение или число загружаемых объектов, это уже хорошая точка для перегрузки backend-а, хранилища или обработчиков.

➤ Списки товаров, постов, объектов и выдача данных Классическая история: нет адекватного ограничения на limit, и клиент может запросить что-то вроде ?limit=999999, заставляя сервис тянуть огромный объём данных.

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

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

• тяжёлая обработка JWT, cookies или иных токенов • дорогая сериализация / десериализация • сложные регулярные выражения • избыточная работа с PDF, изображениями, архивами • дорогие фильтры, сортировки и поисковые запросы

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

━━━━━━━━━━ На что смотреть при защите ━━━━━━━━━━

Чтобы не привезти себе такую проблему в прод, как минимум стоит контролировать: • лимиты на размер входных данных • лимиты на количество объектов в запросе • пагинацию и верхние границы limit • rate limiting • таймауты • стоимость обработки одного запроса • очереди и асинхронную обработку там, где это уместно

И самое главное — думать не только о том, “валидный ли это запрос”, но и о том, насколько дорого он обходится системе.

━━━━━━━━━━ Мини-итог ━━━━━━━━━━

Да, DoS может казаться не такой “зрелищной” уязвимостью, как инъекции, RCE или утечки чувствительных данных.

Но это не делает её неважной.

Нарушение доступности сервиса — это уже прямой удар по бизнесу: • репутация • пользователи • деньги • доверие к продукту

#AppSec #Pentest #BugBounty #DoS #DDoS #WebSecurity #CyberSecurity