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

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

В настоящее время протокол OAuth 2.0 широко используется в сторонних приложениях. Он предлагает беспроблемный пользовательский интерфейс и более простую аутентификацию и авторизацию по сравнению с традиционными методами имени пользователя и пароля. При правильной и продуманной реализации она может быть более безопасной, чем традиционная авторизация, поскольку пользователям не нужно передавать свои учетные данные стороннему приложению для доступа к определенному ресурсу. Мы все предпочитаем входить в систему с помощью Google, Facebook или LinkedIn вместо того, чтобы создавать учетную запись с новыми учетными данными каждый раз, когда нам нужно зарегистрироваться на новом веб-сайте. Протокол OAuth значительно упростил нашу жизнь.

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

С безопасностью дело обстоит немного сложнее. Поставщики услуг OAuth оставили разработчикам над чем подумать. Фактически, безопасная служба OAuth, неправильно реализованная неосведомленным разработчиком, может привести к огромным кражам данных. Например, защита файлов Google Диска пользователя начинается на уровне стороннего приложения.

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

Кража токена OAuth через Referer

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

Примечание. Заголовок Referer - это заголовок в HTTP-запросах, который передает хосту URL-адрес, с которого был отправлен запрос.

Чтобы уменьшить эту уязвимость, разработчик должен убедиться, что его веб-приложение не содержит каких-либо HTML-инъекций. Если это так, злоумышленник может настроить тег изображения на своем веб-сервере и найти способ перенаправить на него пользователя. Затем он может украсть код из Referer заголовка запроса.

Кража токена OAuth через redirect_uri

Как мы видели в Введение в протокол OAuth, приложение инициирует процесс авторизации запросом к серверу OAuth:

https://www.example.com/signin/authorize?[...]&redirect_uri=https://demo.example.com/loginsuccessful

Запрос всегда содержит параметр redirect_uri, используемый сервером OAuth для обратной отправки токена приложению после того, как пользователь дал свое согласие. Если значения этого параметра не контролируются или не проверяются, злоумышленник может легко изменить этот параметр и перенаправить запрос на свой веб-сайт, где он реализует обработчик для получения токена и доступа к ограниченному ресурсу.

https://www.example.com/signin/authorize?[...]&redirect_uri=https://localhost.evil.com

Иногда эти URI блокируются. Злоумышленник может перенаправить на принятый открытый URL-адрес следующим образом:

https://www.example.com/oauth20_authorize.srf?[...]&redirect_uri=https://accounts.google.com/BackToAuthSubTarget?next=https://evil.com

or

https://www.example.com/oauth2/authorize?[...]&redirect_uri=https%3A%2F%2Fapps.facebook.com%2Fattacker%2F

Реализации OAuth никогда не должны заносить в белый список целые домены, только несколько URL-адресов, чтобы «redirect_uri» не мог указывать на открытое перенаправление.

Подделка межсайтовых запросов

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

Давайте начнем с предположения, что я злоумышленник, а вы - жертва.

Я захожу в какое-то веб-приложение и запускаю процесс авторизации этого приложения для доступа к поставщику услуг с помощью OAuth. Приложение запрашивает у поставщика услуг разрешение запросить доступ от моего имени, и оно предоставляется. Меня перенаправляют на веб-сайт поставщика услуг, где я обычно ввожу свое имя пользователя / пароль для авторизации доступа. Вместо этого я перехватываю / предотвращаю этот запрос и сохраняю его URL. Я как-то заставляю вас вместо этого посетить этот URL. Если вы вошли в систему поставщика услуг со своей учетной записью, то ваши учетные данные будут использоваться для выдачи кода авторизации. Код авторизации заменяется на токен доступа. Теперь моей учетной записи в приложении разрешен доступ к вашей учетной записи поставщика услуг.

Итак, как мы можем предотвратить это с помощью параметра state?

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

Это значение передается поставщику услуг при перенаправлении. Теперь я предлагаю вам посетить сохраненный мной URL.

Код авторизации выдается и отправляется обратно клиенту в вашем сеансе вместе с параметром state

Клиент генерирует значение state на основе вашей информации о сеансе и сравнивает его со значением state, которое было отправлено обратно из запроса авторизации поставщику услуг. Это значение не соответствует параметру state в запросе, поскольку это значение state было сгенерировано на основе информации о моем сеансе, поэтому оно отклонено.

Другие уязвимости, обнаруженные в реализациях OAuth, включают возможность выполнять XSS (межсайтовый скриптинг) с использованием параметра redirect_uri, раскрытие закрытого ключа OAuth (ключ иногда может быть обнаружен, когда декомпиляция мобильного приложения) и нарушение правила кода авторизации (когда код авторизации может использоваться более одного раза, для выдачи нескольких токенов доступа). Эти уязвимости обычно встречаются реже, чем рассмотренные выше, но это не делает их менее критичными. Разработчик должен знать все передовые практики, чтобы обеспечить надежность своего веб-приложения.

Если вас интересует веб-безопасность, вы можете прочитать следующие статьи:

Ресурсы: