Ответ 1

Только для # 1 - авторизация с тремя ногами с использованием потока кода авторизации.

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

Значение состояния обычно должно быть псевдослучайным недопустимым значением. Простое значение может быть сгенерировано как int с функцией rand() в PHP, хотя вы могли бы стать более сложными, чтобы обеспечить большую уверенность.

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

Дополнительная информация содержится в документе модели угрозы OAuth 2.0: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00

В частности, см. раздел о защите CSRF: http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-10.12

Ответ 2

Может быть полезно выполнить пример использования CSRF, чтобы понять, как параметр состояния смягчает такую ​​атаку. В этом примере Мэллори атакует и Алиса является жертвой.

Атака

• Мэллори посещает веб-сайт клиента и запускает процесс авторизации этого клиента для доступа к поставщику услуг с использованием OAuth

• Клиент запрашивает у поставщика услуг разрешение на запрос доступа к имени Мэллори, которому предоставляется

• Мэллори перенаправляется на сайт поставщика услуг, где она обычно вводит свое имя пользователя/пароль для авторизации доступа

• Вместо этого Мэллори ловушки/предотвращает этот запрос и сохраняет его URL

• Теперь Мэллори каким-то образом заставит Алису посетить этот URL. Если Алиса зарегистрирована у поставщика услуг со своей учетной записью, ее учетные данные будут использованы для выдачи кода авторизации

• Код авторизации обменивается на токен доступа

• Теперь учетная запись Мэллори на клиенте имеет право доступа к учетной записи Алисы у поставщика услуг

Итак, как мы можем предотвратить это, используя параметр state?

Профилактика

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

• Это значение передается поставщику услуг при перенаправлении с шага три выше

• Теперь, когда Мэллори получает Алису для посещения сохраненного URL (шаг пять выше), этот URL-адрес включает параметр state, сгенерированный с помощью информации сеанса Mallory

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

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

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

Ответ 3

Поскольку "состояние" является просто случайной строкой, сделать что-то вроде этого должно трюк:

$state = md5(uniqid(rand(), TRUE));

Не забудьте сохранить его в своем сеансе, чтобы потом проверить его.