كيف يمكنني تصميم واجهة برمجة تطبيقات JavaScript التي تتيح البرمجة النصية عبر المجال بشكل آمن؟

Question

يعجبني الطريقة التي يتم بها استهلاك واجهة برمجة تطبيقات خرائط Google ، باستخدام برنامج نصي ، لكنني قلق:

واجهة برمجة التطبيقات الخاصة بي هي "شبه خاصة" ، أي يمكن الوصول إليها عبر الإنترنت ولكن يجب أن تسمح بنقل بيانات آمنة ونوع من المصادقة. يجب أن تظل البيانات خاصة على السلك ، ويجب ألا يتمكن أحد المستهلكين من الحصول على بيانات أخرى.

كيف يمكنني استخدام SSL ونوع من المصادقة لإبقاء البيانات آمنة ، ولكن لا يزال من الممكن الوصول إليه "أفقيًا" من صفحة HTML عادي بدون مطلوب من جانب الخادم؟ هل أحتاج إلى إدارة المفاتيح؟ كيف سيتم نشر المفاتيح على الخادم دون اعتراض؟ هل يمكنني استخدام OpenID (أو بعض المصادقة الأخرى الطرف الثالث) لمصادقة مستخدمي API ، أو هل يجب علي إنشاء آلية المصادقة الخاصة بي؟ لقد كنت في جميع أنحاء Google ولا يمكنني العثور على دليل جيد لتصميم ونشر واجهة برمجة التطبيقات الخاصة بي بشكل آمن.

أنا الآن أستخدم REST و AJAX لاستهلاكهما ، لكن المكالمات المتقاطعة مستحيلة. أي مساعدة أو مؤشر في الاتجاه الصحيح سيكون موضع تقدير كبير.

Answer 1

من المحتمل أن أستخدم علامة نصية تم إنشاؤها ديناميكيًا مع عنوان URL SSL الذي تضمن مفتاحًا في سلسلة الاستعلام التي تم تشفيرها. سيستخدم الخادم المفتاح الخاص لفك تشفير معلمة سلسلة الاستعلام وإرجاع البرنامج النصي الذي تضمن المعلومات ذات الصلة (أو لم يكن ، إذا كان المفتاح غير صالح). او هناك شيء ما على طول هذه الخطوط. لكنني سأعترف بأنني لم أضطر فعلاً إلى القيام بذلك في الممارسة العملية.

سأبحث أيضًا عن الفن السابق ، مثل خدمة Amazon S3.

لذا:

1. يوفر المستخدم السر
2. يستخدم الرمز من جانب العميل المفتاح العام لتشفير السر
3. JavaScript إلحقة أ script العلامة التي تتضمن عنوان URL
4. يعالج Server طلب البرنامج النصي ، ويكشف عن السر ، ويتحقق منه ، ويعيد الاستجابة ذات الصلة.

قد تحتاج إلى دورتين ، لأنه بخلاف ذلك ، يمكن إعادة استخدام الطلب إلى الخادم عبر هجوم رجل في الوسط. ممكن حدوثه:

1. JavaScript إلحقة أ script علامة تطلب مفتاحًا فريدًا (ربما مع بعض المعلومات المربكة ، مثل IP المصدر وبعض المفتاح الإضافي العشوائي)
2. يستجيب الخادم بمفتاح لمرة واحدة مرتبطًا بهذا IP
3. يوفر المستخدم السر
4. يستخدم الرمز من جانب العميل مفتاحًا عامًا لتشفير السر ، بما في ذلك المفتاح الفريد من #1
5. JavaScript إلحقة أ script العلامة التي تتضمن عنوان URL
6. يعالج Server طلب البرنامج النصي ، ويكشف عن السر ، ويتحقق منه ، ويعيد الاستجابة ذات الصلة.
7. يمكن تشفير الاستجابة (إلى حد ما) باستخدام المفتاح العشوائي المدرج في #1

لم أفعل أي منها بالفعل. (أو هل أنا؟ bwaa-ha-ha ...) fwiw.

Answer 2

قد تساعد OAUTH في هذا الموقف من خلال تسجيل الدخول إلى المستخدم إلى تطبيق الطرف الثالث والسماح لتطبيقك بالوصول إلى الطرف الثالث نيابة عنهم باستخدام رمز طلب عند تقديم طلبات XHR. http://oauth.net/documentation/getting-started/

========

يتلخص السبب في استخدام وكيل من جانب الخادم إلى سياسة الأصل من نفس الأصل المدمجة في متصفحات الويب: http://en.wikipedia.org/wiki/same_origin_policy

