Подтвердить что ты не робот

Как я могу создать javascript API, который позволяет безопасно использовать междоменные скрипты?

Мне нравится, как используется api Google Maps, используя script include, но я беспокоюсь:

Мой api является "полу-частным", то есть доступен через Интернет, но должен обеспечивать безопасную передачу данных и некоторую аутентификацию. Данные должны оставаться конфиденциальными по кабелю, и один потребитель не сможет получить другие данные.

Как я могу использовать SSL и какую-то аутентификацию для обеспечения безопасности данных, но все же доступную "горизонтально" с простой HTML-страницы без необходимости на стороне сервера? Нужно ли мне управлять ключами? Как ключи будут отправляться на сервер без перехвата? Могу ли я использовать OpenId (или некоторую стороннюю аутентификацию) для аутентификации пользователей api, или мне нужно создать собственный механизм аутентификации? Я был повсюду в Google и не могу найти хорошее руководство для проектирования и развертывания моего API.

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

4b9b3361

ОТВЕТЫ

Ответ 1

Я бы, вероятно, использовал динамически сгенерированный тег script с URL-адресом SSL, который включал ключ в строку запроса, которая была зашифрована с открытым ключом. Сервер будет использовать закрытый ключ для дешифрования параметра строки запроса и возврата script, который включает соответствующую информацию (или не был, если ключ был недействителен). Или что-то вдоль этих линий. Но я признаю, что на самом деле мне не приходилось делать это на практике.

Я также хотел бы узнать об уровне техники, например, о сервисе Amazon S3.

Итак:

  • Пользователь предоставляет секретные
  • Клиентский код использует открытый ключ для шифрования секретного
  • JavaScript добавляет тег script, который включает URL
  • Сервер обрабатывает запрос script, расшифровывает секрет, проверяет его и отправляет обратно соответствующий ответ.

Вам может потребоваться два цикла, поскольку в противном случае запрос на сервер можно было бы повторно использовать с помощью атаки "человек в середине". Это будет:

  • JavaScript добавляет тег script, который запрашивает уникальный ключ (возможно, с некоторой смешающей информацией, такой как исходный IP-адрес и некоторый случайный дополнительный ключ).
  • Сервер отвечает одноразовым ключом, привязанным к этому IP-адресу
  • Пользователь предоставляет секретные
  • Клиентский код использует открытый ключ для шифрования секретности, включая уникальный ключ из # 1
  • JavaScript добавляет тег script, который включает URL
  • Сервер обрабатывает запрос script, расшифровывает секрет, проверяет его и отправляет обратно соответствующий ответ.
  • Ответ может быть зашифрован (в некоторой степени) с использованием случайного ключа, включенного в # 1

Ничего из того, что я на самом деле сделал. (Или у меня? BWAa-ha-ha-ha...) FWIW.

Ответ 2

OAuth может помочь в этой ситуации, указав вход пользователя в стороннее приложение и позволяя вашему приложению получать доступ к сторонней стороне от их имени, используя маркер запроса при выполнении запросов xhr. http://oauth.net/documentation/getting-started/

========

Причина использования прокси-сервера на стороне сервера сводится к политике одного и того же происхождения, встроенной в веб-браузеры: http://en.wikipedia.org/wiki/Same_origin_policy

По сути, браузер разрешает только запросы к адресу, на котором происходит эта страница (например, facebook.com может отправлять запросы только на URI facebook.com). Прокси-сервер на стороне сервера решает эту проблему, обращаясь к серверам за пределами текущего источника. Прокси серверов также являются наилучшей практикой для таких запросов.

Ответ 3

Посмотрите проект javascript Forge с открытым исходным кодом. Он предоставляет javascript TLS-реализацию, которая позволяет безопасные междоменные запросы xhr. Он может вам пригодиться:

http://digitalbazaar.com/2010/07/20/javascript-tls-1/

http://digitalbazaar.com/2010/07/20/javascript-tls-2/

https://github.com/digitalbazaar/forge

Одно потенциальное решение:

  • Настройте сервер Apache для запуска вашего сайта.
  • Получить сертификат SSL для вашего сайта.
  • Установите модуль apache, который поставляется вместе с Forge, чтобы настроить междоменную политику, которая позволяет другим сайтам получать доступ к вашим.
  • Реализация TKS для хоста Forge на вашем сайте вместе с сертификатом вашего сайта в формате PEM.
  • Сообщать другим сайтам о включении javascript с вашего сайта и использовать его для обеспечения безопасных звонков на ваш сайт, чтобы делать то, что вы хотите.

Ответ 4

  • (сторонняя сторона) Страница использует OAUTH или что-то похожее на аутентификацию пользователя и получение маркера с вашего сервера.
  • Страница загружает IFRAME с вашего сервера через SSL, передавая токен для аутентификации.
  • IFRAME может безопасно связываться с вашим сервером через SSL
  • Используйте easyXDM или что-то подобное для связи между IFRAME и сторонней страницей, используя некоторые ограниченные RPC-подобные или подобные сокетам API, который вы создаете.

Или, если вы действительно не доверяете третьей стороне, выполните свою аутентификацию внутри iframe (тогда не нужно использовать oauth, просто используйте обычную форму html) и сообщите все, что должна знать внешняя страница о пользователе, использующем easyXDM.

Ответ 5

Не уверен, что вопрос в точности, я полагаю, вы пытаетесь выполнить jsonp-подобный вызов на [https://secure.com], чтобы обрабатывать/отображать данные на [http://regular.com]?

Могут ли два сервера разговаривать друг с другом? Как насчет чего-то подобного:

  • Пользователь входит в систему на [https://secure.com]

  • После аутентификации secure.com генерирует токен (позволяет его использовать synoken) и передает его прямо на regular.com(сервер-сервер), возможно, как session_id, какое-то произвольное сообщение и otp-шифр (позволяет называть его синхронизатором).

  • Broswer получает cookie session_id, а Secure.com затем перенаправляет браузер на http://regular.com/setcookieandredirect?session_id=blabla&otpencryptedsynmessage=blabla

  • Regular.com просматривает otp-шифр, используя session_id как ключ, и расшифровывает otpencryptedmessage "blabla".

  • Если дешифрованное сообщение соответствует исходному сообщению в синтаксике, мы можем проверить, что пользователь вошел в систему [regular.com], а regular.com генерирует другой токен (позволяет называть его acktoken, lolz) и передает его прямо на [ secure.com], состоящий из session_id, некоторого произвольного сообщения ack и другого otp-шифра (позволяет называть его ackcipher).

  • Regular.com затем отправляет браузеру cookie, состоящий из otpencryptedackmessage (пусть назвал этот cookie "verified_session" ).

  • Завершите загрузку страницы.

Оттуда вы можете сделать jsonp-подобные вызовы

https://secure.com/getscript.js?query=dataname&verifiedtoken=(verified_sessions_cookie_value)

где secure.com/getscript.js проведет проверку, загляните в ackcipher на основе исходного файла cookie session_id, отправленного [secure.com] в качестве ключа, и расшифруйте сообщение otpencrypedackmessage. Если дешифрованное сообщение соответствует сообщению ack, отрисуйте файл script.

Это похоже на трехстороннее рукопожатие. Секретный соус заключается в том, что серверы должны иметь возможность разговаривать друг с другом напрямую, чтобы передавать секретные ключи дискретно. Вам не нужно использовать один и тот же session_id для обоих серверов, я просто использовал это как легкую точку отсчета, чтобы найти способ доступа к шифрам syn/ack otp. Шифры должны быть полностью скрыты от общественности.