02/20/2011:
Сегодня Facebook подтвердил, что действительно есть один вызов, в котором access_token транслируется в открытом доступе. . . это просто один вызов, который я использую, чтобы убедиться, что ПОЛЬЗОВАТЕЛЬ все еще вошел в систему перед сохранением в моей базе данных приложения. Их рекомендация состояла в том, чтобы использовать опцию SSL, предоставленную в прошлом месяце для холста и Facebook в целом. По большей части Auth и Auth безопасны.
Результаты:
После моего сообщения было сделано замечание, что на самом деле это не вопрос, но я думал, что действительно его постулировал. Чтобы не было двусмысленности вот вопрос с вводом:
Поскольку нет никаких данных, отправленных из Facebook во время процесса загрузки холста, которые не были бы разглашены в какой-то момент, включая access_token, сеанс и другие данные, которые могли бы однозначно идентифицировать пользователя, видит ли кто-нибудь другой способ, кроме добавления еще одного слоя, т. е. пароль, отправленный по сети через HTTPS вместе с access_toekn, который обеспечит уникальную неприкосновенность безопасности пользователем?
Используя Wireshark, я захватил локальную трансляцию при загрузке страницы приложения Canvas. Я был очень удивлен, увидев трансляцию access_token в открытом доступе, доступном для просмотра любому. Этот access_token добавляется к любому https-вызову Facebook OpenGraph API.
Использование Facebook в качестве входа в систему одним щелчком мыши вызвало у меня огромные опасения. Он хранится в объекте сеанса в памяти, и файл cookie очищается после завершения работы приложения, и после просмотра вызовов FB.Init я увидел много вызовов HTTPS, поэтому я предположил, что access_token всегда был зашифрован.
Но прошлой ночью я увидел в строке состояния вызов, который был просто HTTP-вызовом, который включал идентификатор приложения, поэтому я почувствовал, что должен обнюхать последовательность загрузки Application Canvas.
Сегодня я пронюхал трансляцию, и на прикрепленном изображении вы можете видеть, что есть http-вызовы с access_token, которые транслируются открыто и ясно, чтобы любой мог получить к ним доступ.
Я что-то упускаю, это то, что я вижу, и моя интерпретация действительно верна. Если кто-то может обнюхать и получить access_token, он теоретически может совершать вызовы API Graph через https, даже если обратный вызов все равно должен быть сайтом, установленным в приложении Facebook.
Но что действительно представляет угрозу безопасности, так это любой, кто использует access_token для доступа к своему собственному сайту. Я не вижу ценности единого входа через Facebook, если единственной вещью, которая была установлена как безопасная, был access_token, потому что, как я вижу, это явно небезопасно. Токены доступа, срок действия которых никогда не истекает, не изменяются. Access_tokens разные для каждого пользователя, доступ к другому сайту может быть закрыт только для одного пользователя, но компрометация данных даже одного пользователя недопустима.
http://www.creatingstory.com/images/InTheOpen.png
Вернулся и сделал больше исследований по этому поводу:
РЕЗУЛЬТАТЫ:
Вернулся и повторно запустил приложение холста, чтобы убедиться, что это не мой код, который не транслировался.
В этом вызове: HTTP GET /connect.php/en_US/js/CacheData HTTP/1.1
USER ID четко виден в файле cookie. Таким образом, USER_ID полностью видны, но они уже есть. Любой может перейти практически на любую страницу, навести курсор на изображение и увидеть идентификатор пользователя. Так что большой угрозы нет. APP_ID также легко получить, но . . .
http://www.creatingstory.com/images/InTheOpen2.png
В приведенном выше файле четко показан ТОКЕН ПОЛНОГО ДОСТУПА в ОТКРЫТОМ состоянии через вызов, инициированный Facebook.
Я ошибся. СКАЖИ МНЕ, ЧТО Я НЕПРАВ, потому что я хочу ошибаться в этом.
С тех пор я сбросил свой секрет приложения, поэтому я показываю реальный нюх загружаемой страницы холста.
Дополнительные данные 20.02.2011:
@ifaour - я ценю время, которое вы потратили на составление своего ответа.
Я хорошо знаком с процессом OAuth и хорошо разбираюсь в распаковке подписанного запроса и использовании access_token. Я выполняю значительную часть своей обработки на сервере, и все мои потоки на стороне сервера Facebook завершены и функционируют без каких-либо недостатков, о которых я знаю. Секрет приложения является безопасным и никогда не передается внешнему приложению, а также регулярно изменяется. Я настолько фанатичен в отношении безопасности, насколько это возможно, зная, что есть так много того, чего я не знаю, что может вернуться и укусить меня.
Две огромные проблемы с access_token:
Проблемы касаются возможного использования access_token от USER AGENT (браузер). Во время процесса FB.INIT() Facebook JavaScript SDK создается файл cookie, а также объект в памяти, называемый объектом сеанса. Этот объект вместе с файлом cookie содержит access_token, сеанс, секрет, uid и статус соединения. Объект сеанса структурирован таким образом, что поддерживает как новый OAuth, так и устаревшие потоки. С OAuth access_token и статус почти все, что используется в объекте сеанса.
Первая проблема заключается в том, что access_token используется для HTTPS-вызовов API GRAPH. Если бы у вас был access_token, вы могли бы сделать это из любого браузера:
https://graph.facebook.com/220439?access_token=...
и он вернет массу информации о пользователе. Таким образом, любой, у кого есть токен доступа, может получить доступ к учетной записи Facebook. Вы также можете сделать дополнительные вызовы любой информации, которую пользователь предоставил приложению, связанному с access_token. Сначала я подумал, что вызов в GRAPH должен иметь обратный вызов на URL-адрес, установленный в настройках приложения, но я протестировал его, как указано ниже, и он вернет информацию обратно прямо в браузер. Я думаю, что добавление этой функции обратного вызова было бы хорошей идеей, это немного усложняет ситуацию.
Вторая проблема заключается в использовании некоторых уникальных частных защищенных данных, которые идентифицируют пользователя в базе данных третьей стороны, т. е., как и в моем случае, я бы использовал единый вход для заполнения информации о пользователе в моей базе данных с использованием этого уникального защищенного элемента данных ( т. е. access_token, который содержит APP ID, USER ID и хэш с секретной последовательностью). Все это не является проблемой на стороне сервера. Вы получаете подписанный_запрос, распаковываете его с секретом, делаете вызовы HTTPS, получаете ответы HTTPS. Когда у пользователя есть информация, введенная через USER AGENT (браузер), которая должна быть сохранена через POST, этот уникальный защищенный элемент данных будет отправлен через HTTPS, чтобы они проверялись перед вставкой в базу данных.
Однако, если НЕТ защищенной части уникальных данных, которая предоставляется через процесс единого входа, то невозможно гарантировать несанкционированный доступ. Access_token — это часть данных, которая используется Facebook для выполнения вызовов HTTPS в GRAPH API. он считается уникальным в отношении КАК ПОЛЬЗОВАТЕЛЯ, так и ПРИЛОЖЕНИЯ и изначально защищен с помощью пакета signed_request. Однако, если впоследствии он будет передан в открытом виде и если я смогу пронюхать провод и получить access_token, то я могу притвориться приложением и получить информацию, которую они разрешили приложению просматривать. Я попробовал приведенный выше пример из браузера Safari и IE, и он вернул мне всю мою информацию в браузере.
В заключение, access_token является частью signed_request, и именно так приложение первоначально получает его. После аутентификации и авторизации OAuth, т. е. ПОЛЬЗОВАТЕЛЬ вошел в Facebook, а затем запустил ваше приложение, access_token сохраняется, как указано выше, и я пронюхал его так, что вижу, что он хранится в файле cookie, который передается по сети, что приводит к НЕТ УНИКАЛЬНОЙ ЗАЩИЩЕННОЙ ИДЕНТИФИКАЦИОННОЙ части информации, которую можно использовать для поддержки взаимодействия с базой данных, или, другими словами, если бы не было еще одной части защищенных данных, отправленной вместе с access_token в мою базу данных, т. е. пароль, я бы не сможет определить, является ли это законным вызовом. К счастью, я использовал безопасный AJAX через POST, и вызов должен исходить из того же домена, но я уверен, что есть способ перехватить это.
Я полностью открыт для любых идей по этой теме о том, как однозначно идентифицировать моих ПОЛЬЗОВАТЕЛЕЙ, кроме добавления еще одного уровня (пароля) с помощью этого процесса единого входа, или если кто-то просто поделится со мной тем, что я неправильно прочитал и проанализировал свои данные и что access_token всегда защищен по сети.
Махало нуи лоа заранее.
