Использование Window.postMessage для отправки токенов аутентификации во встроенные приложения - PullRequest
0 голосов
/ 30 января 2019

Рассмотрим следующий сценарий.

На сайте foo.com есть магазин приложений.Разработчики могут зарегистрировать свои приложения там.Приложение состоит из идентификатора, логотипа, URL-адреса и набора разрешений.

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

Когда они щелкают приложение, соответствующий URL-адрес приложения загружается в iframe.Все идет нормально.Теперь приложению нужен способ действовать от имени пользователя на foo.com.Для этого родительское окно использует window.postMessage для отправки токена аутентификации в iframe, содержащую приложение.

HTML-код в URL-адресе приложения должен включать небольшой фрагмент JS, который прослушивает токен аутентификации изродительское окно.Как только он получает токен, он может сохранить его в файле cookie / хранилище сеанса / где-либо еще и продолжить рендеринг приложения и совершать звонки от имени пользователя.

(примечание: я не указал токен аутентификации.Это может быть токен доступа oAuth, JWT или любой другой.)

Теперь вопрос: как это ужасная и невероятно небезопасная идея?

Альтернативный "стандарт""подход должен заключаться в том, чтобы URL приложения инициировал трехстороннюю схему проверки подлинности oAuth, которая перенаправляла бы пользователя обратно на foo.com (внутри iframe, так что теперь foo.com внутри foo.com), чтобы принять приложение (которое по общему признанию выможет сделать автоматически, так как пользователь уже принял приложение), тогда foo.com перенаправит обратно на URL приложения с кодом авторизации, который он может обменять на токен доступа.

Я думаю,Предложенный поток PostMessage намного проще и чище.Какие недостатки я не вижу?

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

1 Ответ

0 голосов
/ 04 февраля 2019

Если токены авторизации доступны для javascript, то они уязвимы для атак XSS.Вот почему файлы cookie авторизации имеют флаг httpOnly, который запрещает JS взаимодействовать с ними.

Атака XSS на стороннее приложение может выявить токен аутентификации приложения для этого конкретного стороннего приложения.

Атака XSS на foo.com может выявить все токены аутентификации приложения.

Стандартный 3-сторонний поток oAuth заканчивается тем, что сторонний сервер выдает что-то браузеру, который аутентифицирует браузер как соответствующие учетные данные oAuth.Если это файл cookie httpOnly, то он более защищен, поскольку не подвержен атакам XSS.

Кроме того, даже если риск XSS приемлем, у вас все еще есть проблемы с CORS, так как браузер будет на стороне домена, выдающегозапросы к foo.com

...