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

Question

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

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

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

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

Answer 1

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

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

Итак:

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

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

1. JavaScript добавляет script тега, который запрашивает уникальный ключ (возможно, с некоторой ошибочными выводами информации, как источник IP и некоторыми случайным дальнейшим ключ)
2. Сервера отвечает с одноразовым ключом, привязанным к что IP
3. Пользователь предоставляет секрет
4. сторона клиента код использует открытый ключ для шифрования тайны, в том числе уникального ключа от # 1
5. JavaScript добавляет script тега, который включает в себя URL
6. Сервер обрабатывает запрос сценария, расшифровывает секрет, проверяет его и отправляет ответный ответ.
7. Ответ вполне может быть зашифрован (до некоторой степени) с использованием случайного ключа не включен в # 1

Ни один из которых я действительно сделал. (Или у меня? BWAa-ha-ha-ha ...) FWIW.

Answer 2

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

========

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

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

Answer 3

Проверьте проект кузнеца javascript с открытым исходным кодом. Он предоставляет 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

Одним из возможных решений:

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

Answer 4

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

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

Answer 5

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

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

1. Пользователь зайдет на [https://secure.com]

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

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

4. Regular.com смотрит OTP шифра с помощью session_id в качестве ключа, и расшифровывает otpencryptedmessage "блабла."

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

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

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

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

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

где secure.com/getscript.js примет verifiedtoken, выполните поиск ackcipher на основе оригинального печенья session_id отправленный [secure.com] в качестве ключа и дешифрование сообщения otpencrypedack. Если дешифрованное сообщение соответствует сообщению ack, визуализируйте файл сценария.

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