برنامج تعليمي للهندسة العكسية API الخاصة لبرنامجك: قرصنة الأريكة

السفر هو شغفي ، وأنا من أشد المعجبين بـ Couchsurfing. Couchsurfing هو مجتمع عالمي للمسافرين ، حيث يمكنك العثور على مكان للإقامة أو مشاركة منزلك مع مسافرين آخرين. علاوة على ذلك ، يساعدك Couchsurfing على الاستمتاع بتجربة سفر حقيقية أثناء التفاعل مع السكان المحليين. لقد شاركت في مجتمع Couchsurfing لأكثر من 3 سنوات. حضرت اللقاءات في البداية ، ثم تمكنت أخيرًا من استضافة الأشخاص. يا لها من رحلة رائعة كانت! لقد قابلت الكثير من الأشخاص الرائعين من جميع أنحاء العالم وكوّنت الكثير من الأصدقاء. هذه التجربة برمتها غيرت حياتي حقًا.

لقد استضفت الكثير من المسافرين بنفسي ، أكثر بكثير مما قمت بتصفحه بالفعل حتى الآن. أثناء إقامتي في إحدى الوجهات السياحية الرئيسية في الريفيرا الفرنسية ، تلقيت عددًا هائلاً من طلبات الأريكة (تصل إلى 10 طلبات يوميًا خلال موسم الذروة). بصفتي مطورًا مستقلًا للجهة الخلفية ، لاحظت على الفور أن مشكلة موقع couchsurfing.com تكمن في أنه لا يتعامل مع مثل هذه الحالات "عالية التحميل" بشكل صحيح. لا توجد معلومات حول مدى توفر الأريكة الخاصة بك - عندما تتلقى طلبًا جديدًا للأريكة ، لا يمكنك التأكد مما إذا كنت تستضيف بالفعل شخصًا في ذلك الوقت. يجب أن يكون هناك تمثيل مرئي لطلباتك المقبولة والمعلقة ، حتى تتمكن من إدارتها بشكل أفضل. أيضًا ، إذا كان بإمكانك جعل أريكتك متاحة للعامة ، فيمكنك تجنب طلبات الأريكة غير الضرورية. لفهم ما يدور في ذهني بشكل أفضل ، ألق نظرة على تقويم Airbnb.

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

• http://www.nithincoca.com/2013/03/27/the-rise-and-fall-of-couchsurfing/
• http://mechanicalbrain.wordpress.com/2013/03/04/couchsurfing-a-sad-end-to-a-great-idea/

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

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

اقتحام الأريكة

لقد حان الوقت لاستخدام بعض تقنيات الهندسة العكسية للبرامج المفضلة لدي لاقتحام Couchsurfing.com. افترضت أن تطبيقات الأجهزة المحمولة الخاصة بهم يجب أن تستخدم نوعًا من واجهة برمجة التطبيقات للاستعلام عن الواجهة الخلفية. لذلك ، كان علي اعتراض طلبات HTTP القادمة من تطبيق جوال إلى الخلفية. لهذا الغرض ، قمت بإعداد وكيل في الشبكة المحلية ، وقمت بتوصيل جهاز iPhone الخاص بي به لاعتراض طلبات HTTP. بهذه الطريقة ، تمكنت من العثور على نقاط وصول لواجهة برمجة التطبيقات الخاصة بهم ومعرفة تنسيق حمولة JSON الخاصة بهم.

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

عمل موقع الويب على النحو التالي: تقوم بتسجيل الدخول إلى موقع الويب باستخدام بيانات اعتماد couchsurfing.com الخاصة بك ، وبعد بضع نقرات تحصل على رمز html الذي يمكنك تضمينه في ملف تعريف couchsurfing.com الخاص بك ، وفويلا - لديك تقويم محدث تلقائيًا في ملفك الشخصي. يوجد أدناه لقطة شاشة للتقويم وهنا المقالات حول كيفية صنعه:

• https://github.com/nderkach/couchsurfing-python

