6 ручных кейсов для поиска новых векторов атак👇
1️⃣ Переосмысление «невозможного»
Ищи в документации формулировки вида «X не может делать Y». Это не запрет — это предположение разработчиков.
Часто именно здесь:
⚫️ Ошибки в ролевых моделях
⚫️ Обходы проверок
⚫️ Слабые enforcement-механизмы
2️⃣ Обход paywall’ов
Купи доступ один раз. Проанализируй, какие API-запросы реально включают платные фичи.
Дальше:
⚫️ Повтори их с бесплатного аккаунта
⚫️ Проверь, нет ли только фронтенд-проверок
Да, не все программы это принимают. Но финансовый ущерб = реальный риск для бизнеса.
3️⃣ «А что это за библиотека?»
Нашел интересный эндпоинт — начинай фаззить, чтобы бэкенд вернул какие-то ошибки: копируй точный текст ошибки/исключения и ищи в GitHub, чтобы понять, какая именно библиотека используется.
Дальше:
⚫️ Изучай исходники
⚫️ Смотри закрытые issues
⚫️ Проверяй зависимости
4️⃣ Ломай UI-логику
Создавай состояния, которые UI «не должен» показывать.
Не ограничивайся
false → true:⚫️ Меняй значения постепенно
⚫️ Подставляй неожиданные коды подписки
⚫️ Меняй баланс, статусы, флаги
Смотри, как приложение реагирует, а не что рисует UI.
5️⃣ Используй приложение как обычный пользователь
Медленно. Вручную. Через прокси. Параллельно фиксируй идеи:
⚫️ HTML запрещён при регистрации — а при редактировании профиля?
⚫️ UI блокирует — а API?
⚫️ Один флоу проверил, а альтернативный?
Логика пользователя ≠ логика разработчика.
6️⃣ Анализируй ответы сервера
Сравнивай, что вернул бэкенд, а что — фронт.
Типичные находки:
⚫️ Скрытые данные на фронте
⚫️ Флаги beta-фич
⚫️ «Странные» свойства без UI
Фронт часто просто не показывает лишнее, но сервер уже всё выдал.