Блог

Jul 07, 2023

API7:2019 Неправильная конфигурация безопасности: что, примеры эксплойтов и методы предотвращения

Главная » Календарь редакций » Безопасность API » API7:2019 Неправильная конфигурация безопасности:

Главная » Календарь редакций » Безопасность API » Неправильная конфигурация безопасности API7:2019: что, примеры эксплойтов и методы предотвращения

Неправильные настройки безопасности представляют собой очень распространенную угрозу безопасности не только в веб-приложениях, но и в API. Они постоянно входят в десятку крупнейших уязвимостей веб-приложений OWASP. Они входили в первоначальный список 10 крупнейших угроз безопасности API OWASP, опубликованный в 2019 году, а теперь попали в обновленный список 2023 года.

Неправильная конфигурация безопасности сохраняет свое 7-е место в рейтингеТоп-10 API OWASP 2023RCиз-за его широкой распространенности, простоты использования и легкости обнаружения.

Что такое неправильные настройки безопасности? Что их вызывает и как их смягчить? Продолжайте читать, чтобы узнать.

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

Неправильные настройки безопасности могут возникнуть из-за неспособности разработчиков и групп ИТ-безопасности адекватно защитить поверхность атаки с помощью правильных конфигураций.

Это просто означает, что основные настройки безопасности API не были реализованы или были реализованы неправильно, в результате чего в API остались опасные пробелы и слабые места. Злоумышленники могут использовать эти бреши для организации массовых атак и утечек данных.

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

// Небезопасный API Endpointapp.get('/api/user/:id', (req, res) => {const userId = req.params.id;// Извлекаем данные пользователя из базы данных без аутентификации или авторизацииUser.findById( userId, (err, user) => {if (err) {return res.status(500).json({ error: 'Внутренняя ошибка сервера' });}if (!user) {return res.status(404) .json({ error: 'Пользователь не найден' });}// Возвращаем данные пользователя datares.json(user);});}); В этом примере конечная точка API /api/user/:id предназначена для получить данные пользователя на основе предоставленного идентификатора. Однако проверки аутентификации или авторизации не предусмотрены.

Код напрямую извлекает пользователя из базы данных, не проверяя личность пользователя и не гарантируя, что у него есть необходимые разрешения.

Злоумышленник, воспользовавшийся этой неправильной конфигурацией, может просто отправить запрос GET к /api/user/:id с любым параметром id и получить данные пользователя без аутентификации или надлежащей авторизации. Это раскрывает конфиденциальную информацию пользователя неавторизованным лицам.

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

Уязвимости неправильной конфигурации системы безопасности бывают разных форм и размеров с разными уровнями риска. Вот несколько примеров того, что может привести к таким неправильным конфигурациям.

Ознакомьтесь с полным списком неправильных конфигураций API на нашем сайте.Контрольный список проверки проникновения API.

Вот пять примеров сценариев атак с использованием неправильной конфигурации API и их потенциальных последствий:

Нарушение Capital One в 2019 году является реальным примером использования злоумышленниками неверных настроек безопасности. В случае с Capital One злоумышленники обнаружили, что WAF с открытым исходным кодом использовался для защиты приложений и API компании. Этот WAF не был должным образом настроен и настроен в соответствии с потребностями и контекстом среды AWS компании. В результате он не следовал принципам нулевого доверия и наименьших привилегий.

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