لقد أنشأت ميزة رائعة لـ Couchsurfing ، وافترضت بطبيعة الحال أنهم سيقدرون عملي - وربما يقدمون لي منصبًا في فريق التطوير لديهم. لقد أرسلت بريدًا إلكترونيًا إلى jobs (at) couchsurfing.com مع رابط إلى موقع الويب وسيرتي الذاتية ومرجع. ملاحظة شكر تركها أحد ضيوفي:

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

اقترحت منحهم تطبيقي مجانًا. يمكنهم استضافتها على بيئتهم وربطها من خلال مصادقة Facebook. بعد كل شيء ، إنها ميزة رائعة ، والمجتمع في حاجة إليها. هذا هو القرار النهائي الذي تلقيته:

"نحن نعود إلى تأرجح الأمور هنا بعد العطلة وأردنا المتابعة.

لقد أجرينا بعض المناقشات الداخلية حول تطبيقك وكيف يمكننا احترام الإبداع والمبادرة التي يظهرها مع عدم المساس بخصوصية وأمان بيانات مستخدمي Couchsurfing عند إدخال بيانات اعتمادهم في موقع جهة خارجية.

من الواضح أن التقويم يملأ فجوة ميزة على موقعنا ، وهي ميزة تعد جزءًا من مشروع أكبر نعمل عليه الآن.

لكن مسألة جمع أسماء المستخدمين وكلمات المرور لا تزال قائمة. لم نتمكن من التوصل إلى طريقة سهلة لإعداده حتى نتمكن من استضافة ذلك أو دعمه من جانبنا دون السماح لك بالوصول إلى تلك البيانات أو جعل موقعك يُنظر إليه على أنه منتج عمل خاص بنا.

سيتم قريبًا استبدال واجهة برمجة التطبيقات المتوفرة حاليًا بإصدار سيتطلب المصادقة / التفويض من التطبيقات التي تصل إليه ".

اليوم أثناء كتابة هذا البرنامج التعليمي لبرامج الهندسة العكسية (بعد مرور عام على الأحداث) ، لا تزال ميزة التقويم غير مطبقة على Couchsurfing.

العودة إلى البراءة - قرصنة أريكتي ، مرة أخرى

قبل بضعة أسابيع ، تم إلهامي لكتابة مقال حول تقنيات عكس هندسة واجهات برمجة التطبيقات الخاصة. بطبيعة الحال ، قررت تلخيص المقالات السابقة التي كتبتها حول هذا الموضوع ، وإضافة المزيد من التفاصيل. عندما بدأت في كتابة المقالة الجديدة ، أردت عرض عملية الهندسة العكسية باستخدام واجهة برمجة تطبيقات محدثة وأخذ خطوة أخرى في اختراق واجهة برمجة التطبيقات. بناءً على تجربتي السابقة ، وحقيقة أن Couchsurfing قد أعلنت مؤخرًا عن تطبيق wesbite جديد تمامًا للهاتف المحمول http://blog.couchsurfing.com/the-future-of-couchsurfing-is-on-the-way/ ، لقد قرروا اختراق API الخاص بهم مرة أخرى.

لماذا أقوم بعملية الهندسة العكسية؟ حسنًا ، أولاً وقبل كل شيء ، من الممتع جدًا إجراء هندسة عكسية للبرامج بشكل عام. ما أحبه بشكل خاص ، هو أنه لا يتضمن فقط مهاراتك الفنية ، ولكن أيضًا حدسك. في بعض الأحيان ، تكون أفضل طريقة لمعرفة الأشياء هي إجراء تخمين مستنير - سيوفر لك الكثير من الوقت مقارنة بالقوة الغاشمة. لقد سمعت مؤخرًا قصة من شركة كان عليها العمل مع واجهات برمجة التطبيقات (APIs) الخاصة ووثائق قليلة أو معدومة. لقد كانوا يكافحون لفك تشفير حمولة استجابة واجهة برمجة التطبيقات بتنسيق غير معروف لعدة أيام ، ثم قرر شخص ما تجربة ?decode=true في نهاية عنوان url وكان لديهم JSON مناسب. في بعض الأحيان ، إذا كنت محظوظًا ، فكل ما عليك فعله هو تجميل استجابة JSON.

