الرئيسية›الرؤى›ثغرة مكدّس التنقل
أمن التطبيقات المحمولة: الفجوات أولاً

ثغرة Navigation 3: لماذا قد يسرّب مكدّس التنقل (backstack) بياناتك

حين تصبح حالة التنقل بيانات، قد تظهر إخفاقات الخصوصية والتفويض في أماكن غير متوقعة. وكثيراً ما يغفلها التفكير القديم القائم على نقاط الدخول.

Fireland Labs · 25 أكتوبر 2026

النموذج القديم: لماذا كانت الـ intents مهمة

لزمن طويل كان لإرشاد أمن Android مركز ثقل واضح: نقاط الدخول. الـ Activities والـ services والـ receivers والـ intents التي تصل إليها. وإذا استطاع تطبيق آخر إرسال شيء إلى مكوّنك، فتلك هي الحدود التي تستحق الدراسة.

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

بُنيت كثير من قوائم التحقق وعادات المراجعة في ذلك العصر، وما زالت مفيدة. الخطر في الافتراض الصامت بأن «راجعنا الـ intents» تعني «راجعنا التنقل».

النموذج الجديد: حالة التنقل كبيانات

تبدو التطبيقات الحديثة مختلفة في الغالب: مضيف واحد، وشاشات تصريحية، ومكتبة تنقل تحتفظ بقائمة الوجهات في الذاكرة كبيانات عادية. لم يعد مكدّس التنقل (backstack) شيئاً تديره المنصة نيابة عنك. إنه بنية يبنيها شيفرتك وتقرؤها وتغيّرها.

هذا تحسّن حقيقي للمطورين: فهو أسهل في الاختبار وفي الاستدلال وفي الاستعادة. لكنه ينقل الخطر أيضاً.

فحين تصبح حالة التنقل بيانات، تستطيع أن تحمل بيانات. فالوجهات تحتفظ غالباً بوسائط أو معرّفات أو نماذج كاملة. ويمكن أن تنتهي هذه الكائنات في أماكن لم يفكر فيها التصميم الأصلي: الحالة المحفوظة، والسجلات، وتقارير الأعطال، وأحداث التحليلات. كما أصبح الوصول إلى الشاشة سؤالاً يجيب عنه تطبيقك بنفسه، لا نظام التشغيل نيابةً عنك.

وتتغير الأسئلة الجديرة بالطرح تبعاً لذلك. ليس فقط «من يستطيع الوصول إلى هذا المكوّن؟» بل «ما الذي يتطلبه هذا المسار، ومن يفرضه، وإلى أين تذهب هذه الحالة؟»

أنماط إخفاق تخيلية

سيناريوهات تخيلية. تصف أنماط مخاطر لا منتجات حقيقية، وتُغفل عمداً كيفية إثارة أي شيء منها.

ثلاثة أنماط نراها معتادة حين يكون التنقل حالة.

  • بيانات حساسة في حالة التنقل. وجهة تحمل سجلاً كاملاً بدلاً من معرّف. يسافر هذا السجل الآن حيثما تسافر حالة التنقل: التخزين الدائم، والتشخيص، والسجلات. بيانات كان يُفترض أن تعيش لشاشة واحدة تبقى بعدها.

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

  • بيانات حساسة قديمة عند الرجوع. بعد تسجيل الخروج أو تبديل الحساب أو انتهاء الجلسة، يرجع المستخدم إلى الخلف فتعرض شاشة سابقة ما كانت تحتفظ به من قبل. تغيّرت الحالة، لكن الشاشات الواقعة خلفها لم تُبلَّغ.

لا يحتاج أي منها إلى خلل غريب. فهي تنشأ من خيارات تصميم معقولة روجعت واحداً تلو الآخر، ولم تُراجَع يوماً كوحدة متكاملة.

لماذا يهم هذا

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

قد تنتهي الفرق التي تعتمد على مراجعات تركّز على الـ intents، أو على اختبار نقاط النهاية وحده، بتقرير مرتب لم ينظر في التنقل أبداً. فقد يطبّق الخادم كل شيء بصورة صحيحة بينما يكشف العميل ما نزّله بالفعل.

  • انكشاف الخصوصية. بيانات شخصية تُعرض لجلسة خاطئة، أو تُخزَّن في أماكن جمهورها أوسع من الشاشة.

  • احتكاك الصفقات. تسأل مراجعة أمنية كيف تُحمى المسارات والحالة، والإجابة الصادقة هي «لم ننظر في ذلك».

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

هذه ليست حجة ضد التنقل الحديث، بل حجة لاختبار التطبيق الموجود فعلاً، لا ذلك الذي كُتبت له قائمة التحقق.

صندوق الأثر

قيد المراجعة. لم تُراجَع نمذجة الأثر لهذه المقالة ولم يُعتمد عليها بعد. الهيكل أدناه عنصر نائب، ولا يتضمن أي أرقام عن قصد.

نموذج توضيحي وليس توقعاً. المحتوى لاحقاً.

  • أثر العملاء (الآليات): نوعي فقط، مثل فقدان الثقة والتسرّب وعبء الدعم. قيد المراجعة.

  • أثر المستثمرين (الآليات): نوعي فقط، مثل احتكاك الصفقات ومخاطر الجدول الزمني وإصلاحات تعيق المضي قدماً. قيد المراجعة.

  • الأثر التنظيمي (بإيجاز): الأطر المنطبقة وفئة المخاطر قيد التأكيد. ليس استشارة قانونية ولا شهادة امتثال.

  • الافتراضات: ستُدرج لاحقاً.

ما الذي يُختبر

يبدأ الاختبار من كيفية تنقل التطبيق فعلياً، لا من ملف manifest الخاص به. بإيجاز، ثلاثة مجالات.

  • ثوابت تفويض المسارات. لكل مسار حساس: ما الذي يجب أن يتحقق قبل عرضه، وهل يُفرض ذلك في الحالة والمنطق لا فيما تعرضه الواجهة فقط؟ تحقق من بقاء الثابت صحيحاً حين يُبلَغ المسار بترتيب غير معتاد.

  • تسلسل الحالة وانكشافها في السجلات. تتبّع محتوى حالة التنقل، وأين تُحفظ، وأي السجلات وتقارير الأعطال وأحداث التحليلات تستطيع رؤيتها.

  • سلوكيات الإعادة والاستعادة. تحقق مما يحدث بعد إنهاء العملية، وبعد تسجيل الخروج، وبعد تبديل الحساب، وعبر الروابط العميقة حيث يلزم. يجب إعادة التحقق من الحالة المستعادة لا الوثوق بها.

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

ماذا تسأل المزوّد

سؤالان يفرّقان بين الاختبار السطحي والحقيقي، وثالث يتناول كيف تُدعَّم النتائج.

  • هل تختبرون منطق المسارات وحراستها، أم نقاط النهاية فقط؟

  • كيف تتعاملون مع استعادة الحالة وسلوكيات الرجوع؟

  • ما الأدلة التي تقدمونها لنتائج انكشاف الحالة والتفويض؟

الإجابات الجيدة محددة بشأن التدفقات والجلسات والأدلة. أما الإجابات الغامضة عن «التغطية الكاملة» فتستحق سؤال متابعة.

من أين تبدأ

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

هل لديك سؤال عن منتجك؟ اترك بريدك الإلكتروني وسنتواصل معك خلال 1–2 يوم عمل.

الخصوصية

تفضل البريد الإلكتروني؟ hello@firelandlabs.com

❌🕸️