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