Казалось бы, причем тут джинсы с ширинкой сзади?

Но как еще доступно рассказывать, что такое API и почему его, бедолагу, надо защищать? Помимо аналогии со штанами, API еще красиво описывают в виде дорог, а запросы - в виде машинок🚗*
Представьте, как дофига у вас может быть разных приложений и с каким "дофига" они могут взаимодействовать? По-моему, вектор угрозы актуальный. Если нет идей с чего начинать - вам придется сделать карту приложений и их API. Сложно защищать то, что не видно😉

Еще факт: приложения у вас разные, и API могут работать по-разному. Если я понимаю, как защитить свои приложения - ваши работают иначе, поэтому надо определить, как реализовать атаки с помощью API и разработать механизмы защиты.

Для управления безопасностью API, нужно отслеживать все прилоги и куда-то складывать поведенческую аналитику запросов, чтобы ее можно было использовать для определения угроз и векторов атак. Инструментам должен помогать кожаный, не так ли?:)
Поэтому запустим полноценный цикл постов, чтобы прокачать #apisecurity. Так что следующие недели будут трибьютом безопасности апишек.

*Пример с дорогами не так поэтичен, как джинсы😉

А давно ли вам читали сказку?

Кажется, сегодня прекрасный день для этого!

Сегодня буду рассказывать про AppSec в формате сказки, где добро победит🫰конференцию-выезд организуют мои большие друзья из RadCop, у них я готова освещать новости безопасной разработки даже в выходные🫶

Друзья, ссылочка на все доклады двух дней! Для меня формат предсказаний в отрасли был первым, поэтому - если посмотрите, буду рада с вами обсуждать!😉

Ну что, как и обещала - стрим, посвященный безопасности API!

С чего бы начать?

Логично, что с каких-то общих вещей. Раз уж тема безопасности API становится модной и хайповой - давайте посмотрим, что там вообще происходит?

Ну, начинаем с API-рисков, которые были аккурат в 2023 году апдейтнуты OWASP'ом!

Как нельзя лучше для открытия #APISECURITY WEEKS😏

#APISECURITY WEEKS начинается с обзорной экскурсии в мир OWASP API TOP 10 и одного выдуманного магазина.

API1:2023 Broken Object Level Authorization (BOLA)

Что делает хацкер? Использует эндпоинты API, которые могут быть уязвимы для нарушения авторизации на объектном уровне. При этом идентификаторы объектов могут быть вообще любыми. Актуально это потому что серверный компонент не отслеживает состояние на стороне клиента и полагается только на ID-шки, которые идут на сервер. Казалось бы, а что тут плохого? Ну, как минимум, он получает доступ к данным будучи не авторизованным - а это уже и раскрытие информации, и потеря данных, и что-нибудь еще. Все-таки, пользователь (или же хацкер) должны получать доступ только туда, куда им можно.

Пример: крупная компания по доставке товаров из интим-магазина🔞 создает API, который позволяет пользователю получить доступ к списку всех отправлений и посмотреть, какой именно аппарат для пентеста😏 к кому поехал. А потом можно шантажировать:)

Дальше больше! Продолжаем #APISECURITY WEEKS🙌

API2:2023 Broken Authentication

Представим, что авторизоваться все-таки надо, а вот как там проверяется аутентификация? Если где-то на уровне API есть проблема с методами аутентификации или механизмами аутентификации - это же интересно раскопать!

Что может делать злоумышленник? Ну, как минимум перебирать пароли по словарям, особенно, если нет нормального ограничения на вход в систему. (а была бы двухфакторка, вот это вот бы все я тут не писала...🙄)

Пример: все тот же магазин 18+ решил сделать вход в приложение по телефону и моментальному (ага, моментальному) коду в СМС. Злой человек предполагает, что его коллега что-то приобретает в этом магазине и решает... проверить! Вводит телефон, а дальше... просто перебирает коды доступа и вуаля! Он уже в личном кабинете смотрит на все покупочки коллеги:)

Ну что, под окончание рабочего дня третий пост #APISECURITY WEEKS👀

Если вам нужно что-то почитать* по дороге домой из вашего прекрасного френдли офиса с печеньками, то кажется, это оно!

API3:2023 Broken Object Property Level Authorization

Опять про эндпоинты. Внимание, щас сильно актуально для REST'ов: бывает так, что эндпоинты возвращают все свойства объекта😉. Такое себе. Это опять же несанкционированный доступ к конфиденциальным данным и персухе, который приведет к тому, что они перестанут быть сильно конфиденциальными. При этом, он может получить доступ и просто к конкретным желаемым свойствам объекта.

Пример: в нашем уже привычном магазине закончились инструменты для мотивации сотрудников😞. Значит, кто-то их раскупил. И вот, наш хакер использует несовершенство API, получая без авторизации список всех учетных записей (вдруг это его директор закупил и завтра его будут мотивировать?), которые покупали инструменты...

Доброе утро второго дня #APISECURITY WEEKS!

Продолжаем изучать OWASP API TOP 10⬇️

API4:2023 Unrestricted Resource Consumption