سبب آخر لقيامي بهذا البرنامج التعليمي هو أن بعض الشركات تستغرق وقتًا طويلاً لتبني ميزة معينة يطلبها مستخدموها. بدلاً من انتظار تنفيذها ، يمكنك الاستفادة من قوة واجهة برمجة التطبيقات الخاصة بهم وبنائها بنفسك.

لذلك ، مع واجهة برمجة تطبيقات couchsurfing.com الجديدة ، بدأت بنهج مماثل وقمت بتثبيت أحدث تطبيق iOS.

أولاً ، تحتاج إلى إعداد وكيل في شبكة LAN الخاصة بك لتزوير طلبات HTTP القادمة من التطبيق إلى واجهة برمجة التطبيقات عن طريق تنفيذ هجوم man-in-the-middle (MITM).

بالنسبة للاتصالات غير المشفرة ، يكون الهجوم بسيطًا للغاية - يتصل العميل بالوكيل وتقوم بترحيل الطلبات الواردة إلى الخادم الوجهة ذهابًا وإيابًا. يمكنك تعديل الحمولة ، إذا لزم الأمر. في شبكة WLAN عامة ، من السهل إجراء ذلك تحت التخفي عن طريق انتحال صفة جهاز توجيه WiFi.

بالنسبة للاتصالات المشفرة ، هناك اختلاف بسيط: جميع الطلبات مشفرة من طرف إلى طرف. لا يمكن للمهاجم فك تشفير الرسالة ، إلا إذا تمكن بطريقة ما من الوصول إلى المفتاح الخاص (والذي بالطبع لا يتم إرساله أثناء هذه التفاعلات). بعد قولي هذا ، على الرغم من أن قناة اتصال API آمنة ، فإن نقاط النهاية - وخاصة العميل - ليست آمنة.

يجب استيفاء الشروط التالية حتى تعمل طبقة المقابس الآمنة بشكل صحيح:

• يجب توقيع شهادة الخادم مع مرجع مصدق (CA) موثوق به
• يجب أن يتطابق الاسم الشائع للخادم ، في الشهادة ، مع اسم مجال الخادم

للتغلب على التشفير في هجوم MITM ، يحتاج وكيلنا إلى العمل كمرجع مصدق (CA) وإنشاء شهادات على الفور. على سبيل المثال ، إذا حاول العميل الاتصال بـ www.google.com ، يقوم الوكيل ديناميكيًا بإنشاء شهادة لـ www.google.com ويوقعها. الآن ، يعتقد العميل أن الوكيل هو في الواقع www.google.com

لتنفيذ وكيل الاستنشاق المستخدم لعكس هندسة API الخاصة ، سأستخدم أداة تسمى mitmproxy. يمكنك استخدام أي وكيل HTTPS شفاف آخر. تشارلز مثال آخر مع واجهة مستخدم رسومية لطيفة. لإنجاز هذا العمل ، نحتاج إلى إعداد الأشياء التالية:

قم بتكوين البوابة الافتراضية لاتصال WiFi الخاص بهاتفك لتكون الوكيل (بحيث يكون الوكيل في المنتصف وتمر جميع الحزم) قم بتثبيت شهادة الوكيل على الهاتف (بحيث يكون لدى العميل المفتاح العام للوكيل في متجر الثقة الخاص به)

تحقق من وثائق الوكيل الخاص بك حول تثبيت الشهادة. فيما يلي التعليمات الخاصة بـ mitmproxy. وهنا ملف شهادة PEM لنظام iOS.

لمراقبة طلبات HTTP التي تم اعتراضها ، يمكنك ببساطة تشغيل mitmproxy والاتصال به من هاتفك المحمول (المنفذ الافتراضي هو 8080).

افتح موقعًا إلكترونيًا في متصفح هاتفك المحمول. في هذه المرحلة ، يجب أن تكون قادرًا على رؤية حركة المرور في mitmproxy.

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

