Должен ли я проверить HTTP Referer в OAuth 2 Callback?

Question

Я успешно могу аутентифицировать учетные записи Facebook и Google, используя мои сервлеты Oauth2.Я использую состояние с таймером и cookie-файлом сеанса, чтобы убедиться, что это действительно допустимый обратный вызов Oauth.

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

2. Если нет пользы, может ли быть проблема, если я также проверю поле HTTP Referer?

Answer 1

Нет.

1. Я могу имитировать любые заголовки, которые я хочу, как злоумышленник.Я могу сделать так, чтобы я выглядел как http://cia.fbi.gov.vpn/uber1337h4x.Это очевидно и хорошо известно.

2. На всех страницах с номерами HTTPS не отправляется заголовок ссылки в соответствии с RFC2616 sec15 :

   Клиенты НЕ ДОЛЖНЫ включать поле заголовка Referer в (незащищенный) HTTP-запрос, если ссылающаяся страница была передана с использованием защищенного протокола.

3. Нарушение удобства использования согласно RFC2616 sec15 :

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

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

Не делайте этого.

Answer 2

Ответ:

No, you shouldn't use it, and there is NO valuable benefit of doing it.

Серверы авторизации очень хорошо это знают. И здесь было заявлено.

Из списка рассылки OAuth-WG :

Обратные URL-страницы ДОЛЖНЫ перенаправлять на доверенную страницу сразу после получения кода авторизации в URL. Это предотвращает сохранение кода авторизации в истории браузера или непреднамеренную утечку в заголовке реферера.

• Если вы беспокоитесь о CSRF, вы НЕ ДОЛЖНЫ использовать HTTP Referer в качестве метода проверки источника авторизации, поэтому параметр state (какой звук вы используете ).

• Если вас беспокоит конкретная проблема безопасности протокола oauth2, внутри черновика есть полный раздел .

• Если вы беспокоитесь о других соображениях безопасности, это источник .

Я предлагаю вам приложить все усилия для реализации всех проверок вокруг параметра: state .

Edit:

Прочитав нюансы вопроса, вы действительно ответите на свой вопрос. Использование файлов cookie (возможно, локального хранилища HTML5) в обоих случаях - лучшее из известных нам решений.

• Первый нюанс касается CSRF, и одна из возможных доступных контрмер - Проверка заголовка HTTP Referer , и это уже было адресовано в протоколе .

• Второй нюанс, я не совсем уверен, но, вероятно, это случай с расширением Grant, это потому, что кажется, что вы можете работать как «запросчик авторизации прокси-сервера», так же как SAML oauth2 расширение .

Answer 3

Не проверять реферер HTTP; параметр "state" (который, как вам кажется, вы используете) - это подход , который OAuth 2.0 определяет для защиты от атак подделки межсайтовых запросов (CSRF).

Возможно, вы захотите взглянуть на новую книгу О'Рейли Начало работы с OAuth 2.0 Райана Бойда. Он описывает это и связанные с этим вопросы безопасности.

Answer 4

Простая безопасность не была проблемой, поскольку используется параметр state.

Основные проблемы, которые я имел в виду, были:

1. Является ли это тем же браузером, который мое приложение отправило на Facebook, и которое возвращается для представления токена-кандидата?
2. Независимо от того, выполняет ли агент (агент, подобный браузеру) или агенты неоднократно OAuth-запросы и представляет мне неверные токены OAuth, из-за которых мое приложение постоянно связывается с Facebook с плохими токенами, что может привести к потенциально неблагоприятному отношению со стороны Facebook.

Единственное возможное решение первой проблемы - это также установить cookie в дополнение к использованию state. referer помогло бы, если бы большинство провайдеров не использовали https.

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

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

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

Это не четкий ответ (или вопрос), но, надеюсь, это показывает нюансы вопроса.