Итак, реализовать такую штуку могут хакеры, которые кинут несколько простых запросов. По простому говоря, это реализация DoS, которая будет влиять на скорость API. Все апишки имеют ограниченные ресурсы, поэтому "забить" таким образом трафик - вот вам и DoS/DDoS. Так что, если ваш API не имеет лимитов на частоту и объем запросов - кто-то может уже прямо сейчас ломать вашу приложеньку.

Пример: владелец нашего магазина🔞 понял, что доступ в ЛК нужно давать по номеру телефона пользователя и паролю. Конечно, кто-то может забыть пароль (мы же не каждый день покупаем себе что-то... или каждый?). Так вот, хакер пишет правило, которое отправит сотни тысяч запросов на восстановление пароля, а сервисная компания, которая отправляет сообщения для восстановления, реально отправит те самые сотни тысяч сообщений. Магазин практически на грани разорения!

Продолжаем? #APISECURITY WEEKS, я думаю, продлятся недели 2-3. Сначала хотела уместить все в одну неделю, но как выясняется, вообще задача нетривиальная. Погнали!

API5:2023 Broken Function Level Authorization

Чтобы такое исполнить, злоумышленнику надо отправлять вполне себе легитимные вызовы, но на тот эндпоинт, куда у него доступа нет. Обычно проверки авторизации управляются на уровне конфигурации кода, и реализация нормальных проверок никому не нужна (нужна😞). Чтобы такого не было, нужно делать анализ механизма авторизации с учетом ролевой модели. Хакер вообще может попытаться угадать URL и эндпоинт...

Пример: магазин товаров для скучающих по вечерам принял решение: каждый думает, как он хочет, поэтому можно оформить подписку за 200 рублей в месяц и получать скидку на товары из категории "Мотиваторы". Вредоносный человек изменил настройки своей учетной записи, получив права админа, таким образом, что к его учетке тоже прикреплена подписка. Теперь он закупает "Мотиваторы" со скидкой и думает сделать такую же подписку своим друзьям.

Дальше в нашем потоке #APISECURITY WEEKS... бизнес-потоки!

API6:2023 Unrestricted Access to Sensitive Business Flows

Если вы не знаете все про свои API - злоумышленник уже знает. Например, если у вас нет понимания какие именно бизнес-требования покрываются API, вы способствуете повышению этого пункта в рейтинге)). Хакеры могут вручную искать, какие ресурсы, какие эндпоинты задействованы и как они работают. Обращайте внимание, что избыточный неконтролируемый доступ к некоторым ресурсам может нанести вред бизнесу. Условно, кто-то может просто спамить по API, а кто-то может занять всю очередь запросов - и ваш реальный потребитель до вас не дойдет.

Пример: хакер решил, что ему не по душе, когда все мотиваторы из магазина 🔞выкуплены! Он решил реализовать следующий механизм: каждые несколько дней отправлять запросы, чтобы зарезервировать за собой всю очередь, так, чтобы доступа к товарному каталогу больше ни у кого не было. Зато мотиваторы точно на месте😉

P.S. Если вам интересно, что такое мотиватор - вернитесь на пару постов повыше.

Второй пост третьего дня марафон #APISECURITY WEEKS!

API8:2023 Security Misconfiguration

Когда апишку обвешивают сложными конфигами, чтобы было удобно его настраивать - злоумышленнику тоже, кстати, удобно)). Он может поискать незапатченные проблемы или какие-то службы, которые работают с несекьюрными конфигурациями по умолчанию. Это все ищется, гуглится, и даже эксплоиты есть.

Пример: представим, что в нашем небезызвестном магазине🔞 появился чат с консультантом! Теперь проще выбрать мотиватор, ведь сотрудники готовы в этом помочь😉Но так как API не включает контроль кэширования в хедэре, вся эта переписка кэшируется браузером и злоумышленник может получить всю информацию о том кто, что и когда хотел купить из файлов кэша браузера.

Идем дальше! #APISECURITY WEEKS продолжается историями про магазин мотиваторов и...

API9:2023 Improper Inventory Management

Такая прелесть раскрывает огромное количество эндпоинтов - потому что API в целом так работает, что вебчик оказывается более защищен. Поэтому если у нас нет инвентаризации хостов и аналитики по всем версиям API, мы можем получить много проблем. Злоумышленники обычно получают доступ к информации через старые версии или эндпоинты без обновлений безопасности.

Пример: директор магазина🔞решил, что теперь-то точно все безопасно, ведь реализовать какую-нибудь брут-форс атаку не получится. однако, он забыл, что у него есть еще один хост с API - который остался еще с момента проектирования сайта, но механизм ограничения скорости против брут-форса на нем не был реализован! Теперь наш злоумышленник имеет доступ ко всем паролям пользователей и может составлять свою личную аналитику по покупкам.

Вопрос, отвлеченный от недель безопасности API.
Все-таки, у нас под каналом есть чат и возможность там общаться. Подобных чатов много. И вопрос: нужен ли вам еще один чат по безопасности приложенек?
Проголосуйте, пожалуйста🫶

Если да, буду развивать его как побочную ветку канала - где вы еще можете болтать друг с другом.