Данные, данные везде. Как отсутствие ограничения скорости усугубляет серьезные проблемы с безопасностью.
Вы, наверное, слышали о десятке или десятке основных уязвимостей OWASP, угрожающих веб-приложениям. OWASP также периодически выбирает список из десяти основных уязвимостей, угрожающих API-интерфейсам, который называется первой десяткой OWASP API. В настоящее время в десятку лучших API входят нарушение авторизации на уровне объекта, нарушение аутентификации пользователя, чрезмерное раскрытие данных, Отсутствие ресурсов и ограничение скорости, нарушение авторизации на уровне функций, массовое назначение, неправильная конфигурация безопасности, внедрение , Неправильное управление активами и Недостаточное ведение журнала и мониторинг.
Многие из этих уязвимостей затрагивают не только API-интерфейсы, но и компоненты приложения, но они, как правило, проявляются в API-интерфейсах. В прошлый раз мы говорили об уязвимости, которую я постоянно нахожу в приложениях, ориентированных на API: OWASP API # 3, Excessive Data Exposure. Сегодня давайте поговорим о том, что превратит чрезмерное раскрытие данных в утечку данных: OWASP API # 4, Отсутствие ресурсов и ограничение скорости.
OWASP API №4
Отсутствие ресурсов и ограничения скорости - это когда API не ограничивает количество или частоту запросов от конкретного клиента API. Таким образом, клиент API может выполнять тысячи или даже больше вызовов API в секунду или запрашивать сотни или тысячи записей данных одновременно, а сервер все равно будет пытаться выполнить эти запросы.
Звучит неплохо, правда? Во многих случаях нехватка ресурсов и ограничение скорости не являются проблемой. Но иногда они могли позволить злоумышленникам сделать что-то еще.
Когда это проблема?
Прежде всего, отсутствие ограничения скорости может повлиять на производительность серверов API и позволить злоумышленникам запускать DoS-атаки. Когда один или несколько клиентов делают слишком много запросов одновременно, запросы от этих клиентов могут подавить способность сервера обрабатывать запросы и, в свою очередь, замедлить работу службы или сделать ее недоступной для других пользователей.
Другая проблема заключается в том, что отсутствие ограничения скорости может привести к атакам методом перебора на конечные точки аутентификации и на конечные точки с авторизацией на уровне сломанных объектов. Например, если нет ограничения на то, сколько раз пользователь может отправлять запросы на вход, злоумышленники могут подбирать пароли пользователей, пытаясь войти в систему с разными паролями, пока не добьются успеха. С другой стороны, если приложение страдает от неработающей авторизации на уровне объекта, злоумышленники могут использовать конечную точку без ограничения скорости для перебора идентификаторов, указывающих на конфиденциальные данные.
Наконец, отсутствие ограничения скорости может помочь злоумышленникам быстрее извлекать конфиденциальные данные, если конечная точка API теряет информацию. Например, предположим, что эта конечная точка используется для получения электронной почты пользователя и не ограничена какой-либо формой контроля доступа. Эта конечная точка вернет содержимое 20 писем:
https://api.example.com/v1.1/emails/view?user_id=123&entries=20
Эта конечная точка вернет 5000, позволяя злоумышленникам читать все электронные письма пользователей за один вызов API:
https://api.example.com/v1.1/emails/view?user_id=123&entries=5000
И когда этот вызов API возвращает адрес электронной почты пользователя и не ограничивается ограничением скорости:
https://api.example.com/v1.1/profile/email/view?user_id=123
Злоумышленники могут запустить большое количество запросов API для сбора адресов электронной почты пользователей:
https://api.example.com/v1.1/profile/email/view?user_id=123 https://api.example.com/v1.1/profile/email/view?user_id=124 https://api.example.com/v1.1/profile/email/view?user_id=125 ... ... ... https://api.example.com/v1.1/profile/email/view?user_id=2345
Предотвращение проблем с ограничением ресурсов и скоростью
Так как же предотвратить возникновение этих проблем? Вам необходимо ограничить доступ пользователей к ресурсам! Но легче сказать, чем сделать.
Соответствующая скорость и лимит ресурсов для каждой функции часто должны быть разными. Например, ограничение скорости для конечных точек аутентификации должно быть намного ниже, чтобы предотвратить атаки с использованием подбора пароля и подбора пароля. Первое, что вы можете сделать, это определить, что является «нормальным использованием» для этой конкретной функции. Затем заблокируйте пользователей, которые запрашивают ресурсы с гораздо большей скоростью, чем обычно.
Определение риска проблем с ограничением скорости - это все, что касается того, где находится уязвимость в контексте приложения. В следующий раз давайте рассмотрим еще одну проблему API, которая также будет означать разные вещи в разных контекстах: OWASP API № 5, авторизация на уровне сломанной функции и то, как определить ее влияние на приложение. В следующий раз, почему вы должны сначала проверить конфиденциальные функции в своих API.
О каких еще концепциях безопасности вы хотите узнать? Я хотел бы знать. Не стесняйтесь подключаться к Twitter @ vickieli7.
Хотите узнать больше о безопасности приложений? Пройдите наши бесплатные десять лучших курсов OWASP здесь: https://www.shiftleft.io/learn/.