يسمح المتصفح بشكل أساسي فقط بتقديم الطلبات إلى العنوان الذي تأتي منه الصفحة (على سبيل المثال ، يمكن لـ Facebook.com تقديم طلبات فقط إلى Facebook.com URIs). يحل الوكيل من جانب الخادم هذه المشكلة عن طريق تقديم طلبات إلى الخوادم خارج الأصل الحالي. الوكلاء من جانب الخادم هم أيضًا أفضل الممارسات لتقديم طلبات مثل هذه.

Answer 3

تحقق من مشروع OpenSource 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

حل واحد محتمل:

1. قم بإعداد خادم Apache لتشغيل موقعك.
2. احصل على شهادة SSL لموقعك.
3. قم بتثبيت Apache Mod الذي يأتي مع Forge لإعداد سياسة عبر المجال التي تسمح للمواقع الأخرى بالوصول إلىك.
4. استضافة تطبيق TLS الخاص بـ Forge على موقعك مع شهادة موقعك بتنسيق PEM.
5. أخبر المواقع الأخرى لتضمين JavaScript من موقعك واستخدامها لإجراء مكالمات آمنة لموقعك للقيام بكل ما تريد.

Answer 4

1. (الطرف الثالث) تستخدم الصفحة OAuth أو شيء مشابه لمصادقة المستخدم والحصول على رمز من الخادم الخاص بك.
2. تقوم الصفحة بتحميل iFrame من الخادم الخاص بك عبر SSL مرر الرمز المميز للمصادقة.
3. يمكن لـ IFRAME التواصل بشكل آمن إلى الخادم الخاص بك عبر SSL
4. يستخدم easyxdm أو شيء مشابه للتواصل بين IFRAME وصفحة الطرف الثالث ، باستخدام بعض واجهة برمجة تطبيقات محدودة تشبه RPC أو شبيهة بالمقبس التي تقوم بإنشائها.

أو إذا كنت لا تثق حقًا في الطرف الثالث - فقم بمصادقةك داخل iframe (لا حاجة إلى OAUTH ، فما عليك سوى استخدام نموذج HTML عادي) وقم بتوصيل أي شيء يحتاجه الصفحة الخارجية لمعرفة المستخدم باستخدام EasyXDM.

Answer 5

لست متأكدًا جدًا من السؤال بالضبط ، فأنا أعتبر أنه تحاول إجراء مكالمة تشبه JSONP لـ [https://secure.com] من أجل معالجة/عرض البيانات على [http://regular.com ]؟

هل يمكن للخادمين التحدث مع بعضهما البعض؟ ماذا عن شيء مثل هذا:

1. يقوم المستخدم بتسجيل الدخول على [https://secure.com

2. عند المصادقة ، يقوم Secure.com بإنشاء رمز (يتيح أن نسميه بناء البناء) ويمرره مباشرة إلى Congarts.com (خادم إلى خادم) ، وربما مثل Session_id ، وبعض الرسائل التعسفية ، و Copher OTP (يتيح الاتصال به Syncpher) .

3. Broswer يتلقى Session_id ملف تعريف الارتباط ، ويقوم Secure.com ثم إعادة توجيه المتصفح إلى http://regular.com/setcookieansedirect؟session_id=blabla&otpencryptedsynmessage=blabla

4. Prooctor.com يبحث عن otp cipher باستخدام Session_id كمفتاح ، وينككضف otpencryptedmessage "blabla".

5. إذا تطابق الرسالة التي تم فك تشفيرها للرسالة الأصلية في البناء ، فيمكننا التحقق من تسجيل الدخول إلى [congary.com] وينشئ موقع Cormer. من Session_id ، وبعض رسالة ACK التعسفية ، وشفرات OTP مختلفة (دعنا نسميها ackcipher).

6. يقوم Contorm.com بعد ذلك بإرسال المتصفح إلى ملف تعريف ارتباط يتكون من otpencryptedackmessage (دعنا نسمي ملف تعريف الارتباط هذا "Verified_session").

7. الانتهاء من تحميل الصفحة.

من هناك ، يمكنك إجراء مكالمات تشبه JSONP

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

حيث سيأخذ Secure.com/getscript.js exertoken ، البحث عن Ackcipher استنادًا إلى ملف تعريف الارتباط الأصلي الذي تم إرساله بواسطة [Secure.com] كمفتاح ، وفك تشفير otpencrypedackmessage. إذا كانت الرسالة التي تم فك تشفيرها تتطابق مع رسالة ACK ، فرض ملف البرنامج النصي.

انها نوعا ما مثل المصافحة ثلاثية. الصلصة السرية هي أن الخوادم يجب أن تكون قادرة على التحدث مع بعضها البعض مباشرة لتمرير مفاتيح سرية بشكل تقديري. ليس عليك استخدام نفس Session_id لكلا الخادمين ، كنت أستخدم ذلك فقط كنقطة مرجعية سهلة لإيجاد طريقة للوصول إلى أصفاف Syn/ACK OTP. يجب أن تكون الأصفار مخفية تمامًا عن الأماكن العامة.