уязвимость в спеке oauth

последние несколько дней в списке рассылки OAuth шло обсуждение недавно открытой уязвимости. Что характерно, проблема заключается не в технической части, а в социальной. Вся криптография по-прежнему надёжна (сюрприз!), но есть способ получить доверенность на данные другого человека.

если коротко, то процесс OAuth состоит из трёх частей. Вначале вы говорите сервису-потребителю, что сейчас дадите ему доверенность использовать свои данные с другого сервиса. Потом вы отправляетесь на другой сервис и подписываете доверенность. И в конце отправляетесь назад с готовыми документами.

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

ниже следует более техническое описание.

регистрируемся на сервисе-потребителе данных. Говорим, что сейчас можно будет получить, например, свою адресную книжку от гугла. Сервис пытается отправить нас на гугл за подтверждением. Но мы на гугл не идём, мы берём этот урл и даём в блоге ссылку на него со словами типа «какие чудеса сервис ХХХ делает с адресной книжкой».

читатель блога заинтересовывается и переходит по ссылке. При необходимости логинится в гугл. Видит там запрос «сервис ХХХ хочет вашу адресную книжку». Всё кажется нормальным, и человек подписывает доверенность.

вот и всё: злонамеренному пользователю сервиса ХХХ выдана доверенность на пользование адресной книжкой другого человека.

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

более подробно и с картинками проблема под названием «OAuth Session Fixation Attack» описана в блоге со смешным названием

Артемий Трегубенко,

comments powered by Disqus