Основные уязвимости API OATH
Основные уязвимости API OATH: введение
Когда дело доходит до эксплойтов, лучше всего начать с API. API доступ обычно состоит из трех частей. Клиентам выдаются токены сервером авторизации, который работает вместе с API. API получает токены доступа от клиента и применяет на их основе правила авторизации для конкретного домена.
Современные программные приложения уязвимы для множества опасностей. Будьте в курсе самых последних эксплойтов и недостатков безопасности; наличие контрольных показателей для этих уязвимостей необходимо для обеспечения безопасности приложений до того, как произойдет атака. Сторонние приложения все чаще полагаются на протокол OAuth. Пользователи получат лучший общий пользовательский опыт, а также более быстрый вход и авторизацию благодаря этой технологии. Это может быть более безопасно, чем обычная авторизация, поскольку пользователям не нужно раскрывать свои учетные данные стороннему приложению для доступа к данному ресурсу. Хотя сам протокол безопасен и надежен, способ его реализации может сделать вас уязвимым для атак.
При разработке и размещении API в этой статье основное внимание уделяется типичным уязвимостям OAuth, а также различным мерам безопасности.
Сломанная авторизация на уровне объекта
Существует обширная поверхность атаки, если авторизация нарушается, поскольку API предоставляют доступ к объектам. Поскольку элементы, доступные через API, должны быть аутентифицированы, это необходимо. Реализуйте проверки авторизации на уровне объекта с помощью шлюза API. Доступ должен быть разрешен только тем, у кого есть соответствующие учетные данные.
Сломанная аутентификация пользователя
Несанкционированные токены — еще один частый способ злоумышленников получить доступ к API. Системы аутентификации могут быть взломаны или по ошибке может быть раскрыт ключ API. Токены аутентификации могут быть используется хакерами получить доступ. Проверяйте подлинность людей, только если им можно доверять, и используйте надежные пароли. С OAuth вы можете выйти за рамки простых ключей API и получить доступ к своим данным. Вы всегда должны думать о том, как вы будете входить и выходить из места. Ограниченные токены отправителя OAuth MTLS можно использовать в сочетании с Mutual TLS, чтобы гарантировать, что клиенты не будут вести себя неправильно и передавать токены не той стороне при доступе к другим компьютерам.
Продвижение API:
Чрезмерное раскрытие данных
Нет никаких ограничений на количество конечных точек, которые могут быть опубликованы. В большинстве случаев не все функции доступны всем пользователям. Раскрывая больше данных, чем это абсолютно необходимо, вы подвергаете опасности себя и других. Избегайте раскрытия конфиденциальных информация пока это абсолютно необходимо. Разработчики могут указывать, кто и к чему имеет доступ, используя области действия и утверждения OAuth. Заявки могут указывать, к каким разделам данных имеет доступ пользователь. Контроль доступа можно сделать проще и легче в управлении, используя стандартную структуру для всех API.
Отсутствие ресурсов и ограничение скорости
Черные шляпы часто используют атаки типа «отказ в обслуживании» (DoS) как способ грубой силы, чтобы перегрузить сервер и, таким образом, сократить время его безотказной работы до нуля. Без ограничений на ресурсы, которые могут быть вызваны, API-интерфейс уязвим для изнурительной атаки. «Используя шлюз API или инструмент управления, вы можете установить ограничения скорости для API. Должны быть включены фильтрация и нумерация страниц, а также ограничение ответов.
Неправильная конфигурация системы безопасности
Различные рекомендации по настройке безопасности являются достаточно исчерпывающими из-за значительной вероятности неправильной настройки безопасности. Несколько мелочей могут поставить под угрозу безопасность вашей платформы. Например, возможно, что черные шляпы со скрытыми целями могут обнаружить конфиденциальную информацию, отправленную в ответ на искаженные запросы.
Массовое присвоение
Тот факт, что конечная точка не определена публично, не означает, что разработчики не могут получить к ней доступ. Секретный API может быть легко перехвачен и изменен хакерами. Взгляните на этот базовый пример, в котором используется открытый токен носителя в «частном» API. С другой стороны, общедоступная документация может существовать для чего-то, что предназначено исключительно для личного использования. Открытая информация может использоваться «черными шляпами» не только для чтения, но и для управления характеристиками объекта. Считайте себя хакером, когда будете искать потенциальные слабые места в своей защите. Разрешить только тем, у кого есть соответствующие права, доступ к тому, что было возвращено. Чтобы свести к минимуму уязвимость, ограничьте пакет ответа API. Респондентам не следует добавлять ссылки, которые не являются абсолютно необходимыми.
Рекламируемый API:
Ненадлежащее управление активами
Текущие версии и документация важны не только для повышения производительности труда разработчиков, но и для вашей собственной безопасности. Готовьтесь к выпуску новых версий и прекращению поддержки старых API заранее. Используйте новые API вместо того, чтобы использовать старые. Спецификацию API можно использовать в качестве основного источника достоверной документации.
Впрыск
API-интерфейсы уязвимы для внедрения, как и приложения сторонних разработчиков. Вредоносный код может использоваться для удаления данных или кражи конфиденциальной информации, такой как пароли и номера кредитных карт. Самый важный урок, который можно извлечь из этого, — не зависеть от настроек по умолчанию. Ваш поставщик управления или шлюза должен быть в состоянии удовлетворить ваши уникальные потребности приложений. Сообщения об ошибках не должны содержать конфиденциальную информацию. Чтобы предотвратить утечку идентификационных данных за пределы системы, в токенах следует использовать парные псевдонимы. Это гарантирует, что ни один клиент не сможет работать вместе для идентификации пользователя.
Недостаточное ведение журнала и мониторинг
Когда атака все-таки происходит, командам требуется хорошо продуманная стратегия реагирования. Разработчики будут продолжать эксплуатировать уязвимости, не будучи пойманными, если не будет налажена надежная система регистрации и мониторинга, что приведет к увеличению потерь и ухудшению общественного мнения о компании. Примите строгую стратегию мониторинга API и тестирования конечной точки производства. Белые тестировщики, обнаружившие уязвимости на ранней стадии, должны быть вознаграждены схемой вознаграждения. Журнал можно улучшить, включив идентификатор пользователя в транзакции API. Убедитесь, что все уровни вашей архитектуры API проверены с использованием данных токена доступа.
Заключение
Архитекторы платформ могут оборудовать свои системы, чтобы быть на шаг впереди злоумышленников, следуя установленным критериям уязвимости. Поскольку API-интерфейсы могут обеспечивать доступ к информации, позволяющей установить личность (PII), обеспечение безопасности таких услуг имеет решающее значение как для стабильности компании, так и для соблюдения законодательства, такого как GDPR. Никогда не отправляйте токены OAuth напрямую через API без использования шлюза API и подхода с фантомным токеном.
Рекламируемый API:
