Безопасность API: что проверять

Матрица доступа: где на самом деле дыра

Разберу ту матрицу. Наивная проверка спрашивает два вопроса: залогинен ли человек и подходит ли его роль. Оба ответа «да» - доступ открыт. Но не задан третий вопрос: а этот объект вообще его? Правильная проверка добавляет условие «владелец объекта совпадает с тем, кто спрашивает, либо это администратор» - и те же два сочетания сразу закрываются.

Такая дыра называется IDOR (insecure direct object reference) - небезопасная прямая ссылка на объект; в списке OWASP (Open Web Application Security Project) она же значится как BOLA (broken object level authorization), нарушенная проверка доступа на уровне объекта. Это самая частая уязвимость API, и живёт она не в строке «мне нельзя», а в ячейке «моя роль, чужой объект».

// Как проверять: завести двух пользователей, создать объект под первым, запомнить его идентификатор и запросить под вторым. Ожидаемый ответ - отказ, а не чужие данные. Прогонять надо все операции, включая изменение и удаление, и обязательно напрямую через API: в интерфейсе кнопки чужого объекта просто не показаны, и через него дыру не увидишь. И не надейтесь, что идентификаторы «никто не угадает» - они утекают в ссылках, письмах и логах.

IDOR

insecure direct object reference: чужой объект по подменённому идентификатору

матрица доступа

роль, ресурс, операция и обязательно «чужой объект своей роли»

Инъекции и лишние поля

Замер первый. В поле поиска ввожу anna' or '1'='1. Если сервер склеивает запрос к базе строками, кавычка закрывает условие и остаток моего ввода становится частью самой команды. Это называется инъекцией: чужой текст просочился внутрь запроса и выполнился как его часть. Мне вернулись обе строки таблицы, включая чужую запись «коды от сейфа». Тот же ввод в параметризованном запросе, где значение передаётся отдельно от текста команды, вернул ноль строк: он остался просто текстом.

Замер второй. Пользователь отправляет на обновление профиля {"name": "Анна Б", "is_admin": true}. Обработчик, который «просто применяет, что прислали», поднял человеку права администратора. С белым списком разрешённых полей - только имя и почта - права остались на месте. Это называется массовым присваиванием, и проверяется подстановкой привилегированных полей в каждый принимающий адрес.

// Третье - чужой скрипт в данных. Если API принял <script> и сохранил, а веб-клиент потом это нарисовал, скрипт выполнится у всех, кто откроет страницу. Проверять это в консольном клиенте бессмысленно: там ничего не рисуется. Смотреть надо в браузере, куда данные в итоге попадают.

параметризованный запрос

значение передаётся отдельно от текста команды и не может стать командой

массовое присваивание

сервер применяет лишние поля из запроса, включая привилегированные

Утечки: словами и секундомером

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

А есть неочевидная - по времени. Замер: сервер на любой неверный вход отвечает одинаковым текстом «неверный логин или пароль». Но для существующего пользователя он тратит 52 миллисекунды на проверку пароля, а для несуществующего отвечает мгновенно, за доли миллисекунды. Разница в тысячи раз, и по ней логины перебираются с секундомером - текст ответа тут ничего не скрывает.

// Рядом живёт ограничение частоты запросов: у входа, отправки кодов и дорогих операций должен быть предел, после которого приходит отказ с кодом 429. Тестируют и сам предел, и обходы вокруг него: смена адреса, смена регистра логина, параллельные соединения. Общий чек-лист по всему этому - список OWASP для API.

утечка по времени

ответ одинаковый, а длительность выдаёт, есть ли такой пользователь

ограничение частоты

предел числа запросов, после которого приходит отказ 429

Как отвечать: «Что такое IDOR и как его тестировать?»

IDOR - это когда доступ к объекту проверяется только по идентификатору из запроса, без вопроса, а чей это объект. Роль тут не спасает. У меня легально есть роль обычного пользователя и доступ к чтению заказов - но если я подставлю чужой номер заказа и сервер отдаст его, потому что проверил лишь «залогинен и роль подходит», это дыра. Я строил такую матрицу: два пользователя, два заказа, шесть сочетаний - и два из них оказались открыты, каждый читал чужое. Поэтому тестирую я не «под своей ролью мне нельзя», а именно между объектами одной роли: завожу двух пользователей, создаю объект под первым, беру его идентификатор и запрашиваю под вторым. Ответ должен быть отказом, а не чужими данными. Прогоняю так все операции, включая изменение и удаление, и обязательно напрямую через API, а не через интерфейс - там кнопки чужого объекта просто не показаны, и дыру не увидишь. И не принимаю аргумент «идентификаторы никто не угадает»: они утекают в ссылках, письмах и логах, а последовательные номера просто перебираются.

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

На чём валят

• −Проверять доступ только «мне нельзя»: в матрице открытыми оказались ячейки «своя роль, чужой объект».
• −Склеивать запрос к базе строками: ввод с кавычкой вернул всю таблицу вместо одной строки.
• −Применять присланные поля без белого списка - обычный пользователь стал администратором.
• −Считать одинаковый текст ответа защитой: разница во времени в тысячи раз выдаёт существующие логины.
• −Токен в адресе запроса - он уже в логах сервера, в истории браузера и в статистике переходов.