Введение
Небезопасная прямая ссылка на объект (Insecure Direct Object Reference, IDOR) — это тип уязвимости контроля доступа, возникающий, когда приложение использует предоставленные пользователем входные данные для прямого доступа к объектам. Если приложение не проверяет должным образом, имеет ли пользователь, запрашивающий объект, право на доступ к нему, злоумышленник может изменить ссылку (например, ID базы данных, имя файла или ID пользователя в URL) для получения доступа к конфиденциальным данным других пользователей.
Важно понимать, что сама по себе ссылка не является уязвимостью. Уязвимость заключается в доверии к этой ссылке без проверки того, разрешено ли текущему пользователю переходить по ней.
В этой лабораторной работе вы выступите в роли специалиста по безопасности, тестирующего локальный веб-API. Вы начнете с аутентификации в качестве обычного пользователя, проанализируете, как приложение ссылается на ваш профиль, а затем используете уязвимость IDOR для доступа к личным данным других пользователей, включая администратора.
Аутентификация в качестве обычного пользователя
На этом этапе вы будете взаимодействовать с локальным веб-API, работающим на вашем компьютере на порту 5000. Чтобы начать тестирование приложения на наличие уязвимостей, сначала необходимо аутентифицироваться как обычный пользователь и получить действительный токен сессии.
Нам предоставлены учетные данные для обычного пользователя по имени Элис (Alice). Ее имя пользователя — alice, а пароль — password123.
Вы будете использовать инструмент командной строки curl для отправки HTTP-запроса POST к конечной точке входа в систему. curl — это мощный инструмент для передачи данных на сервер или с сервера.
Выполните следующую команду в терминале, чтобы войти в систему:
curl -X POST http://localhost:5000/api/login \
-H "Content-Type: application/json" \
-d '{"username": "alice", "password": "password123"}'
Разберем эту команду:
-X POSTуказывает, что мы отправляем запрос POST, который обычно используется для отправки данных, таких как учетные данные для входа.-H "Content-Type: application/json"сообщает серверу, что отправляемые нами данные отформатированы как JSON.-d '...'содержит полезную нагрузку JSON с именем пользователя и паролем.
Если учетные данные верны, вы увидите вывод, похожий на этот:
{"token": "Bearer alice_token", "user_id": "1001"}
Запишите token и user_id. Токен (Bearer alice_token) действует как ваше цифровое удостоверение. Вам нужно будет включать его в последующие запросы, чтобы подтвердить, что вы прошли аутентификацию. user_id (1001) — это ваш уникальный идентификатор в базе данных приложения.
Анализ ссылок на объекты (URL/API)
Теперь, когда вы аутентифицированы как Элис, вы можете получить доступ к ее профилю пользователя. Во многих веб-приложениях доступ к профилям пользователей осуществляется через конечную точку API, которая требует ваш токен аутентификации и ссылку на конкретный объект (в данном случае профиль пользователя), который вы хотите просмотреть.
Вы снова будете использовать curl, но на этот раз отправите запрос GET к конечной точке /api/profile. Вы должны включить токен аутентификации в заголовки HTTP и указать свой user_id в URL.
Это именно тот шаблон, который встречается в реальных API: токен подтверждает существование сессии, а параметр выбирает объект для получения. Безопасные приложения должны связывать эти две идеи вместе с помощью проверок авторизации.
Выполните следующую команду, чтобы просмотреть профиль Элис:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1001"
В этой команде:
-H "Authorization: Bearer alice_token"передает ваше цифровое удостоверение на сервер.?user_id=1001— это параметр запроса, добавленный к URL. Это и есть прямая ссылка на объект. Она точно указывает серверу, какую запись в базе данных нужно извлечь.
Вы должны получить ответ в формате JSON, содержащий информацию о профиле Элис:
{"name": "Alice", "role": "user", "email": "alice@example.com", "secret": "alice_secret_123"}
Обратите внимание, как приложение полагается на параметр user_id=1001 в URL, чтобы решить, какие данные вернуть. Безопасное приложение проверило бы, действительно ли пользователю, связанному с Bearer alice_token, разрешено просматривать данные для user_id=1001. Если приложение не выполняет эту проверку авторизации, оно уязвимо для IDOR.
Манипуляция идентификаторами пользователей
На этом этапе вы проверите, правильно ли приложение обеспечивает контроль доступа. В данный момент вы аутентифицированы как Элис, но что произойдет, если вы запросите у сервера данные другого пользователя?
Это ключевой вопрос авторизации. «Вошел ли я в систему?» и «Разрешено ли мне читать этот объект?» — это разные проверки, и их смешение ведет прямо к IDOR.
Предположим, есть другой обычный пользователь по имени Боб (Bob), и его ID пользователя — 1002. Если приложение уязвимо для IDOR, оно будет слепо доверять параметру user_id в URL, не проверяя, есть ли у Элис разрешение на просмотр профиля Боба.
Измените параметр user_id в вашей предыдущей команде с 1001 на 1002. Выполните следующую команду:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1002"
Посмотрите на вывод, возвращенный сервером:
{"name": "Bob", "role": "user", "email": "bob@example.com", "secret": "bob_secret_456"}
Вы успешно получили личную информацию Боба, включая его электронную почту и секретный ключ, оставаясь при этом аутентифицированным как Элис!
Это подтверждает наличие уязвимости «Небезопасная прямая ссылка на объект» (IDOR). Сервер проверил, что вы вошли в систему (путем проверки токена), но не проверил, авторизованы ли вы для доступа к конкретному объекту (профилю Боба), который вы запросили.
Доступ к неавторизованным данным
Подтвердив наличие уязвимости IDOR, вы теперь можете расширить атаку, чтобы получить доступ к высокочувствительной информации. Во многих системах административные пользователи имеют предсказуемые ID, такие как 1, 0 или 9999.
Для этого приложения ID пользователя администратора — 9999. Используя ту же уязвимость IDOR, вы можете попытаться извлечь профиль администратора, который содержит секретный флаг.
Чтобы задокументировать свою находку, вы перенаправите вывод команды curl в файл с именем flag.txt в вашем текущем рабочем каталоге (~/project).
Выполните следующую команду, чтобы получить профиль администратора и сохранить его:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=9999" > ~/project/flag.txt
Символ > перенаправляет вывод, который обычно отображается на экране, в указанный файл.
Чтобы убедиться, что вы успешно захватили данные администратора, прочитайте содержимое файла с помощью команды cat:
cat ~/project/flag.txt
Вы должны увидеть данные профиля администратора, включая секретный флаг:
{"name": "Admin", "role": "admin", "email": "admin@example.com", "secret": "FLAG{IDOR_VULN_EXPLOITED}"}
Поздравляем! Вы успешно использовали уязвимость IDOR, чтобы обойти контроль доступа и получить конфиденциальные административные данные.
Резюме
В этой лабораторной работе вы изучили механизмы уязвимости «Небезопасная прямая ссылка на объект» (IDOR) — критического недостатка контроля доступа. Вы начали с аутентификации в качестве обычного пользователя и анализа того, как приложение ссылается на данные пользователей через параметры URL. Манипулируя этими параметрами, вы успешно обошли проверки авторизации и просмотрели личные профили других пользователей. Наконец, вы расширили атаку, чтобы извлечь конфиденциальные административные данные.
Это упражнение подчеркивает важность реализации надежных проверок авторизации на стороне сервера. Приложения никогда не должны полагаться исключительно на предоставленные пользователем входные данные для предоставления доступа к объектам; они всегда должны проверять, имеет ли аутентифицированный пользователь явное право на доступ к запрашиваемому ресурсу.
