Как оценить необходимые привилегии?

Я рассчитываю балл CVSS для проблемы и сомневаюсь по поводу необходимого уровня привилегий (PR).

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

Каков в этом случае будет значение PR? Я считаю его низким, так как любой, кто может получить доступ к рабочей станции, сможет взять токен. Кто-то сказал мне, что он должен быть высоким, потому что пользователь должен быть авторизован. Так какой из вариантов правильный?

None (N)    Нападающий не авторизован до атаки и, следовательно, не требует доступа к настройкам или файлам уязвимой системы для выполнения атаки.
Low (L)     Нападающий требует привилегий, которые предоставляют базовые возможности пользователя, которые обычно могут затрагивать только настройки и файлы, принадлежащие пользователю. В качестве альтернативы, нападающий с низкими привилегиями имеет возможность доступа только к незащищенным ресурсам.
High (H)    Нападающий требует привилегий, которые предоставляют значительный (например, административный) контроль над уязвимым компонентом, позволяя доступ к компонентным настройкам и файлам.

Согласно спецификации CVSS, метрика необходимых привилегий определяется следующим образом:

• None: Нападающий не авторизован до атаки и, следовательно, не требует доступа к настройкам или файлам уязвимой системы для выполнения атаки.
• Low: Нападающий требует привилегий, которые предоставляют базовые возможности пользователя, которые обычно могут затрагивать только настройки и файлы, принадлежащие пользователю. В качестве альтернативы, нападающий с низкими привилегиями имеет возможность доступа только к незащищенным ресурсам.
• High: Нападающий требует привилегий, которые предоставляют значительный (например, административный) контроль над уязвимым компонентом, позволяя доступ к компонентным настройкам и файлам.

Что нужно уточнить, так это какая именно уязвимость у вас обнаружена и в каком ее объеме. Не очень ясно, относится ли рабочая станция к вашей уязвимости или нет.

Является ли уязвимость только проблемой экспозиции функции отладки, которая позволяет экспортировать JWT? Или она касается потенциального доступа к конфиденциальной информации, находящейся на рабочей станции?

Я предположу, что это первое, и что рабочая станция не является частью вашей уязвимости. Я предполагаю, что любое клиентское приложение, независимо от того, находится ли оно на конкретной рабочей станции, будет уязвимым.

Таким образом, ваше обоснование становится неуместным, потому что вы упоминаете рабочую станцию. Доступ к рабочей станции не имеет значения в этом случае.

Метрика PR интересуется только привилегиями, необходимыми нападающему.

В вашем случае нападающему нужно быть залогиненным как пользователь вашего приложения. Так что мы можем исключить уровень None.

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

И просто для полноты, следующее обоснование:

Кто-то сказал мне, что он должен быть высоким, потому что пользователь должен быть залогинен.

является неверным. Снова же, в спецификации различие между низким и высоким уровнями связано с разницей в привилегиях. Наличие авторизации просто повышает уровень с None до Low, но не до High.