API2:2019 Некорректная Аутентификация Пользователей
| Источники угроз/Векторы атак | Недостатки безопасности | Последствия |
|---|---|---|
| Зависит от API : Сложность эксплуатации 3 | Распространенность 2 : Сложность обнаружения 2 | Технические последствия 3 : Зависит от бизнеса |
| Аутентификация в API - сложный и запутанный механизм. Разработчики и инженеры безопасности могут иметь неверное представление о том, что входит в понятие аутентификации, и как правильно ее внедрить. Кроме того, механизм аутентификации - простая цель для злоумышленников, поскольку он общедоступен. Все это приводит к тому, что механизм аутентификации потенциально содержит большое число уязвимостей. | Механизм аутентификации подвержен двум основным проблемам: 1. Отсутствие механизмов защиты: разработчики должны обращать особое внимание на точки входа API, отвечающие за аутентификацию, и внедрять дополнительные уровни защиты. 2. Некорректная реализация механизма: механизм используется или реализован, не принимая во внимание основные векторы атак, или используется механизм, не подходящий под текущую ситуацию (например, механизм аутентификации для IoT устройств зачастую не подходит для веб приложений). | Злоумышленник может получить контроль над учетными записями других пользователей в системе, получить доступ к их персональным данным, или осуществить критичные действия от их имени, например, отправить денежные переводы или персональные сообщения. |
Как определить, является ли API уязвимым?
Точки входа, отвечающие за аутентификацию и процесс аутентификации, - это активы, требующие защиты. Необходимо относиться к функционалу восстановления пароля аналогично механизму аутентификации.
API уязвим, если:
* Позволяет перебор учетных данных, при условии, что у злоумышленника есть списки существующих логинов и паролей.
* Позволяет злоумышленнику подбирать пароль к одной и той же учетной записи путем перебора, не требуя ввода CAPTCHA или не блокируя учетную запись.
* Допускает слабые пароли.
* Передает критичные аутентификационные данные в URL, например, аутентификационные токены или пароли.
* Не проверяет подлинность токенов.
* Допускает JWT токены не содержащие подпись ("alg":"none") или использующие уязвимые алгоритмы подписи, не проверяет срок действия токена.
* Хранит пароли в открытом виде или в хэшированном виде с использованием слабых алгоритмов хеширования.
* Использует слабые ключи шифрования.
Примеры сценариев атаки
Сценарий #1
Перебор учетных данных с использованием списка известных логинов и паролей - распространенная атака. Если в приложении отсутствуют автоматизированные меры защиты от угроз или перебора учетных данных, то оно может быть использовано для определения валидности учетных данных.
Сценарий #2
Злоумышленник начинает восстановление пароля, отправив POST запрос в точку входа /api/system/verification-codes и указав имя пользователя в теле запроса. Затем одноразовый пароль из 6 цифр отправляется на телефон жертвы. Поскольку API не ограничивает количество запросов, злоумышленник может за несколько минут подобрать корректный одноразовый пароль, перебирая все возможные пароли с помощью скрипта, работающего в многопоточном режиме и отправляющего запросы на /api/system/verification-codes/{smsToken}.
Как предотвратить?
- Идентифицируйте все возможные способы аутентификации в API (для мобильных и веб клиентов, deep links, обеспечивающих аутентификацию в одно нажатие, и так далее).
- Спросите у разработчиков, какие способы аутентификации вы пропустили.
- Изучите используемые механизмы аутентификации. Изучите, что они из себя представляют и как используются. OAuth не используется для аутентификации пользователей, так же как и API ключи.
- Не изобретайте велосипед, когда речь идет об аутентификации, генерации токенов и хранении паролей. Используйте стандарты.
- Внедрите защиту от перебора, ограничение на количество единовременных запросов и временную блокировку учетных записей на точках входа, отвечающих за восстановление учетных данных и пароля, аналогично мерам защиты на точках входа, используемых для аутентификации.
- Ознакомьтесь с OWASP Authentication Cheatsheet.
- Используйте многофакторную аутентификацию, где это возможно.
- Используйте механизмы защиты от перебора учетных данных, перебора по словарю и перебора всех возможных значений на точках входа, отвечающих за аутентификацию. Эти механизмы должны использовать более строгие правила по сравнению с механизмом ограничивающим количество запросов в остальных точках входа API.
- Внедрите блокировку учетных записей или CAPTCHA для предотвращения перебора аутентификационных данных, направленного на единичных пользователей. Внедрите защиту от слабых паролей.
- Не используйте API ключи для аутентификации пользователей. Они должны использоваться для аутентификации приложений и проектов, являющихся клиентами API.