Чем в действительности могут угрожать небезопасные прямые ссылки на объекты?
Небезопасные прямые ссылки на объекты (Insecure Direct Object Reference, IDOR) являются распространёнными и потенциально разрушительными уязвимостями, возникающими в результате неграмотной настройки доступов в веб-приложениях.
Уязвимости IDOR позволяют киберпреступнику злонамеренно взаимодействовать с вашим веб-приложением, манипулируя «прямой ссылкой на объект», такой как, например, ключ базы данных, параметр запроса или имя файла.
В этой статье мы постараемся ответить на следующие ключевые вопросы:
— Что такое IDOR?
— Как найти данную уязвимость в своём веб-приложении?
— Что можно сделать, чтобы защититься от IDOR?
Возьмём в качестве примера реальный случай, произошедший за рубежом много лет назад. Один из студентов рядового иностранного ВУЗа открыл свой университетский профиль, перешёл в раздел с расписанием занятий и заметил в адресной строке следующее содержимое:
« » (URL указан для примера).
Очевидно, что идентификатор «000021156», раз он отображается в личном кабинете студента, явно принадлежит именно ему. Однако, что будет, если изменить его на другой? Хотя бы просто поменять одну цифру. Любопытство взыграло над студентом, и он совершил задуманное, получив доступ к расписанию занятий, а затем и всем остальным данным из личного кабинета совсем другого студента этого университета.
Подобную процедуру по получению доступа к чужим данным можно было повторять бесконечно, подставляя действительные идентификаторы других учащихся, если они известны, или банально угадывать их, ведь они назначались студентам по порядку.
Чтобы такая уязвимость сработала в современном веб-приложении, множество вещей должны пойти не так. Во-первых, приложение, очевидно, не должно включать никаких дополнительных проверок авторизации, чтобы понять, должен ли конкретный пользователь иметь доступ к запрошенной информации. То есть доступ к данным должен быть реализован «небезопасным» способом.
Во-вторых, база данных уязвимого веб-приложения должна работать исключительно на основе идентификатора пользователя, то есть должна существовать некая «прямая ссылка на объект», по которой можно считать всю информацию.
Наконец, идентификаторы должны быть перечислены в адресной строке в удобном для распознавания формате, что позволит легко манипулировать ими даже человеку, не обладающему какими-либо познаниями в области хакинга.
Готовые популярные CMS-решения, как правило, не грешат подобными недостатками безопасности, однако создавая своё веб-приложение с нуля, было бы неплохо убедиться в том, что вы не совершили ту же ошибку, что и специалисты упомянутого выше университета.
Некоторые способы выявления уязвимостей включают в себя:
1. Фальсификация URL
Фальсификация URL-адресов — это самый простой способ использовать уязвимость IDOR. Для его использования не требуется значительных технических знаний, потому что всё, что необходимо сделать для успешной эксплуатации — просто изменить видимое значение параметра в адресной строке веб-браузера. Конечный результат всегда один: сервер предоставляет атакующему неправомерный доступ к той информации, доступа к которой у него не должно быть.
2. Манипуляции с телом
Манипуляции с телом веб-приложения очень похожи на фальсификацию URL-адресов, за исключением того, что злоумышленник изменяет одно или несколько значений в теле сайта, а не в URL-адресе. Это может означать изменение значений переключателей, флажков или других элементов формы, включая скрытые значения.
Возможно, форма обладает скрытыми значениями, которые могут быть найдены в коде сайта. Например, скрытое значение для передачи идентификатора конкретного пользователя системы текущему активному сеансу. Если злоумышленник сможет изменить такое скрытое значение до отправки формы, он сможет сделать так, чтобы его запросы исходили от другого пользователя системы.
3. Манипуляции с cookie-файлами или JSON ID
Cookie-файлы, как и JSON, широко используются за кулисами веб-приложений для хранения и обмена данными между клиентом и сервером, помогая сделать веб-страницы более динамичными. Например, когда мы заходим на веб-сайт, сервер может хранить значение идентификатора пользователя или сеанса как раз внутри cookie-файла или объекта JSON. Если веб-приложение содержит уязвимость IDOR, злоумышленник может изменить эти значения.
4. Обход пути
Обход пути, также называемый обходом каталога, — это уникальный тип уязвимости IDOR, который злоумышленник может использовать для доступа и управления файлами или папками непосредственно на сервере, на котором выполняется веб-приложение. Такая атака куда глубже, чем другие типы атак IDOR, поскольку она позволяет получить прямой доступ к ресурсам файловой системы, а не к записям базы данных.
Обход пути может позволить злоумышленнику получить доступ к файлам конфигурации, узнать учётные данные пользователей или даже получить полнофункциональную оболочку цели.
1. Внедрите надлежащий контроль доступа и управление сеансами
Open Web Application Security Project (OWASP), участники которого и придумали термин «небезопасная прямая ссылка на объект», рассматривает IDOR прежде всего как проблему контроля доступа. Надлежащие проверки контроля доступа и функции управления сеансом должны предотвращать доступ злоумышленника к данным или манипулирование ими, даже если в системе используются легко поддающиеся перечислению идентификаторы. Памятки OWASP по и могут быть полезны для ознакомления перед внедрением подобной защиты.
2. Избегайте прямых ссылок на объекты
Помимо проблем с контролем доступа, использование прямых ссылок на объекты в веб-приложении часто считается неаккуратной практикой кодинга. Особенно, когда речь идёт о конфиденциальных данных, таких как идентификаторы клиентов, сотрудников, номера счетов и т.д. Косвенные ссылки на объекты — часто в виде справочных карт или хеширования — устраняют уязвимости IDOR, скрывая или запутывая истинный идентификатор. Если же используются хэши, не забудьте включить сильную и уникальную соль, так как базовые алгоритмы хеширования, такие как MD5, легко отменить при помощи специализированного софта.
3. Используйте GUID или случайные идентификаторы
В приложениях, использующих последовательные идентификаторы или значения параметров, эксплуатация IDOR не составляет труда. Если потенциальный злоумышленник заметит, что идентификатор пользователя в системе выглядит как «0001», то он может сделать вполне обоснованное предположение, что существует пользователь «0002», «0003» и т.п.
Современные вычислительные мощности и методы автоматизации позволяют довольно легко перебрать все возможные значения от 0000 до 9999, пока хакер не найдёт нужного ему пользователя.
Тем не менее, ни GUID, ни универсальные уникальные идентификаторы до конца не устраняют основную природу уязвимости IDOR. Они лишь значительно усложняют её эксплуатацию.
4. Перепроверяйте вводимые пользователями данные
Проверка пользовательского ввода может помочь смягчить множество проблем безопасности, включая IDOR. Перечисление идентификаторов становится намного сложнее, если введённые пользователем параметры будут проверены на правильную и допустимую длину/формат. Проверка может выполняться либо на стороне клиента, либо на стороне сервера, в зависимости от того, что является наиболее подходящим в конкретной ситуации.
Кроме того, при проектировании приложений стоит изначально закладывать надёжные механизмы авторизации и избегать прямых ссылок на конфиденциальные данные. Тщательный и проактивный подход к безопасности — лучшее средство защиты от атак, эксплуатирующих уязвимости IDOR и им подобные.
Небезопасные прямые ссылки на объекты (Insecure Direct Object Reference, IDOR) являются распространёнными и потенциально разрушительными уязвимостями, возникающими в результате неграмотной настройки доступов в веб-приложениях.
Уязвимости IDOR позволяют киберпреступнику злонамеренно взаимодействовать с вашим веб-приложением, манипулируя «прямой ссылкой на объект», такой как, например, ключ базы данных, параметр запроса или имя файла.
В этой статье мы постараемся ответить на следующие ключевые вопросы:
— Что такое IDOR?
— Как найти данную уязвимость в своём веб-приложении?
— Что можно сделать, чтобы защититься от IDOR?
Как работают уязвимости IDOR
Под IDOR чаще всего подразумевают подмену одного из параметров URL-адреса веб-приложения для получения доступа к той информации, которая изначально скрыта от посторонних глаз.Возьмём в качестве примера реальный случай, произошедший за рубежом много лет назад. Один из студентов рядового иностранного ВУЗа открыл свой университетский профиль, перешёл в раздел с расписанием занятий и заметил в адресной строке следующее содержимое:
« » (URL указан для примера).
Очевидно, что идентификатор «000021156», раз он отображается в личном кабинете студента, явно принадлежит именно ему. Однако, что будет, если изменить его на другой? Хотя бы просто поменять одну цифру. Любопытство взыграло над студентом, и он совершил задуманное, получив доступ к расписанию занятий, а затем и всем остальным данным из личного кабинета совсем другого студента этого университета.
Подобную процедуру по получению доступа к чужим данным можно было повторять бесконечно, подставляя действительные идентификаторы других учащихся, если они известны, или банально угадывать их, ведь они назначались студентам по порядку.
Чтобы такая уязвимость сработала в современном веб-приложении, множество вещей должны пойти не так. Во-первых, приложение, очевидно, не должно включать никаких дополнительных проверок авторизации, чтобы понять, должен ли конкретный пользователь иметь доступ к запрошенной информации. То есть доступ к данным должен быть реализован «небезопасным» способом.
Во-вторых, база данных уязвимого веб-приложения должна работать исключительно на основе идентификатора пользователя, то есть должна существовать некая «прямая ссылка на объект», по которой можно считать всю информацию.
Наконец, идентификаторы должны быть перечислены в адресной строке в удобном для распознавания формате, что позволит легко манипулировать ими даже человеку, не обладающему какими-либо познаниями в области хакинга.
Готовые популярные CMS-решения, как правило, не грешат подобными недостатками безопасности, однако создавая своё веб-приложение с нуля, было бы неплохо убедиться в том, что вы не совершили ту же ошибку, что и специалисты упомянутого выше университета.
Распространённые каналы для использования IDOR
В наши дни различные идентификаторы чаще встречаются в заголовках или API, нежели прямо в адресной строке. Однако динамический характер большинства веб-сайтов означает, что идентификаторы и параметры по-прежнему широко используются в той или иной форме. Идентификаторы могут включать:- ключи базы данных;
- параметры запроса;
- идентификаторы пользователя или сеанса;
- имена файлов.
Как выявить уязвимости IDOR
Уязвимости IDOR легко эксплуатировать, однако сами разработчики зачастую могут и вовсе не догадываться об их наличии. Анализ кода и автоматическое сканирование — вполне приемлемы для многих других распространённых проблем безопасности, однако они не так хороши для обнаружения недостатков типа IDOR. Это означает, что для выявления таких уязвимостей может потребоваться ручное тестирование безопасности.Некоторые способы выявления уязвимостей включают в себя:
- выполнение базовых тестов с помощью встроенных инструментов разработчика в веб-браузере;
- использование инструментов «Burp Suite» или «Open Web Application Security Project Zed Attack Proxy» (OWASP ZAP) для повышения эффективности ручного тестирования.
- участие в программе раскрытия уязвимостей;
- найм внешней компании, осуществляющей услуги пентеста для проверки критических веб-приложений.
Четыре типа атак IDOR
Концептуально большинство атак, использующих IDOR, работают аналогичным образом, однако небольшие нюансы всё же имеются.1. Фальсификация URL
Фальсификация URL-адресов — это самый простой способ использовать уязвимость IDOR. Для его использования не требуется значительных технических знаний, потому что всё, что необходимо сделать для успешной эксплуатации — просто изменить видимое значение параметра в адресной строке веб-браузера. Конечный результат всегда один: сервер предоставляет атакующему неправомерный доступ к той информации, доступа к которой у него не должно быть.
2. Манипуляции с телом
Манипуляции с телом веб-приложения очень похожи на фальсификацию URL-адресов, за исключением того, что злоумышленник изменяет одно или несколько значений в теле сайта, а не в URL-адресе. Это может означать изменение значений переключателей, флажков или других элементов формы, включая скрытые значения.
Возможно, форма обладает скрытыми значениями, которые могут быть найдены в коде сайта. Например, скрытое значение для передачи идентификатора конкретного пользователя системы текущему активному сеансу. Если злоумышленник сможет изменить такое скрытое значение до отправки формы, он сможет сделать так, чтобы его запросы исходили от другого пользователя системы.
3. Манипуляции с cookie-файлами или JSON ID
Cookie-файлы, как и JSON, широко используются за кулисами веб-приложений для хранения и обмена данными между клиентом и сервером, помогая сделать веб-страницы более динамичными. Например, когда мы заходим на веб-сайт, сервер может хранить значение идентификатора пользователя или сеанса как раз внутри cookie-файла или объекта JSON. Если веб-приложение содержит уязвимость IDOR, злоумышленник может изменить эти значения.
4. Обход пути
Обход пути, также называемый обходом каталога, — это уникальный тип уязвимости IDOR, который злоумышленник может использовать для доступа и управления файлами или папками непосредственно на сервере, на котором выполняется веб-приложение. Такая атака куда глубже, чем другие типы атак IDOR, поскольку она позволяет получить прямой доступ к ресурсам файловой системы, а не к записям базы данных.
Обход пути может позволить злоумышленнику получить доступ к файлам конфигурации, узнать учётные данные пользователей или даже получить полнофункциональную оболочку цели.
Как IDOR влияет на данные
Уязвимости IDOR зачастую просты в использовании, но последствия таких атак могут быть катастрофичны. Ниже приведены лишь несколько способов, которыми IDOR может повлиять на конфиденциальность, целостность и доступность данных вашей организации:- Конфиденциальность. Как мы видели на примере с университетом, успешная атака IDOR даёт злоумышленнику доступ к тому, что он не должен видеть. Это может быть что угодно: от кода скидки для частых покупателей онлайн-маркетплейса до конфиденциальной личной информации о здоровье пациента или какой-нибудь коммерческой тайны.
- Целостность. В некоторых случаях злоумышленник может использовать IDOR для изменения данных. Обычно эти типы атак манипулируют параметрами в HTTP-запросе POST. Так, в 2020 году один из исследователей безопасности вовремя заметил уязвимость IDOR, которая позволила бы злоумышленнику изменить пароль учётных записей пользователей на веб-серверах Министерства обороны США. Злоумышленники могут использовать аналогичные уязвимости для добавления в систему несанкционированных данных, таких как фальсифицированная финансовая информация или различные компрометирующие документы.
- Доступность. IDOR также можно использовать для снижения доступности ресурсов. Представьте себе функцию в приложении PHP, которая удаляет документы по имени файла. С её помощью без надлежащих проверок авторизации злоумышленник сможет изменить имя нужного ему файла и удалить любые документы, к которым у него даже нет полноценного доступа.
Четыре совета по предотвращению уязвимостей IDOR
Уязвимости IDOR можно предотвратить, избегая прямых ссылок на объекты, реализуя проверку пользовательского ввода и реализуя глобально уникальные идентификаторы (известные как GUID) или случайные идентификаторы. Хотя не существует по-настоящему универсального решения, когда речь идёт о том, как предотвратить уязвимости IDOR, некоторые из перечисленных ниже шагов могут существенно снизить риск их обнаружения и эксплуатации.1. Внедрите надлежащий контроль доступа и управление сеансами
Open Web Application Security Project (OWASP), участники которого и придумали термин «небезопасная прямая ссылка на объект», рассматривает IDOR прежде всего как проблему контроля доступа. Надлежащие проверки контроля доступа и функции управления сеансом должны предотвращать доступ злоумышленника к данным или манипулирование ими, даже если в системе используются легко поддающиеся перечислению идентификаторы. Памятки OWASP по и могут быть полезны для ознакомления перед внедрением подобной защиты.
2. Избегайте прямых ссылок на объекты
Помимо проблем с контролем доступа, использование прямых ссылок на объекты в веб-приложении часто считается неаккуратной практикой кодинга. Особенно, когда речь идёт о конфиденциальных данных, таких как идентификаторы клиентов, сотрудников, номера счетов и т.д. Косвенные ссылки на объекты — часто в виде справочных карт или хеширования — устраняют уязвимости IDOR, скрывая или запутывая истинный идентификатор. Если же используются хэши, не забудьте включить сильную и уникальную соль, так как базовые алгоритмы хеширования, такие как MD5, легко отменить при помощи специализированного софта.
3. Используйте GUID или случайные идентификаторы
В приложениях, использующих последовательные идентификаторы или значения параметров, эксплуатация IDOR не составляет труда. Если потенциальный злоумышленник заметит, что идентификатор пользователя в системе выглядит как «0001», то он может сделать вполне обоснованное предположение, что существует пользователь «0002», «0003» и т.п.
Современные вычислительные мощности и методы автоматизации позволяют довольно легко перебрать все возможные значения от 0000 до 9999, пока хакер не найдёт нужного ему пользователя.
Тем не менее, ни GUID, ни универсальные уникальные идентификаторы до конца не устраняют основную природу уязвимости IDOR. Они лишь значительно усложняют её эксплуатацию.
4. Перепроверяйте вводимые пользователями данные
Проверка пользовательского ввода может помочь смягчить множество проблем безопасности, включая IDOR. Перечисление идентификаторов становится намного сложнее, если введённые пользователем параметры будут проверены на правильную и допустимую длину/формат. Проверка может выполняться либо на стороне клиента, либо на стороне сервера, в зависимости от того, что является наиболее подходящим в конкретной ситуации.
Заключение
Уязвимости IDOR — весьма распространённая проблема веб-приложений, способная нанести серьёзный ущерб конфиденциальности и безопасности данных. Хотя они могут показаться трудноуловимыми, внимательное тестирование и аудит кода помогут выявить их ещё до обнаружения и злонамеренной эксплуатации злоумышленниками.Кроме того, при проектировании приложений стоит изначально закладывать надёжные механизмы авторизации и избегать прямых ссылок на конфиденциальные данные. Тщательный и проактивный подход к безопасности — лучшее средство защиты от атак, эксплуатирующих уязвимости IDOR и им подобные.