لا توجد خوارزمية صارمة حول كيفية إجراء هندسة عكسية لواجهة برمجة تطبيقات للبرمجيات - في معظم الأوقات تعتمد على حدسك وتضع افتراضات.

أسلوبي هو تكرار استدعاءات API واللعب بخيارات مختلفة. بداية جيدة هي إعادة تشغيل الطلب الذي اكتشفته في mitmproxy ، ومعرفة ما إذا كان يعمل (اضغط على "r" لإعادة الطلب). الخطوة الأولى هي معرفة أي الرؤوس إلزامية. من المريح جدًا اللعب بالرؤوس باستخدام mitmproxy: اضغط على "e" للدخول إلى وضع التحرير ، ثم "h" لتعديل الرؤوس. مع الاختصارات التي يستخدمونها ، سيشعر مدمنو الهيمات بأنهم في المنزل. يمكنك أيضًا استخدام ملحقات المستعرض مثل Postman لاختبار واجهة برمجة التطبيقات ، لكنها تميل إلى إضافة رؤوس غير ضرورية ، لذلك أقترح التمسك بـ mitmproxy أو curl.

لقد قمت بعمل برنامج نصي يقرأ ملف تفريغ mitmproxy ويقوم بإنشاء سلسلة curl - https://gist.github.com/nderkach/bdb31b04fb1e69fa5346

لنبدأ بالطلب المرسل عند تسجيل الدخول.

 POST https://hapi.couchsurfing.com/api/v2/sessions ← 200 application/json 

أول شيء لاحظته هو أن كل طلب يحتوي على رأس إلزامي X-CS-Url-Signature والذي يختلف في كل مرة. حاولت أيضًا إعادة تشغيل الطلب بعد فترة من الوقت للتحقق مما إذا كان هناك فحص طابع زمني على الخادم ، ولا يوجد أي فحص. الشيء التالي الذي يجب فعله هو معرفة كيفية حساب هذا التوقيع.

في هذه المرحلة ، قررت إجراء هندسة عكسية للثنائي واكتشاف الخوارزمية. بطبيعة الحال ، بعد أن كانت لدي خبرة في التطوير لـ iPhone وامتلاك جهاز iPhone تحت تصرفي ، قررت أن أبدأ بـ iPhone ipa (يمكن تسليم تطبيق iPhone). تبين أنه لفك تشفير واحد ، أحتاج إلى هاتف مكسور الحماية. قف! وقت المطرقه.

بعد ذلك ، تذكرت أن لديهم تطبيق Android أيضًا. كنت مترددًا بعض الشيء في تجربة هذا النهج ، لأنني لا أعرف أي شيء عن Android أو Java. ثم اعتقدت أنها ستكون فرصة جيدة لتعلم شيء جديد. اتضح أنه من الأسهل الحصول على كود شبه مصدر يمكن قراءته من قبل الإنسان عن طريق فك تشفير java bytecode بدلاً من كود جهاز iphone المحسن بشكل كبير.

Apk (تطبيق Android القابل للتسليم) هو في الأساس ملف مضغوط. يمكنك استخدام أي مستخرج مضغوط لفك محتوياته. ستجد ملفًا يسمى class.dex ، وهو رمز Dalvik bytecode. Dalvik هو جهاز افتراضي يستخدم لتشغيل Java bytecode المترجم على Android.

لفك ترجمة ملف dex. إلى كود مصدر java. استخدمت الأداة المسماة dex2jar. ناتج هذه الأداة عبارة عن ملف jar ، والذي يمكنك فكه باستخدام مجموعة متنوعة من الأدوات. يمكنك حتى فتح جرة في Eclipse أو IntelliJ IDEA وستقوم بكل العمل نيابة عنك. تنتج معظم هذه الأدوات نتيجة مماثلة. لا نهتم حقًا إذا كان بإمكاننا تجميعها مرة أخرى لتشغيلها ، فنحن نستخدمها فقط لتحليل الكود المصدري.

