Комментарии 10
Ох уж эти API... Каждый микросервис норовит выставить наружу свой API, да еще и с документацией, которая, порой, выглядит как приглашение на вечеринку для всех желающих. И ладно бы только Swagger, там же еще и GraphQL, и всякие кастомные RPC, которые порой вообще без доки живут, но дыры в них не меньше.
Это, конечно, штука полезная. Типа пылесос для низковисящих фруктов. Находит то, что лежит на поверхности, и это уже хорошо. Потому что, поверьте, таких "подарков" до сих пор хватает. Вроде бы 2025 год на дворе, а базовые вещи до сих пор пролетают мимо ревью. Иногда кажется, что разработчики соревнуются, кто оставит более жирную дыру, чтобы потом пентестеры не скучали.
Вот вам история из жизни, без имен и паролей, разумеется:
Как-то раз, на одном из проектов, мы ковыряли внутренний API одной очень крупной, очень серьезной компании. Ну, знаете, такие, у которых бюджет на безопасность, как у маленькой страны. И вот, в процессе изучения, натыкаемся на эндпоинт, который, судя по названию, должен был возвращать какие-то внутренние логи. Ну, логи и логи, дело обычное. Но вот незадача: он возвращал не просто логи, а логи с полным стектрейсом, включая переменные окружения, пути к файлам и, что самое вкусное, часть конфигов с продакшн-сервера. Без какой-либо авторизации, разумеется. Просто GET-запрос, и вуаля! Весь внутренний мир компании как на ладони. Оказалось, что это был какой-то дебажный эндпоинт, который забыли выключить после релиза. "Ну, кто же его найдет?" – думали они. А вот Autoswagger или его ручной аналог – найдет. И найдет быстро. Это как оставить ключ от сейфа под ковриком у двери, а потом удивляться, почему кто-то зашел и взял все самое ценное.
Так что, господа, инструменты вроде Autoswagger – это не панацея, но очень важный первый шаг. Они помогают отсеять совсем уж вопиющие косяки. Но помните: настоящий хакер – это не тот, кто просто сканирует, а тот, кто умеет думать как разработчик, который очень сильно устал и хочет домой. И искать не только то, что явно торчит, но и то, что спрятано за семью печатями, но при этом открывается на стук. А еще, конечно, не забывайте про банальную гигиену: не оставляйте дебажные эндпоинты на проде, не выставляйте наружу то, что не должно быть наружу, и всегда, ВСЕГДА проверяйте авторизацию. Иначе потом будете рассказывать грустные истории на Хабре, а мы будем кивать головой и вспоминать свои похожие приключения. Удачи в поисках дыр, и пусть они будут только в тестовых средах!
Гораздо интереснее, что автосваггер не найдёт. Или найдёт, но нам не расскажет, а отправит куда надо.
Шутки юмора о торчащих эндпоинтак в очень крупном бизнесе заставляют задаться вопросом: что у них с код-ревью?
Бюджет не большой страны на безопасность, без ревью, это слишком сомнительная история. Больше похоже на тестирование незадачливой команды кандидатов в песочнице и под колпаком.
Шутки юмора о торчащих эндпоинтак в очень крупном бизнесе заставляют задаться вопросом: что у них с код-ревью?
Я думаю, что это не ревью а DevOps или DevSecOps должны делать. В коде будет условие типа "если такой-то эндпоинт в конфиге включён - выложить лог". И ревью такой код пройдёт. А вот "ревью продового конфига" в серьезной компании разработчик и не увидит - не его это уровень доступа. Это будет делать кто-то по инструкции по деплою приложения + необходимые конфиги. А вот полнота этих инструкций - это ещё одна поверхность для контроля.
Или найдёт, но нам не расскажет, а отправит куда надо.
Не понял, там же исходники открыты, всего пару питон файлов
А как Autoswagger работает с закрытыми API, для которых документация не публикуется на сервере? Сможет ли он тогда найти уязвимости ?
Также возникает вопрос, а как бороться с уязвимостями которые нашел этот инструмент, просто удалить всю документацию?
Я думаю (нужно проверить), что он находит именно открытую документацию и проверяет её. А бороться - я вижу 3 варианта:
1) Если открыто то, что не должно быть открыто, то закрыть
2) Если открыто то, что должно быть открыто, но работает "некорректно", то исправить
3) Если открыто то, что должно быть открыто и работает как надо, то не трогать.
Звучит логично. А не знаете случайно, сколько примерно по времени занимает анализ с помощью данного инструмента и что необходимо для его работы?
Мы в практике используем Mozilla Observatory — он довольно быстро даёт общую картину, нужно указать только домен. Интересно, здесь так же или процесс отличается?
По-разному, в зависимости от настроек. У них в github описаны варианты сканирования.
Спасибо, а незнаете случайно, планируем запуститься на нескольких bug bounty программах (хотим потратить по несколько дней на каждую) и хотелось бы узнать ваше по инструментарию.
Кроме Autoswagger, какие еще инструменты посоветуете для эффективного тестирования? Может быть у вас есть практические советы, как организовать процесс, чтобы быстро находить интересные вещи, а не тратить время на очевидные векторы?
Бесплатный инструмент Autoswagger находит уязвимости API, которые злоумышленники надеются, что вы пропустите