Сломанная авторизация на уровне объекта с примерами

В этом посте мы исследуем и обсуждаем сбой авторизации на уровне сломанных объектов.

Мы начнем с объяснения того, что означает нарушение авторизации на уровне объекта. Затем мы рассмотрим атаку, объясняя связанные с ней факторы риска.

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

Что такое авторизация на уровне сломанного объекта

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

Нарушенная авторизация на уровне объекта в прошлом была известна как незащищенная прямая ссылка на объект (IDOR).

Когда мы говорим слово объект в авторизации на уровне сломанного объекта мы имеем в виду значение или группу значений. Объектом может быть сообщение в социальной сети, которое содержит автора, контент и дату публикации.



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

Когда пользователь делает запрос к API, этот запрос используется для доступа к объектам. Это тот момент, когда следует принять решение об авторизации. Пользователь должен иметь доступ только к тем объектам, к которым ему предоставлен доступ. Это авторизация работает правильно.

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

API облегчает различные операции с объектами. Мы можем получать, создавать, обновлять или даже удалять объекты.

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

Использование уязвимости доступа на уровне сломанных объектов

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

Давайте посмотрим на это на примере.

Здесь у нас есть URL-адрес, который используется для вызова API:

https://myemail.com/messages/12345

Этот вызов API используется для получения личных сообщений пользователя. Используемый ресурс Сообщения .

Сообщение - это объект, на который мы ссылаемся при авторизации на уровне сломанного объекта. Предполагается, что личные сообщения могут быть прочитаны только предполагаемым получателем.

Затем у нас есть идентификатор сообщения 12345. Это важная часть для злоумышленника.

Идентификатор сообщает службе, какую запись нужно вернуть. API извлекает эту запись из хранилища данных и возвращает ее в ответе.

Что произойдет, если мы изменим идентификатор с 12345 к 12346? например:

https://myemail.com/messages/12346

Если сообщение с id 12346 был предназначен для нашего пользователя, мы должны иметь возможность его получить.

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

Другой пример - отправка запроса POST для обновления ресурса. Мы можем поиграть с идентификатором в полезной нагрузке JSON:

{
'userId': '12345678',
'oldPassword': 'My_0ld_Pa$$',
'newPassword': '$uperS3CurE' }

Если бы мы поместили любой потенциал userId в запросе и смогли обновить данные другого пользователя, то у нас возникла серьезная проблема.

Техническое воздействие

Как только мы узнаем, что уязвимость существует, мы можем использовать ее всеми способами. Как упоминалось ранее, мы можем использовать различные методы HTTP в API. Мы можем использовать Id для обновления или даже удаления сообщений!

Что произойдет, если мы сможем перебрать все идентификаторы? Возможно, мы сможем удалить все сохраненные сообщения. Это большое влияние.

Общая уязвимость

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

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

Во-первых, контроль безопасности просто не был реализован. Код не был написан для проверки авторизации запросов.

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

Как обнаружить

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

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

Обратите внимание, что идентификатор может быть в URL-адресе, в теле запроса или в заголовке.

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

Инструменты

Мы можем использовать любой инструмент, который проверяет HTTP-запросы и ответы. Вот некоторые из них:

  • Инструменты разработчика Google
  • Люкс Burp
  • Почтальон

Burp Suite также можно использовать для автоматизации некоторых запросов.

Защита от неработающей авторизации на уровне объекта

У нас здесь две защиты.

Первая защита - использовать непредсказуемые идентификаторы, такие как GUID . Когда мы используем в коде последовательные числа, например 12345, это означает, что идентификаторы очень предсказуемы. Злоумышленнику не нужно прилагать много усилий, чтобы перебирать числа, чтобы найти объекты.

Пример GUID:

d3b773e6-3b44-4f5f-9813-c39844719fc4

GUID сложны, их трудно угадать, и они не являются последовательными.

Следующая защита - это действительно иметь код для проверить авторизацию . Этой проверки часто просто не бывает.

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

Запрошенный идентификатор необходимо проверить, чтобы подтвердить, что пользователь авторизован для доступа к объекту.

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

Заключение

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

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

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