В этой статье пойдет речь об известных уязвимостях OAuth. Читатели также узнают, как можно реализовать безопасную и защищенную авторизацию в веб-приложении.
OAuth – это надежный протокол, но его степень защищенности в значительной степени зависит от осведомленности веб-разработчиков при реализации авторизации. Это делает данную тему чрезвычайно важной для специалистов в сфере информационной безопасности. Им необходимо обеспечить высокий уровень защиты учетных записей своих пользователей. Настала пора познакомиться с эффективными практиками, которые помогут снизить опасность плохой реализации OAuth.
Введение
Протокол OAuth 2.0 в настоящее время широко используется в различных приложениях. С помощью него становится доступным удобный пользовательский интерфейс , более легкая аутентификация и авторизация по сравнению с традиционными методами ввода имени пользователя и пароля. При правильной и продуманной реализации протокол OAuth будет более безопасным, чем традиционная авторизация, поскольку пользователям не нужно делиться своими учетными данными со сторонним приложением для получения доступа к определенному ресурсу. Пользователи часто предпочитают входить в систему с помощью их аккаунтов Google, Facebook или LinkedIn вместо того, чтобы создавать новую учетную запись каждый раз, когда нужно зарегистрироваться на каком-то веб-сайте. Таким образом, протокол OAuth значительно упрощает нашу жизнь.
В целом, популярные поставщики услуг OAuth очень надежны. Вход в систему с помощью аккаунта Google или Facebook внушает пользователям определенное чувство безопасности, и это правильно. Протокол тщательно протестирован специалистами. Все имеющиеся уязвимости всегда быстро исправляются командой разработчиков. Однако, стоит отметить, что чувство полной безопасности может быть ложным.
Поставщики услуг OAuth оставили разработчикам приложений много причин поволноваться о безопасности своих программ. На самом деле, изначально защищенный сервис OAuth, неправильно реализованный в процессе его установки, может стать легкой мишенью для злоумышленников. Подобная безалаберность приведет к краже личных данных пользователей.
Далее следует рассмотреть наиболее распространенные уязвимости , встречающиеся в сторонних приложениях, реализующих протокол OAuth для авторизации своих пользователей. Нужно помнить, что сам протокол безопасен и надежен. Только после неверной реализации он становится уязвимым для атак хакеров.
Кража токена OAuth с помощью заголовка Referer
Когда приложение запрашивает авторизацию от имени пользователя у сервера OAuth, человек получает код, который следует ввести и отправить обратно на сервер для его последующей проверки. Если в процессе работы пользователь будет перенаправлен на другую страницу, то код будет виден в заголовке «Referer » HTTP-запроса. Таким образом, код попадет на внешний веб-сайт, что поставит под угрозу зарегистрированные на сервере OAuth данные пользователей.
Примечание : заголовок «Referer » — это заголовок HTTP-запроса, он передает хосту URL-адрес, с которого отправляется запрос.
Чтобы смягчить последствия данной уязвимости, разработчику необходимо убедиться, что его веб-приложение не содержит каких-либо html-инъекций. Если инъекции были обнаружены, то злоумышленник с легкостью может установить тег изображения на свой веб-сервер и найти способ перенаправить пользователя на него. Таким образом, он получит возможность украсть код из заголовка «Referer » HTTP-запроса.
Кража токена OAuth с помощью параметра redirect_uri
Приложение инициирует процесс авторизации, отправляя запрос на сервер 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
Иногда подобные URL блокируются. Злоумышленник может перенаправить полученные данные на открытый URL, как этот:
https://www.example.com/oauth20_authorize.srf?[...]&redirect_uri=https://accounts.google.com/BackToAuthSubTarget?next=https://evil.com
Или этот:
https://www.example.com/oauth2/authorize?[...]&redirect_uri=https%3A%2F%2Fapps.facebook.com%2Fattacker%2F
При реализации OAuth никогда нельзя включать в белый список целые домены. Следует добавлять только несколько URL-адресов, чтобы «redirect_uri » не перенаправлял запрос на Open Redirect.
Подделка межсайтовых запросов
Подделка межсайтового запроса может произойти, когда злоумышленнику удастся заставить жертву нажать на его ссылку и, таким образом, сгенерировать запрос, который он не собирался генерировать. Подделка межсайтовых запросов обычно смягчается с помощью токена CSRF, который связан с сеансом пользователя. Он помогает приложению проверить личность человека, отправившего запрос. Параметр «state » в протоколе OAuth служит токеном CSRF.
Стоит взглянуть, как осуществляется CSRF-атака на OAuth и как параметр «state » может быть использован для смягчения последствий уязвимости.
Хакер открывает веб-приложение и запускает процесс авторизации для получения доступа к поставщику услуг с помощью OAuth. Приложение запрашивает у поставщика услуг разрешение на доступ, который необходимо предоставить. Хакер будет перенаправлен на веб-сайт поставщика услуг, где обычно нужно ввести свое имя пользователя и пароль для авторизации доступа. Вместо этого хакер ловит и предотвращает этот запрос и сохраняет его URL-адрес. Хакер каким-то образом заставляет жертву открыть этот URL. Если жертва вошла в систему поставщика услуг, используя свой аккаунт, то ее учетные данные будут использованы для выдачи кода авторизации. Код авторизации обменивается на токен доступа. Теперь учетная запись хакера в приложении авторизована. Он может получить доступ и к учетной записи жертвы.
Итак, как можно предотвратить данную ситуацию с помощью параметра «state »?
Приложение должно создать значение, которое каким-то образом основано на исходной учетной записи (например, задействовать хэш-ключ сеанса пользователя ). Не столь важно, какое оно, главное, что значение уникально и генерируется с использованием частной информации о первоначальном пользователе. Оно и присваивается параметру «state ».
Это значение передается поставщику услуг при перенаправлении. Теперь хакер приглашает жертву открыть URL-адрес, который он сохранил.
Код авторизации выдается и отправляется обратно клиенту в сеансе вместе с параметром «state».
Клиент генерирует значение параметра на основе информации о сеансе и сравнивает его со значением «state », которое было отправлено обратно из запроса авторизации поставщику услуг. Это значение не соответствует параметру «state » в запросе, поскольку оно было сгенерировано только на основе информации о текущем сеансе. В результате, полученное значение не принимается системой.
Другие уязвимости, обнаруженные при реализации OAuth, включают в себя возможность выполнения XSS (межсайтового скриптинга) с использованием параметра «redirect_uri», раскрытие OAuth Private Key (ключ иногда может быть получен при декомпиляции мобильного приложения) и Authorization Code Rule Violation (когда код авторизации может быть использован более одного раза для выдачи нескольких токенов доступа). Эти уязвимости встречаются реже, чем описанные выше, но это не делает их менее опасными. Разработчик должен знать все необходимые практики, чтобы обеспечить надежную работу своего веб-приложения.
Автор переведенной статьи: Simon Saliba.
Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.
ЧИТАТЬ ВСЕ СТАТЬИ НА САЙТЕ | ПОДПИСЫВАЙТЕСЬ НА НАШ TELEGRAM КАНАЛ
