قررنا اليوم مناقشة موضوع أمن المعلومات. ننشر ترجمة مقال كونال باندي ، ونكتشف الثغرات ونعمل قبل المنحنى!
المقدمة
أصبحت سرقة البيانات الشخصية (PII) للمستخدم أمرًا شائعًا بالنسبة لنا. يجد المهاجمون العديد من الطرق للحصول على البيانات الشخصية ، على سبيل المثال ، باستخدام ثغرات XSS و IDOR ، والكشف عن نقطة نهاية واجهة برمجة التطبيقات ، والمزيد.
يمكن اختبار السيناريو الموضح في هذه المقالة من خلال مراقبة سلوك نقطة نهاية API ببساطة. في المثال أدناه ، من خلال استدعاء API ، يمكن تخزين المعلومات الشخصية لأي مستخدم في نقاط نهاية API الأخرى.
تفسير
في أحد البرامج الخاصة على منصة HackerOne Bug Bounty ، حيث تمت دعوتي ، تم اقتراح اختبار بوابة المتجر ، أي قسم عمل البائع. هنا ، يمكن لموظفي المتجر إرسال دعوة "تقديم الطلب" إلى أي عميل. للحصول على المعلومات التي يحتاجونها ، يرسل البائع هذا الطلب إلى العملاء عبر البريد الإلكتروني أو باستخدام رمز الاستجابة السريعة.
بعد تلقي رابط بدعوة لإجراء دفعة ، ينتقل المشتري إلى: payment-na.examle.com/0811ebf4-d7d0-ba31-9ce68648a5a9 ويملأ البيانات المطلوبة.
عندما يتم اعتراض طلب ، يكتشف Burp Suite نقطة نهاية POST API التي تحتوي على البيانات المدخلة.
طلب
POST /na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 HTTP/1.1
Host: payments-na.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json;charset=utf-8
X-Cdc-Client: 2.15.45
Content-Length: 125
Origin: https://payments-na.example.com
DNT: 1
Connection: close
Referer: https://payments-na.example.com
{"browser_prefilled":[],"customer_details":{"country":"US"..............},"skipped_fields":[],"user_submitted":true,"action":"continueAddressUnverified"}
إجابة
بعد ملء النموذج ، يتم الانتهاء من العملية. منجز!
أثناء طريقة POST إلى payments-na.example.com/na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 ، يتم حفظ جميع المعلومات ، وتم إجراء الدفع.
مرحلة التشغيل
قد يجد المستخدمون أو المهاجمون قسمًا آخر في البوابة حيث يمكنهم استخدام وظيفة Place Order ، تمامًا كما هو الحال في الطريقة الموضحة أعلاه ، وتلقي رابط الدفع التالي: payment-na.examle.com/fa5daba4-5d50-8f80 –9eb1-ebia3ea6d665 .
في هذه الحالة ، ما عليك سوى ملء النموذج ، واعتراض الطلب في Burp Suite ، واستلام طلب POST إلى payment-na.example.com/na/customer/client/v1/session/xxxx ، وتحميل نقطة نهاية واجهة برمجة التطبيقات التي تم إنشاؤها وتجاهل الطلبات الأخرى إلى نحن لم نرسلهم.
تم استلام نقطة نهاية API: payment-na.example.com/na/customer/client/v1/session/96afd42f-4281-4529-9b8c-3ba70b0f000b .
لمزيد من الاختبارات ، يمكن أيضًا استخدام نقطة النهاية هذه باستخدام طريقة GET في المتصفح. يوجد أدناه لقطة شاشة لنقطة نهاية واجهة برمجة التطبيقات الناتجة:
كما نرى ، لم تتم إضافة أي معلومات بعد ولم يتم تحديد أي معلمات.
سنقوم الآن باسترداد رابط واجهة برمجة التطبيقات هذا وإرساله إلى المستخدمين الآخرين الذين ملأوا تفاصيل طلباتهم. بمجرد نقر الضحية على رابط واجهة برمجة التطبيقات هذا ، سيتم نسخ جميع البيانات الشخصية من الإرسال السابق الذي تم تخزينه هنا ( / na / customer / client / v1 / session / 002420e4-e031-47aa-8d94-6f7c40c248c7 ) إلى نقطة النهاية المحددة API: / na / customer / client / v1 / session / 96afd42f-4281-4529-9b8c-3ba70b0f000b .
بعد أن تنقر الضحية على رابط API الذي أرسلناه إليك ، سيتم نسخ جميع بيانات المستخدم الشخصية إلى نقطة النهاية هذه.
من جانب الضحية:
يكفي المهاجم أن يزور ببساطة نقطة نهاية واجهة برمجة التطبيقات هذه في وضع التصفح المتخفي ، وستكون هناك بيانات الضحية المنسوخة (البريد الإلكتروني ، العنوان ، إلخ).
البيانات الشخصية للضحية:
بهذه الطريقة ، يمكن للمهاجمين الحصول على البيانات الشخصية لأي عميل ببساطة عن طريق إنشاء نقطة نهاية API لجلسة جديدة وإرسالها إلى مستخدمين آخرين.
العمل على الخلل
قام فريق تطوير البوابة الإلكترونية بإزالة طريقة GET ، وربطها بطريقة POST ، وإضافة رأس رمز التفويض إلى طلب طريقة POST أعلاه ، حيث ستتم المصادقة في كل مرة من الخادم.
أدى هذا إلى القضاء على إمكانية تكرار السيناريو الموصوف أعلاه - هجوم بنسخ البيانات الشخصية للمستخدم عبر واجهة برمجة التطبيقات.
النقاط الرئيسية
1. يمكن أن تكون سيناريوهات مثل هذه الهجمات مختلفة ، ومثال واحد منها فقط. انتبه إلى نقاط الضعف هذه وحاول البحث بشكل أعمق لإنشاء سيناريو مشابه: كيف يمكن لمهاجم آخر أن يهاجمك.
2. في المثال الموضح ، تمت مصادقة واجهة برمجة التطبيقات (API) الخاصة بالمهاجم إلى نقطة نهاية واجهة برمجة التطبيقات الخاصة بالضحية نظرًا لعدم وجود تحقق من صحة رأس رمز التفويض المميز. سمح ذلك للخادم بنسخ البيانات الشخصية للعملاء إلى نقطة نهاية API أخرى.
مسار الأحداث:
22 يوليو: أبلغت فريق البوابة عن الثغرة الأمنية.
23 يوليو: تمت مراجعة التقرير من قبل الفريق وتم ضبط الخطورة على متوسطة.
23 يوليو: حصل على مكافأة قدرها 500 دولار.
27 يوليو: تم حل المشكلة ، وتم تجميع التقرير.