فيما يلي قائمة بالأدوات التي جربتها:

• FernFlower (الآن جزء من IntelliJ IDEA)
• CFR
• JD-GUI
• كراكاتاو
• بروسيون

كان CFR و FernFlower الأفضل بالنسبة لي. لم تتمكن JD-GUI من فك بعض الأجزاء المهمة من الكود وكانت عديمة الفائدة ، بينما كانت الأجزاء الأخرى متشابهة في الجودة. لحسن الحظ ، يبدو أن كود Java لم يتم حجبه ، ولكن هناك أدوات مثل ProGuard http://developer.android.com/tools/help/proguard.html لمساعدتك على فك الشفرة.

إن فك تجميع Java ليس حقًا نطاق هذا البرنامج التعليمي للهندسة العكسية - فهناك الكثير مكتوبًا حول هذا الموضوع ، لذلك دعنا نفترض أنك نجحت في فك شفرة جافا الخاصة بك وتعديلها.

لقد جمعت جميع الأكواد ذات الصلة المستخدمة لحساب X-CS-Url-Signature في الجوهر التالي: https://gist.github.com/nderkach/d11540e9af322f1c1c74

أولاً ، لقد بحثت عن إشارات X-CS-Url-Signature ، والتي وجدتها في RetrofitHttpClient . بدت مكالمة معينة مثيرة للاهتمام - إلى وحدة EncUtils . عند البحث في الأمر ، أدركت أنهم يستخدمون HMAC SHA1. HMAC هو رمز مصادقة للرسالة يستخدم وظيفة تشفير (SHA1 في هذه الحالة) لحساب تجزئة رسالة. يتم استخدامه لضمان النزاهة (أي منع رجل في الوسط من تعديل الطلب) والمصادقة.

نحتاج إلى شيئين لحساب X-CS-Url-Signature : المفتاح الخاص والرسالة المشفرة (ربما بعض الاختلافات في حمولة طلب HTTP وعنوان URL).

 final String a2 = EncUtils.a(EncUtils.a(a, s)); final ArrayList<Header> list = new ArrayList<Header>(request.getHeaders()); list.add(new Header("X-CS-Url-Signature", a2));

في الكود ، توجد a و s هو المفتاح الذي يتم استخدامه لحساب الرأس a2 (الاستدعاء المزدوج لـ EncUtils يحسب فقط HMAC SHA1 hex Digging).

لم يكن العثور على المفتاح مشكلة - فقد تم تخزينه في نص عادي في ApiModule ، وتم استخدامه لتهيئة المعلمة الثانية لـ RetrofitHttpClient.

 RetrofitHttpClient a(OkHttpClient okHttpClient) { return new RetrofitHttpClient(okHttpClient, "v3#!R3v44y3ZsJykkb$E@CG#XreXeGCh"); }

إذا نظرنا إلى استدعاء EncUtils ، يمكننا أن نرى أن السلسلة الحرفية أعلاه تستخدم حرفيًا كمفتاح لحساب HMAC ، إلا في الحالة التي يتم فيها تعريف this.b في الحالة الأخيرة ، يتم إلحاق this.b بنقطة.

 String s; if (this.b == null) { s = this.a; } else { s = this.a + "." + this.b; }

الآن ، بمجرد النظر إلى الكود ، لم يكن واضحًا بالنسبة لي مكان this.a(String b) this.b هذا. لكنني لم أتمكن من العثور على مكالمة لها في أي مكان في الكود).

 public void a(final String b) { this.b = b; }

أنا أشجعك على فكها واكتشاف نفسك :)

