Уязвимости механизма авторизации

В очередной раз пересматривая наши наработки по обнаружению уязвимостей в механизме авторизации веб-приложений, понял, что не знаю о вменяемом тексте на русском языке, который дает декомпозицию явления и рассматривает его со всех сторон. В результате, появился данный текст. Очень прошу оставить feedback на тему того, понятно ли написано, есть ли спорные моменты и был ли полезен данный текст. Буду переписывать до тех пор, пока не станет доходчиво, как в букваре. Заранее спасибо.

Задача механизма авторизации — предоставить ответ на вопрос, разрешено ли пользователю совершить запрашиваемое им действие. В основе механизма авторизации лежат формальные модели разграничения доступа, самыми известными среди которых являются модель Белла-ЛаПадулы, дискреционная модель и модель RBAC (разграничение доступа на основе ролей).

В веб-приложениях стандартом де-факто является реализация разграничения доступа на основе ролей. В модели RBAC решение о доступе субъекта к объекту принимается на основе привилегий, которыми наделена его роль. Рассмотрим модельную схему работы механизма авторизации, основанного на модели RBAC:
Шаг 1. Установление субъекта U, целевого объекта O и запрашиваемого действия A.
Шаг 2. Определение роли R субъекта U.
Шаг 3. Проверка наличия у роли R привилегии, разрешающей доступ A от пользователя U к объекту O.
Замечание. Список привилегий пользователя может быть задан либо как белый, либо как черный список. При описании привилегий с помощью белого списка явно указывается список объектов и действий над ними, разрешенных субъекту. Если запрашиваемое действие не входит в белый список, оно запрещается. При реализации привилегий с помощью черного списка явно указывается список объектов и действий над ними, запрещенных субъекту. Если запрашиваемое действие не входит в черный список, оно разрешается. Возможен и комбинированный вариант – в таком случае используются правила и для запрещения и для разрешения доступа.

В зависимости от места и первопричины предлагается выделять следующие виды уязвимостей авторизации:

1. Роль пользователя находится под его контролем. Так бывает, когда определение роли пользователя происходит на основе входных данных, которые полностью контролируются пользователям. Примером такой уязвимости является возможность выставления флага isAdmin = true, передаваемого в cookies. В соответствие с общеизвестной классификацией уязвимостей по этапам жизненного цикла ПО, данный вид уязвимостей относится к уязвимостям проектирования. Действительно, ответственность за появление уязвимостей подобного рода лежит на системном архитекторе.
2. Неполный список привилегий пользователя. Данная ошибка обычно встречается при описании привилегий в виде черного списка. В этом случае отсутствие правила для запрещения доступа к объекту автоматически приводит к разрешению доступа. Примером такой уязвимости является конфигурационный файл веб-сервера, в котором указан неполный список директорий, для которых необходимо провести авторизацию. Данный вид уязвимостей относится к уязвимостям внедрения и эксплуатации. Действительно, ответственность за появление уязвимостей подобного рода лежит не на разработчиках, а на администраторах приложений.
3. Отсутствие обращения к механизму авторизации на пути выполнения, ведущем к защищенной функциональности. Данный вид уязвимостей относится к уязвимостям реализации. Действительно, ответственность за появление уязвимостей подобного рода лежит полностью на программисте, который не добавил обращение к механизму авторизации.

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

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

1. Как уже было показано, в случае контроля пользователем своей роли арность отношения – «многие к одному». Нескольких уязвимостей данного вида в одном и том же приложении быть не может по определению.
2. В случае неполного списка привилегий, арность отношения так же – «многие к одному». Действительно, обнаружение возможности совершить любое из запрещенных действий свидетельствует о неполной конфигурации. Аналогично с предыдущим, в приложении такая уязвимость либо есть, либо отсутствует.
3. В случае отсутствия обращения к механизму авторизации, арность отношения – «многие ко многим». Действительно, проявление такой уязвимости может случиться только при выполнение пути с отсутствующей проверкой. На других путях данная уязвимость проявляться не будет по определению. Более того, отсутствующие проверки на других путях будут выливаться в свои, особенные, проявления уязвимости, так как для выполнения этих путей потребуется передать другие входные данные. Уязвимостей такого вида в приложении может быть сколько угодно.

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

1. Уязвимости механизма авторизации первого и второго вида (контроль роли пользователем и неполный список привилегий) можно обнаружить, найдя хотя бы одно их проявление. Вопрос полноты в данном случае не стоит (уязвимость может быть только одна), однако актуален вопрос точности.
2. При обнаружении уязвимостей механизма авторизации третьего вида (отсутствие обращения к механизму авторизации на пути выполнения) возникает вопрос полноты анализа. Действительно, так как проверка авторизации должна быть на всех путях выполнения, ведущих к защищенной функциональности, возникает нетривиальная задача вызвать выполнение всех этих путей. Данная задача, как известно¹, в общем случае неразрешима.

Сноска 1. Если бы была решена задача нахождения входных данных, в результате запуска с которыми будет выполнен заданный путь, то автоматически была бы решена задача определения выполнимости путей. Доказано, что эта задача неразрешима.