Перевод: Нарушенный контроль доступа

Привет, друзья, надеюсь, у вас все хорошо! В OWASP Top 10 2021, нарушенный контроль доступа (BAC) занял первую позицию с самым серьезным риском безопасности. Проблемы с нарушенным контролем доступа возникают, когда ограничения накладываются только на фронтенд, а API-интерфейсы бэкенда не защищаются. Использование легко перечисляемых идентификаторов является первопричиной небезопасных прямых ссылок на объекты (IDOR).

В этой статье я расскажу о своем подходе и сценариях, с которыми я столкнулся.

Что такое контроль доступа?

Аутентификация идентифицирует пользователя и проверяет его.

Управление сессиями определяет, какие последующие HTTP-запросы выполняются тем же пользователем.

Контроль доступа определяет, разрешено ли пользователю выполнять действие, которое он пытается выполнить.

Вертикальные средства контроля доступа

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

Например, администратор может иметь возможность изменять или удалять учетную запись любого пользователя, в то время как обычный пользователь не имеет доступа к этим действиям.

Горизонтальные средства контроля доступа

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

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

Контекстно-зависимые средства контроля доступа

Контекстно-зависимые средства контроля доступа предотвращают выполнение пользователем действий в неправильном порядке.

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

Нарушенный контроль доступа

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

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

Примеры нарушенного контроля доступа

Нарушенный контроль доступа происходит, когда пользователь может выполнять действия, которые он не должен делать.

Вертикальная эскалация привилегий

Доступ к функциям, доступ к которым запрещен.

Например: Пользователь может получить доступ к панели администратора и удалить учетную запись любого пользователя.

Горизонтальная эскалация привилегий

Горизонтальная эскалация привилегий возникает, когда пользователь может получить доступ к ресурсам, принадлежащим другому пользователю. Например, если сотрудник должен иметь доступ только к своим собственным записям о работе и заработной плате, но на самом деле может получить доступ к записям **других сотрудников**.

Например, пользователь обычно может получить доступ к странице своей учетной записи, используя URL-адрес, подобный следующему: [https://insecure-website.com/myaccount?id=123] (https://insecure-website.com/myaccount?id=123), в этом сценарии, если злоумышленник сможет изменить параметр id, это приведет к горизонтальной эскалации привилегий.

Горизонтальная и вертикальная эскалация привилегий

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

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

Небезопасные прямые ссылки на объекты (IDOR)

Это уязвимость контроля доступа, которая возникает, когда приложение использует пользовательский ввод для прямого доступа к объектам.

Уязвимости IDOR чаще всего связаны с горизонтальной эскалацией привилегий, но могут возникать и при вертикальной.

Вопросы, связанные с функциональностью

При тестировании любого приложения, в котором есть роли пользователей, всегда нужно думать о следующих вопросах:

• Каковы полномочия этого пользователя?
• Имеет ли пользователь разрешение на выполнение этого действия?
• Может ли этот пользователь просматривать эти данные?
• Каковы будут последствия для бизнеса, если наложенный контроль доступа может быть нарушен?

Сценарии, возникающие при тестировании приложений на нарушение контроля доступа

Давайте рассмотрим некоторые из сценариев, с которыми я столкнулся.

Сценарий 1 - Небезопасная прямая ссылка на объект (IDOR) приводит к раскрытию конфиденциальной информации

Приложение представляло собой управление государственными фондами. Приложение позволяло пользователю проверять файлы платежей. В процессе тестирования я открыл файл и обратил внимание на идентификатор файла в URL, после чего изменил его на другой. Я был удивлен, увидев, что загрузился файл, содержащий конфиденциальные банковские реквизиты другого пользователя. Следовательно, небезопасная прямая ссылка на объект (IDOR) привела меня к перечислению банковских реквизитов всех других пользователей, что привело к простой проблеме нарушения контроля доступа.

Сценарий 2 - Нарушение бизнес-логики в платформе управления поставками

В этом сценарии приложение представляло собой некую платформу управления поставками. В ней записи должны были быть одобрены другим пользователем (проверяющим). Создатель не может утверждать свои собственные записи. Бизнес-логика, применяемая в этом приложении, аналогична той, когда один и тот же пользователь не может утверждать собственные записи. Например, если USER1 создал запись RECORD1 и пытается утвердить ее, ответ показывает, что создатель и проверяющий не могут быть одним и тем же. Теперь попробуйте утвердить запись USER2, которая является RECORD2. После наблюдения за POST-запросом на утверждение я понял, что ID записи передается в URL и теле запроса. Поэтому я изменил ID на RECORD1 и отправил запрос. К моему удивлению, запись была одобрена. Таким образом, изменив ID, я смог обойти наложенный контроль доступа.

Сценарий 3 - Принудительный просмотр

Это приложение предназначено для управления фондами. Это банковское приложение содержит 2 типа пользователей - Внутренний пользователь (сотрудники банка) и внешний пользователь (клиенты). Во время работы над приложением я заметил дашборд, где роль пользователя была указана в URL. Я изменил ее на admin и увидел, что открылась панель администратора. Функции администратора и данные пользователя банка, такие как имя, роль, номер мобильного телефона и адрес электронной почты, открыты для внешних пользователей. В результате я смог нарушить контроль доступа, наложенный путем изменения URL-адреса.

Сценарий 4 - Нарушение бизнес-логики путем изменения проверки на стороне клиента

В этом случае приложение имело дело с расчетами между двумя банками по транзакциям ATM/POS, где поддерживаются пороговые проценты. Создатель не может утверждать свои собственные записи. Когда я тестировал функциональность Maker-Checker, приложение сказало: "Maker и Checker не должны совпадать" для утверждения собственной созданной записи. После просмотра сообщения в отладчике мы видим, что функция, отвечающая за проверку на стороне клиента: if (Checker==Maker [0]) выдает сообщение об ошибке, поэтому я изменил запрос, содержащий логику с (Checker!=Maker[0]). Затем я попытался одобрить свои собственные записи и запись была одобрена успешно.

Как защитить себя

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

Уязвимости контроля доступа, как правило, можно предотвратить, используя подход "защита в глубину" и применяя следующие принципы:

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

Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.

Перевод статьи был выполнен проектом перевод энтузиаста:

• 📚 @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности
• 🔥 @Ent_Translate - Инстаграм проекта