كان اكتشاف الرسالة بسيطًا جدًا - في الكود يمكنك أن ترى أنه تسلسل لمسار عنوان url ، أي /api/v2/sessions وسلسلة بها حمولة JSON (إن وجدت).

 final byte[] b = this.b(request.getUrl()); byte[] a; if (request.getBody() != null && request.getBody() instanceof JsonTypedOutput) { System.out.println("body"); // this.a(x, y) concatenates byte arrays a = this.a(b, ((JsonTypedOutput)request.getBody()).a); } else { a = b; }

بمجرد النظر إلى الكود ، كان من الصعب معرفة الخوارزمية الدقيقة لحساب HMAC. لذلك ، قررت إعادة إنشاء التطبيق برموز تصحيح الأخطاء لمعرفة كيفية عمل التطبيق بالضبط. لقد استخدمت أداة تسمى apktool https://code.google.com/p/android-apktool/ لتفكيك رمز Dalvik bytecode باستخدام smali https://code.google.com/p/smali/. لقد اتبعت الدليل على https://code.google.com/p/android-apktool/wiki/SmaliDebugging

بعد إنشاء ملف apk ، تحتاج إلى تسجيله وتثبيته على جهازك. نظرًا لأنه لم يكن لدي جهاز Android ، فقد استخدمت المحاكي الذي يأتي مع Android SDK. مع بعض الإطعام بالملعقة ، إليك كيفية القيام بذلك:

 jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android <path_to_your_built_apk> androiddebugkey jarsigner -verify -verbose -certs <path_to_your_built_apk> zipalign -v 4 <path_to_your_built_apk> <path_to_your_output_signed_apk>

لقد استخدمت محاكي Android مدمجًا يأتي مع sdk وصورة افتراضية Atom x86 مع تمكين HAXM لضمان تشغيله بسلاسة.

 tools/emulator -avd mydroid -no-boot-anim -cpu-delay 0

فيما يلي دليل رائع حول كيفية إعداد صورة افتراضية: http://jolicode.com/blog/speed-up-your-android-emulator

تأكد من رؤية الخط HAX يعمل وأن المحاكي يعمل في وضع الفضيلة السريع عند بدء تشغيل المحاكي للتأكد من تمكين HAXM.

بعد ذلك ، قمت بتثبيت apk في المحاكي وقمت بتشغيل التطبيق. باتباع دليل apktool ، استفدت من مصحح الأخطاء عن بُعد IntelliJ IDEA للاتصال بالمحاكي وتعيين بعض نقاط فصل الأسطر:

من خلال اللعب مع التطبيق قليلاً ، تمكنت من معرفة أن المفتاح الخاص المستخدم لتهيئة RetrofitHttpClient يُستخدم لحساب HMAC لتوقيع طلب تسجيل الدخول. ردا على تسجيل الدخول POST ، تتلقى معرف المستخدم و accessToken ( X-Access-Token ). يتم استخدام رمز الوصول لتفويض جميع الطلبات التالية. يتم إنشاء HMAC لجميع طلبات تسجيل الدخول اللاحقة بنفس طريقة طلب تسجيل الدخول ، باستثناء أن المفتاح يتكون من إلحاق .<user_id> بالمفتاح الخاص الأصلي.

بمجرد الحصول على تصريح ، يرسل التطبيق الطلب التالي:

 POST https://hapi.couchsurfing.com/api/v2/users/1003669205/registerDevice ← 200 application/json

نظرًا لأنني تمكنت من الخصم بشكل تجريبي ، فإن هذا الطلب اختياري للمصادقة. نقاط المكافأة إذا اكتشفت الغرض من استخدامه!

بمجرد المصادقة ، يمكنك إرسال طلب لجلب ملف تعريف المستخدم الخاص بك (أو ملف تعريف المستخدم الخاص بأي شخص آخر) ، مثل هذا:

 GET https://hapi.couchsurfing.com/api/v2/users/1003669205 ← 200 application/json 

لم أخوض كثيرًا في التفاصيل ، لكنني لاحظت أنه يتم تحديث ملف تعريف بطلب PUT. للمتعة فقط ، حاولت تحديث ملف تعريف آخر بنفس الطلب - لم يكن مصرحًا به ، لذلك يبدو أنه تم تنفيذ أساسيات الأمان.

لقد كتبت نصًا بسيطًا من Python لتسجيل الدخول باستخدام بيانات اعتماد couchsurfing.com الخاصة بك والحصول على ملف تعريف المستخدم الخاص بك: https://gist.github.com/nderkach/899281d7e6dd0d497533. إليك غلاف Python لواجهة برمجة التطبيقات: https://github.com/nderkach/couchsurfing-python مع حزمة متوفرة في مستودع pypi (تثبيت Pip couchsurfing).

الخطوات التالية

لست متأكدًا مما سأفعله بالضبط بواجهة برمجة التطبيقات هذه المرة. لم يعد مسموحًا برمز HTML في ملفات تعريف المستخدمين ، لذلك سأضطر إلى التوصل إلى نهج مختلف للمشكلة القديمة. سأستمر في تطوير غلاف Python API وتحسينه ، إذا كان هناك طلب عليه ، وافترض أن couchsurfing.com لن يسبب الكثير من المشاكل. لم أستكشف واجهة برمجة التطبيقات كثيرًا ، واختبرتها للتو بحثًا عن بعض نقاط الضعف الأساسية. يبدو آمنًا بدرجة كافية ، ولكن سيكون من المثير للاهتمام معرفة ما إذا كان يمكنك الوصول إلى البيانات غير المتوفرة من خلال موقع الويب. في كلتا الحالتين ، يمكنك الآن استخدام هندسة البرمجيات العكسية لبناء عميل بديل لـ Windows Phone أو Pebble أو أريكتك الذكية.

اختتام مع سؤال

هناك مناقشة أود فتحها - لماذا لا تنشر واجهة برمجة التطبيقات الخاصة بك وتجعلها عامة؟ حتى إذا لم أتمكن من اختراق واجهة برمجة التطبيقات ، فسيظل من الممكن التخلص من موقع الويب. سيكون الأمر أبطأ وأكثر صعوبة في الصيانة ، لكنهم بالتأكيد يفضلون أن يستخدم المستهلكون واجهة برمجة التطبيقات بدلاً من مكشطة الويب. سيسمح توفر واجهات برمجة التطبيقات لمطوري الطرف الثالث بتحسين منتج الشركة وبناء خدمة ذات قيمة مضافة حولها. يمكن للمرء أن يدعي أن الحفاظ على واجهة برمجة التطبيقات العامة سيكون أكثر تكلفة من الحفاظ على واجهة برمجة التطبيقات الخاصة ؛ ولكن مرة أخرى ، فإن مزايا خدمات بناء المجتمع الخاص بك أعلى منتجك ستفوق تكاليف صيانة API.

هل من الممكن منع استخدام واجهة برمجة التطبيقات الخاصة تمامًا من قبل عملاء الجهات الخارجية؟ لا أعتقد ذلك. قد يؤدي استخدام تثبيت SSL إلى منع التطفل على طلبات واجهة برمجة التطبيقات باستخدام أسلوب وكيل بسيط وشفاف كما هو موضح سابقًا. في النهاية ، حتى إذا قمت بالتعتيم على الملف الثنائي ، فسيكون المخترق المتحمس الذي لديه بعض الموارد والوقت قادرًا دائمًا على عكس هندسة التطبيق الثنائي والحصول على المفتاح / الشهادة الخاصة. أعتقد أن افتراض أن نقطة نهاية العميل آمنة هو افتراض خاطئ بطبيعته. عميل API هو نقطة ضعف.

من خلال الحفاظ على خصوصية واجهة برمجة التطبيقات ، تنقل الشركة بشكل أساسي رسالة عدم ثقة إلى مستخدميها. بالتأكيد ، يمكنك محاولة حماية واجهة برمجة التطبيقات الخاصة بك بشكل أكبر. ومع ذلك ، ألا تفضل تطبيق أمان أساسي لواجهة برمجة التطبيقات لمنع الاستخدام الضار ؛ وبدلاً من ذلك ، ركز مواردك على تحسين البرنامج لتوفير تجربة مستخدم أفضل؟

Couchsurfing ، من فضلك ، مع السكر في الأعلى ، افتح API.