Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей я обращусь к уязвимостям из списка топ-10 OWASP, посвященного безопасности API. В каждой статье я покажу вам, как экспериментировать с API, тестируя уязвимость, и обсужу свои выводы.

В качестве подопытных я буду использовать разные API. Все они демонстрационные – в реальной жизни и публичных приложениях они не используются. Следовательно, все обсуждаемые уязвимости абсолютно безвредны, если вообще не внедрены специально.

Вот весь список топ-10:

1. Некорректная авторизация на уровне объекта.
2. Некорректная аутентификация.
3. Авторизация на уровне свойств неработающего объекта.
4. Неограниченное потребление ресурсов.
5. Ошибка авторизации на уровне функций (эта статья).
6. Подделка запросов на стороне сервера.
7. Неправильная конфигурация безопасности.
8. Отсутствие защиты от автоматизированных угроз.
9. Неправильное управление запасами.
10. Небезопасное использование API.

Что такое «Ошибка авторизации на уровне функций»?

API страдает от ошибки авторизации на уровне функций (BFLA), если пользователь может выполнять операции над ресурсами, которые, по идее, выполнять не может. Если некорректная авторизация на уровне объекта говорит о доступе к данным, BFLA – это про изменение или удаление данных.

Для примера возьмем такую ситуацию: вы пользователь онлайн-банка и можете получить информацию о любом из ваших счетов через некий защищенный раздел банковского сайта. Возможно, что когда вы запрашиваете данные о счете, сайт вызывает API для получения информации от бэкэнда – что-то вроде этого: GET /accounts/123. 123 в данном случае – уникальный идентификатор вашего счета. . Этот API-запрос, скорее всего, будет содержать токен, куки или нечто иное, уникально идентифицирующее и верифицирующее вас.

Пример нарушения BFLA – это когда тот же пользователь с теми же аутентификационными данными может обновить информацию о счете. К примеру, это можно сделать через PUT или PATCH-запросы к /accounts/123, изменив состояние счета (халявные деньги!)

Тестирование на BFLA-уязвимость

Возьмем API для демо-приложения ParaBank.

Допустим, мы верно авторизовались, и счет с ID 12345 соответствует нашему пользователю с ID 12212. Мы можем получить информацию о счете 12345, используя HTTP GET к /accounts/12345. Запрос возвращает информацию о счете:

{
        "id": 12345,
        "customerId": 12212,
        "type": "CHECKING",
        "balance": -2300.00

 }

Все как ожидалось – за вычетом разве что грустного баланса на счету. Кстати, о балансе – давайте посмотрим, нельзя ли что-нибудь с ним сделать. Конечно, мы можем поработать над этим, получив повышение или перейдя на другую работу – но, возможно, финансовые проблемы можно решить как-то проще?

Что, если мы просто обновим баланс правильным PUT или PATCH-вызовом? API-документация не содержит никакой информации о подобных операциях, но это не должно нас обескуражить. Напротив, ее отсутствие в документации – это основная причина, чтобы попробовать это и поглядеть, что получится.

Для начала отправим HTTP PATCH к /accounts/12345 с телом запроса:

{
    "balance": 1500.00
}

К сожалению, возвращается запрос со статусом HTTP 405 (метод не разрешен). Увы. Теперь попробуем отправить HTTP PUT с таким телом запроса:

{
    "id": 12345,
    "customerId": 12212,
    "type": "CHECKING",
    "balance": 1500.00
}

Увы, результат тот же: операция не разрешена. HTTP POST тоже не сработал.

И, наконец, мы можем попробовать удалить счет, используя HTTP DELETE к /accounts/12345. Избавились от счета – избавились от задолженности. К сожалению (для нас), эта попытка тоже возвращает HTTP 405. Кажется, придется все-таки поговорить с боссом о повышении…

Создание тестов для проверки BFLA-узявимости

Как можно видеть на примерах выше, тестирование потенциальных BFLA-узявимостей – дело довольно несложное. Можно даже воспользоваться инструментами и проверять каждый билд. Вот так это может выглядеть для нашего примера в RestAssured.Net:

[TestCaseSource("ActionsOnAccounts")]

public void CheckAccountsForBFLAViolations(HttpMethod httpMethod, HttpStatusCode httpStatusCode)
{
    Given()
    .When()
         .Invoke($"http://localhost:8080/parabank/services/bank/accounts/12345", httpMethod)
    .Then()
        .StatusCode(httpStatusCode);
}
private static IEnumerable<TestCaseData> ActionsOnAccounts()
{
    yield return new TestCaseData(HttpMethod.Get, HttpStatusCode.OK).
        SetName("HTTP GET is allowed");
    yield return new TestCaseData(HttpMethod.Post, HttpStatusCode.MethodNotAllowed).
        SetName("HTTP POST is not allowed");
    yield return new TestCaseData(HttpMethod.Put, HttpStatusCode.MethodNotAllowed).
        SetName("HTTP PUT is not allowed");
    yield return new TestCaseData(HttpMethod.Patch, HttpStatusCode.MethodNotAllowed).
        SetName("HTTP PATCH is not allowed");
    yield return new TestCaseData(HttpMethod.Delete, HttpStatusCode.MethodNotAllowed).
        SetName("HTTP DELETE is not allowed");
    yield return new TestCaseData(HttpMethod.Head, HttpStatusCode.OK).
        SetName("HTTP HEAD is allowed");
    yield return new TestCaseData(HttpMethod.Options, HttpStatusCode.OK).
        SetName("HTTP OPTIONS is allowed");
}

Этот тест перебирает список HTTP-методов, вызывает их для отправки запроса к /accounts/12345 и проверяет код статуса соответствующих ответов. Это, конечно, крайне поверхностный тест (как тестировщик, вы не должны слепо доверять кодам статуса), но это хороший старт для создания своих собственных, более глубоких тестов, прогоняющихся для каждого билда.

Как снизить риск BFLA-уязвимости?

BFLA не просто так попал в топ-10 уязвимостей: потенциальный урон тут значителен. Злоумышленники могут легко эксплуатировать такую уязвимость, изменять или удалять важные данные, если API подвержен BFLA.

Контрмеры, которые можно предпринять для снижения риска BFLA-узявимости:

• Тестируйте! Чтобы начать тестировать на BFLA, не нужно особых знаний – достаточно креативного подхода.
• Проектируя или разрабатывая API, по умолчанию запрещайте любой доступ к ресурсу, и выдавайте права на конкретные методы только явно, присваивая их ролям, у которых должен быть доступ.

Примеры

Другие примеры BFLA-уязвимостей можно найти на странице OWASP: Broken Object Level Authorization.

Также множество примеров есть в разделах API Security Fundamentals и OWASP API Security Top 10 and Beyond API Sec University.

Обсудить в форуме