مفيش secrets جوه الـ app: درس باسورد Applebee's
باحث أمني لقى باسورد داتابيز عملاء Applebee's جوه تطبيق الـ Android. إيه اللي حصل، وإزاي تتجنب نفس الغلطة حسب OWASP Mobile M1.
باحث أمني فك تطبيق Applebee's على Android، ولقى جوّاه باسورد بيفتح داتابيز العملاء بتاعة الشركة. مش hack معقد ولا zero-day، ده credential مكتوب جوه الكود ونازل مع كل نسخة من التطبيق. القصة نشرتها TechCrunch يوم 30 أكتوبر، وهي درس مباشر لأي حد بيعمل mobile app أو frontend.
اللي حصل
حسب TechCrunch:
- الباحث Robert Wiggins (من What Security) اكتشف المشكلة الشهر ده، واستخدم AI يساعده يدوّر على الـ credential وسط آلاف السطور من كود تطبيق Android، اللي عليه أكتر من مليون تحميل على Google Play
- الـ credential كان بيدّي access لداتابيز العملاء، وحسب كلامه كان ممكن كمان يسمح لمهاجم إنه يعدّل في الداتا
- الداتا فيها أسماء وإيميلات وتواريخ ميلاد وأرقام تليفونات و ZIP codes، وعناوين IP لآخر login، اللي ممكن تكشف مكان الشخص التقريبي
- TechCrunch فكّت التطبيق بنفسها (decompile) وأكدت إن الـ credential موجود، والشركة قفلت الثغرة قبل نشر الخبر
- متحدث باسم Dine Brands (الشركة الأم) قال إنهم لحد دلوقتي ملقوش دليل على دخول غير مصرّح، بس رفض يقول هل عندهم server logs أصلًا يقدروا يعرفوا منها مين دخل
- الباحث مقدرش يبلّغ الشركة مباشرة لأن مكانش عندها طريقة للإبلاغ عن مشاكل أمنية، فطلب مساعدة TechCrunch
ليه ده خطير؟
ده بالظبط أول بند في OWASP Mobile Top 10 نسخة 2023: M1: Improper Credential Usage. أي حاجة بتنزل على جهاز المستخدم، سواء APK أو IPA أو JS bundle في المتصفح، اعتبرها public. أي حد يقدر ينزّلها ويفكها ويقرا الـ strings اللي جواها. ولو الـ credential ده بيفتح داتابيز، يبقى أي حد معاه التطبيق بقى admin.
القواعد اللي تمشي عليها
1. افترض إن الـ app بيتفك ويتقري
قبل أي release دوّر بنفسك على الـ secrets في الـ build النهائي، مش في الـ source بس:
grep -rniE "password|secret|api_key" ./dist
وأحسن من كده تحط secret scanner في الـ CI عشان يمسك أي حاجة قبل ما تتعمل merge.
2. الـ client ميكلمش الداتابيز مباشرة
كل طلب لازم يعدّي على API بتاعك. الـ API هو اللي ماسك الـ credentials على السيرفر، وبيتأكد من هوية المستخدم، وبيدّيه صلاحياته هو بس. التطبيق نفسه ميكونش معاه غير token خاص بالمستخدم ده.
3. tokens قصيرة العمر وتتلغي
OWASP بتنصح متخزنش credentials المستخدم على الجهاز، وتستخدم access tokens تقدر تلغيها (revocable)، وتغيّر الـ API keys بانتظام. كده لو token اتسرب، الضرر بيبقى محدود ومؤقت.
4. اتسرب حاجة؟ غيّرها فورًا
لو secret اتنشر في نسخة من التطبيق، شيله من الكود مش كفاية، لأن النسخ القديمة لسه على أجهزة الناس. لازم تعمل rotate للـ credential فورًا، وتراجع الـ logs. ولاحظ هنا إن مفيش logs يعني مفيش طريقة تعرف بيها مين دخل.
رأيي
الـ AI غيّر المعادلة. زمان كان فيه ناس بتقول «محدش هيقعد يقرا الكود المفكوك»، دلوقتي التدوير على secrets جوه تطبيق مفكوك بقى شغل دقايق، سواء للباحث الأمني أو للمهاجم. وبرضه وجود طريقة واضحة للإبلاغ عن الثغرات (زي security.txt أو برنامج disclosure) مش رفاهية، الباحث هنا اضطر يروح لصحفيين عشان يوصل للشركة.
آخر مرة عملت scan للـ secrets في الـ build بتاعك كانت إمتى؟
المصادر
- Security
- AppSec
- Mobile
- OWASP
- Full Stack Tips