OAuth небезопасен или я не понял?

Я думал о безопасности для моего веб-сервиса REST API, и решил взглянуть на другие крупные службы и как они это делают. В качестве примера я решил изучить Twitter OAuth. После прочтения руководства для новичков меня немного смущает и шокирует.

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

В качестве примера возьмем LinkedIn. Они запрашивают ваше имя пользователя и пароль gmail в своей собственной форме, и вы не представляете, как они будут его использовать. Они могут просто украсть его и сохранить в своей БД, они могут использовать OAuth для gmail (и они не показывают страницу Gmail с информацией о том, какой тип доступа они запрашивают), они могут делать все, что захотят, с помощью этой информации.

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

Кстати, в протоколе OAuth произошел поток безопасности http://oauth.net/advisories/2009-1/), и я уверен, что их больше, но никто не заботится о том, чтобы найти их.

Ответ 1

Я собираюсь пойти с "Ты этого не понял". (В вашей защите очень мало людей).

Пусть будет ясно: атака фиксации сеанса, на которую вы ссылаетесь, затронула OAuth 1.0, но была разрешена в OAuth 1.0a, которая стала RFC 5849. Нет основных разработчиков OAuth 1.0 - основные разработчики либо внедрили OAuth 1.0a/RFC 5849, либо реализовали один из черновиков OAuth 2.0.

Что касается анти-шаблона имени пользователя/пароля, OAuth 1.0a не предусматривает механизм обмена имени пользователя и пароля для токена доступа. OAuth 2.0 делает, но только для поддержки установленных приложений. Имейте в виду, что установленное приложение может просто keylog (или подобное), если оно действительно этого захочет. Когда дело доходит до обеспечения безопасности, все ставки отключены, если приложение уже выполняется изначально и не используется на клиентской машине. Но на самом деле это совсем другой сценарий, чем то, о чем вы говорите. Веб-приложения как OAuth 1.0a, так и OAuth 2.0 никогда не касаются имени пользователя и пароля.

Поток для OAuth 1.0a выглядит следующим образом: приложение запрашивает у провайдера токен запроса, сообщая ему все, к чему он хочет получить доступ. Поставщик выдает временный неавторизованный токен, и в этот момент клиент может отправить пользователю провайдеру для авторизации этого токена. Пользователь входит в систему со своим именем пользователя и паролем на сайте поставщика, а затем либо предоставляет, либо запрещает доступ. Затем провайдер перенаправляет обратно строку с верификатором, которая позволяет сайту обновляться до авторизованного токена доступа. Все эти взаимодействия подписаны. Если подписи не совпадают ни с одним из них, поставщик отклонит запрос. И пользователь может в любой момент отменить любой токен, удалив клиентскую способность для доступа к своей учетной записи.

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

Точка, вы намного безопаснее, используя OAuth 1.0a или OAuth 2.0, чтобы разрешить третьему лицу, чем с любыми альтернативами. Если вам это не нравится, решение прост: не разрешайте третьим лицам получать доступ к вашей учетной записи. Разумеется, есть много причин, по которым вы, возможно, не захотите этого делать.

Ответ 2

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

Например, что делает LinkedIn, все неправильно. Таким образом, я никогда не давал бы им свою учетную запись gmail. Для того, чтобы предоставить информацию о моей учетной записи gmail, я настаиваю на том, что мой браузер использует SSL с Google, поэтому корневой фрейм страницы принадлежит Google.

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