Защита API от несанкционированного доступа: вход, права, лимиты и защита от перебора

Три уровня проверки

• Метод. Может ли эта роль вообще вызвать этот метод. Её проверяют почти всегда.
• Объект. Может ли она открыть именно этот заказ, документ или контрагента. Здесь чаще всего ошибаются: объект берут по номеру из запроса, а принадлежность организации не проверяют.
• Поле. Какие поля видны и какие можно менять. Партнёр видит свою цену, но не себестоимость; пользователь не должен передавать в запросе поле «роль» или «скидка» и получать запись.

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

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

Как мы это проверяем

Берём две учётные записи в разных организациях с одной ролью и пробуем из-под каждой обратиться к объектам другой: читать, менять, удалять, скачивать файл. Затем так же из-под разных ролей одной организации. Результат записывается в матрицу «роль — метод — объект — результат», и она остаётся у вас как набор тестов. Код обработчиков читаем отдельно, подход описан на странице Secure code review.

Подбор паролей идёт двумя способами. Первый — перебор по словарю для одной записи, его видно по лимитам. Второй — проверка пар «адрес — пароль», утёкших с чужих сервисов: на каждую запись приходит по одной-две попытки с разных адресов, и простой лимит по адресу ничего не показывает. Защита строится в таком порядке:

1. Одинаковый ответ. Вход, восстановление и регистрация не должны сообщать, существует ли такая запись.
2. Лимиты по записи и по адресу. Нарастающая задержка, а не вечная блокировка: блокировка по записи позволяет вывести из строя чужую учётную запись.
3. Хранение паролей. Специальный медленный алгоритм с солью, а не быстрый хеш. При утечке базы это замедляет подбор.
4. Проверка пароля при установке. Отказ для слишком простых и известных по утечкам вариантов.
5. Второй фактор для ролей с доступом к деньгам и персональным данным. Выбор способа разобран в статье «SSO и MFA: что выбрать», вход сотрудников и единый вход — на странице SSO и MFA для корпоративных систем.
6. Оповещение. Всплеск неудачных входов по одной записи или с одного адреса доходит до человека, который может отреагировать.

Журнал, в который пишется всё подряд, не читает никто. Для защиты API нужны события с понятным составом: кто (учётная запись или ключ), откуда, что запросил, какой был ответ. Их набор небольшой:

• успешные и неудачные входы, смена пароля, выдача и отзыв ключей;
• отказы в доступе («нет прав», «не найдено» на чужой объект), особенно серии подряд;
• превышения лимитов;
• смена ролей и прав и массовые выгрузки.

Пароли, токены и ключи в журнал не попадают, даже в сообщениях об ошибках. Мы настраиваем отправку событий в то, чем вы пользуетесь для мониторинга, и 2–3 оповещения на серии отказов и неудачных входов. Систем обнаружения вторжений, SIEM и дежурства мы не предоставляем: события должны дойти до вашего человека.

Если API нужно построить, а не защитить, начинайте с разработки API и бэкенда: защита закладывается в проект сразу. Если нужно, чтобы сотрудники входили во все системы одним входом и со вторым фактором, это SSO и MFA. Если вопрос шире API и касается всего приложения, нужен аудит безопасности веб-приложения, а если только код, то ревью кода. Защита от внедрения запросов и подмены содержимого страниц описана на странице о защите от SQL-инъекций и XSS. Порядок мер по шагам лежит в статье «Как защитить API от взлома».