احجب النص الصريح في تطبيقات Android دون الاعتماد على VPN

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

مشكلتان تحت اسم واحد

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

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

المسار الأول: التطبيق الذي تتحكم فيه

إن كنت توزّع التطبيق، فالإصلاح قرار نقل مع سياسة تفرضه. وجّه كل نقطة نهاية إلى HTTPS، وأبقِ التحقق من اسم المضيف والشهادة مفعّلًا، واحذف البديل الاحتياطي بـ HTTP العادي بدلًا من إبقائه على بعد علم إعداد واحد. إعادة التوجيه لا تفيد هنا: طلب HTTP يتلقى 301 قد أرسل ترويساته وجسمه مكشوفًا، لذا يجب ألا تسافر بيانات الاعتماد أبدًا بافتراض أن إعادة التوجيه ستحميها.

على Android 7.0 وما بعده، يعبّر Network Security Configuration عن السياسة. الملف أدناه هو أصغر نسخة مفيدة: يرفض النص الصريح في كل مكان إلا إذا استثنى استثناء خاص بنطاق ذلك.

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

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

ثمة تفصيلان في الإصدار يستحقان المعرفة. التطبيقات التي تستهدف API 28 أو أحدث ترفض النص الصريح افتراضيًا، لذا فالتطبيق الذي ما زال يتحدث HTTP العادي إما يستهدف مستوى API أقدم أو لديه استثناء في مكان ما. وعند وجود إعداد أمان شبكة، لم تعد سمة المانيفست الأقدم android:usesCleartextTraffic تحدد المسألة، ولهذا يبدو أحيانًا أن تغيير ذلك العلم لا يفعل شيئًا.

المسار الثاني: التطبيق الذي لا تتحكم فيه

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

قواعد الشبكة بدائل أضعف مما تبدو. السماح بالمنفذ 443 فقط لا يفرض TLS موثّقًا، لأن كثيرًا من البروتوكولات النصية يمكن نقلها إلى ذلك المنفذ، وحجب المنفذ 80 لا يغطي النص الصريح على منافذ أخرى. كما أن وضع HTTPS-only في المتصفح محصور بذلك المتصفح، لا بتطبيق بريد أو محادثة منفصل على الهاتف نفسه.

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

أين يفيد VPN وأين لا يفيد

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

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

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

ما يجب اختباره قبل اعتباره محجوبًا

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

adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartext

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

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