إذا كنت على دراية بـ "إضافة إلى الشاشة الرئيسية" على Android، فهناك المزيد حول هذا الأمر: يمكن لمتصفح Chrome إنشاء حزمة التثبيت الخاصة به لتطبيق PWA الخاص بك والتي تسمى WebAPK.، مما يجعله يتصرف مثل تطبيق النظام: يظهر في درج التطبيقات، ويتم إدراجه في إعدادات Android، ويمكنه فتح الروابط من نطاقك مباشرة في التطبيق.
في هذا الدليل، ستفهم ما هو WebAPK، وكيف يبنيه Chrome من بيان تطبيق الويب الخاص بك، وما هي مرشحات النية التي يسجلها، وكيف يتعامل مع الأذونات والتخزين، ومدى تكرار تحديثه، وما هي مخاطر الأمان التي يجب عليك مراعاتها (مع حالات حقيقية من حملات التصيد الاحتيالي التي تم اكتشافها).بالإضافة إلى ذلك، سترى توصيات عملية لتقليل سطح الهجوم لديك وضمان تشغيل تطبيق الويب التقدمي (PWA) الخاص بك بأمان على نظام Android.
ما هو WebAPK ولماذا هو مهم
WebAPK هو ملف APK خاص يتم إنشاؤه تلقائيًا بواسطة Chrome لنظام Android عندما يقوم المستخدم بتثبيت تطبيق ويب تقدمي (PWA) على الشاشة الرئيسية.على عكس الاختصار البسيط، تقوم هذه الحزمة بتحويل موقعك إلى "تطبيق" في نظر النظام: فهي تتكامل مع مُبدِّل التطبيق، ولديها إدخالها الخاص في إعدادات التطبيق، والأهم من ذلك، أنها تسجل مرشحات النية لالتقاط عناوين URL ضمن نطاق تطبيقك.
يقوم المتصفح بفحص بيان الويب (manifest.json) والبيانات الوصفية الأخرى لبناء WebAPKعندما يكتشف Chrome تغييرات ذات صلة بالبيان، فإنه يطلب ملف APK جديدًا ويقوم بنشره، مما يضمن أن التطبيق المثبت يعكس التكوين المحدث دون أي إجراء يدوي من قبل المستخدم.
إن "ترقية" تطبيق الويب التقدمي الخاص بك إلى WebAPK يعني أيضًا ميزة إضافية في تجربة المستخدم والتكامل.يُفتح في وضع مستقل، دون الحاجة إلى واجهة المستخدم الخاصة بالمتصفح، ويستجيب للروابط من النطاق، ويعرض الأيقونة والاسم وشاشة البداية كتطبيق أصلي. لا يستخدم WebView، بل يعمل في نسخة Chrome التي ثبّتها المستخدم.
كيفية إنشاء Chrome لملفات WebAPK وما الذي يجب مراعاته
تبدأ العملية بملف manifest.jsonيقرأ Chrome خصائص مثل الاسم والأيقونات وعنوان URL للبدء والعرض والنطاق، ويُنشئ ملف APK. إذا اكتشف تحديثًا للبيان يؤثر على الحقول الرئيسية، فسيعيد بناء ملف WebAPK. لذلك، يُنصح بعدم الاستمرار في تغيير البيان.
تجنب استخدام البيان للبيانات المخصصة أو معرفات المستخدم- إذا قمت بإدراج معلومات متغيرة بشكل متكرر، فسوف تجبر على إعادة التجميع بشكل متكرر مما يؤدي إلى زيادة أوقات التثبيت والتحديث، مما يؤدي إلى تفاقم التجربة.
مثال بسيط على البيان الذي يفتح التطبيق بشكل مستقل عن المصدر:
{
"start_url": "/",
"display": "standalone"
}باستخدام هذا التكوين، سيؤدي فتح التطبيق من درج التطبيقات إلى تحميل المصدر (على سبيل المثال، https://example.com/) في الوضع المستقل.، بدون شريط Chrome أو عناصر التحكم النموذجية في المتصفح.
نوايا Android: التقاط الروابط في النطاق
عند تثبيت تطبيق ويب تقدمي (PWA) كـ WebAPK، يسجل نظام Android مرشحات النية لجميع عناوين URL التي تقع ضمن نطاق التطبيق.إذا قام المستخدم بالنقر على رابط ضمن هذا النطاق، فسيتم فتحه مباشرة في التطبيق بدلاً من فتحه في علامة تبويب المتصفح.
يتضمن ملف APK مرشحات النية مع إجراء VIEW، والفئات DEFAULT وBROWSABLE، والبيانات التي تحدد المخطط (https)، والمضيف، والمسار الذي يتحكم فيه تطبيقك.قد يبدو المرشح النموذجي لتغطية المجال بأكمله على النحو التالي (ملخصًا):
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" android:host="example.com" android:pathPrefix="/" />
</intent-filter>باستخدام هذا الفلتر، سيؤدي النقر على رابط مثل https://example.com/read في تطبيق آخر إلى تشغيل WebAPK الخاص بك لخدمته. بالإضافة إلى ذلك، إذا انتقل المستخدم يدويًا إلى عنوان URL ضمن النطاق من شريط عناوين Chrome، فسيفترض المتصفح نية زيارة الموقع وسيفتحه كما ينبغي، تمامًا كما يفعل مع تطبيق أصلي ذي نوايا مُعلنة.
تحديد النطاق باستخدام النطاق
إذا كنت لا تريد أن "يمتص" ملف WebAPK الخاص بك النطاق بأكمله، فقم بتحديد النطاق في البيانيُحدد مزيج الأصل والنطاق المسارات التي تنتمي إلى تطبيقك، والتي يجب أن يستمر فتحها في المتصفح. يُعد هذا مفيدًا إذا كان التطبيق والمحتوى العام موجودين على نفس المضيف.
مثال على بيان بنطاق مقيد بـ /app/:
{
"scope": "/app/",
"start_url": "/app/",
"display": "standalone"
}مع هذا النطاق، سيستخدم مرشح نية WebAPK android:pathPrefix="/app/" لفتح ما يقع ضمن هذا المسار فقط في التطبيق، وترك بقية الموقع للمتصفح.
الأذونات والإشعارات وكيفية إدارتها
تتصرف الأذونات في WebAPK مثل أي تطبيق ويب.لا يُطلب هذا أثناء التثبيت. يُنصح بطلبه أثناء التشغيل، وإن أمكن، في اللحظة التي يحتاج فيها المستخدم إلى هذه الإمكانية (على سبيل المثال، طلب الكاميرا عند التقاط صورة، وليس عند تحميل الصفحة الرئيسية).
فارق بسيط مهم مع الإشعاراتبينما يمنح أندرويد عادةً أذونات الإشعارات للتطبيقات المُثبّتة بسرعة، لا تتلقى ملفات WebAPK أذونات الإشعارات فورًا. يجب أن يطلب تطبيقك هذه الأذونات صراحةً أثناء التشغيل باستخدام واجهة برمجة تطبيقات الويب المناسبة، وسيظهر للمستخدم مربعات حوار Chrome، وليس مربعات أندرويد الأصلية.
التخزين والحالة: ما يشاركه مع المتصفح
على الرغم من أن التثبيت عبارة عن APK، إلا أن بيانات WebAPK موجودة في ملف تعريف Chrome الحالي.تتم مشاركة ملفات تعريف الارتباط، ومساحة التخزين من جانب العميل (IndexedDB، وlocalStorage، وCache Storage)، وموظفي الخدمة مع المتصفح. هذا يسمح بتجربة موحدة بين إصدار المتصفح والتطبيق المُثبّت.
النتيجة المباشرة: إذا قام المستخدم بحذف بيانات الموقع أو مسح ملف تعريف Chrome، فسوف يؤثر ذلك أيضًا على WebAPK.وهذا يعني أن التطبيق المثبت ليس معزولًا على مستوى التخزين؛ فهو يستفيد من الاتساق، ولكنه يرث الملفات المحذوفة.
تحديثات WebAPK: التردد والمحفزات
يقوم Chrome بمراجعة البيان بشكل دوري ويقرر ما إذا كان سيطلب WebAPK جديدًا ويقوم بتثبيته.. يعتمد التردد على إصدار Chrome:
- Chrome 76 والإصدارات الأحدث:محاولة التحقق يوميًا. في حالات نادرة، عندما لا يتمكن خادم التحديث من تقديم التغييرات، تنخفض الفترة إلى 1 يومًا.
- Chrome 75 والإصدارات الأقدم:كانت الدورة المعتادة كل 3 أيام، مع نسخة احتياطية لمدة 30 يومًا في حالة فشل خادم التحديث.
مثال افتراضي لمتصفح Chrome 76+ سيكون هذا على النحو التالي: تقوم بتثبيت WebAPK في الأول من يناير؛ إذا قمت بفتحه في اليوم الثاني، فقد مرت 1 ساعة ويتحقق من وجود تحديث؛ فتح Chrome بمفرده لا يفرض الفحص؛ إذا قمت بمسح بيانات Chrome (على سبيل المثال، في السادس من يناير)، من وجهة نظر المتصفح، يعتبر التشغيل التالي لـ WebAPK "الأول" ويتم إعادة تعيين عدد الأيام للتحقق مرة أخرى.
في Chrome 75- كان السلوك مشابهًا، ولكن مع وجود فترات زمنية مدتها 3 أيام بين الفحوصات عندما يسير كل شيء على ما يرام، ونفس الفترة الاحتياطية لمدة 30 يومًا إذا لم يستجب الخادم بشكل صحيح.
WebAPK وPWA وAPK: التوافق والاختلافات
APK هو تنسيق حزمة تطبيقات Android، بينما PWA هو تطبيق ويب يستفيد من المعايير مثل العاملين في الخدمة، والبيان، وHTTPS.ملف WebAPK هو الجسر: حيث يقوم المتصفح بتجميع تطبيق الويب التقدمي في ملف APK "وسيط" لدمجه كتطبيق مثبت.
في الممارسة العملية، يقوم WebAPK بـ "رفع" سلوك موقع الويب إلى مستوى أصلي للمستخدم.: الرمز الخاص، التواجد في الدرج، تعدد المهام، إلغاء التثبيت من الإعدادات، النوايا لفتح الروابط، شاشة البداية والذاكرة المؤقتة الداخلية التي يديرها عامل الخدمة.
تاريخيًا، كان Chrome يعزز هذا النهج.من اختصارات الويب والإشعارات البسيطة، إلى تطبيقات الويب التقدمية ذات القدرات المتزايدة؛ وأخيرًا، إلى ملفات WebAPK التي تبدو مثل التطبيقات الكاملة، مع كونها لا تزال تعتمد على الويب في الأساس.
عمال الخدمة والتشغيل دون اتصال بالإنترنت
عامل الخدمة هو المحرك الذي يتيح التحميل السريع والاستخدام دون اتصال بالإنترنت والتحكم الدقيق في الشبكة والذاكرة المؤقتة.إنه يعمل في الخلفية، ويعترض طلبات تقديم الموارد من Cache Storage أو تطبيق استراتيجيات الاسترداد عندما لا يكون هناك اتصال، تمامًا كما يفعل الوكيل المحلي.
مع هذه القوة تأتي المسؤولية.- يجب أن يتم إصدار عامل الخدمة وتكوينه بشكل صحيح، مع سياسات واضحة للتخزين المؤقت والتحديث، لتجنب سيناريوهات التقادم أو الأسوأ من ذلك، تسميم ذاكرة التخزين المؤقت إذا تمكن المهاجم من حقن المحتوى.
المخاطر الأمنية في PWA وWebAPK
كما هو الحال مع أي تقنية أخرى، يمكن إساءة استخدام PWA/WebAPK إذا كان التنفيذ أو النشر ضعيفًا.. بعض المتجهات التي ينبغي أخذها في الاعتبار:
- التصيد الاحتيالي عبر PWA/WebAPKإنشاء تطبيقات ويب مزيفة تُثبّت على هيئة ملفات WebAPK، وتنتحِل صفة تطبيقات أو خدمات مصرفية. مظهرها جذاب للغاية، وتكاملها مع أندرويد يُقلل من الشكوك.
- عمال الخدمة الملتزمون: يمكن أن يؤدي إلى تسميم ذاكرة التخزين المؤقت وتقديم محتوى ضار بشكل مستمر.
- رجل في الوسط (MitM):يؤدي سوء تكوين HTTPS أو الشهادات أو سياسات HSTS إلى فتح الباب أمام اعتراض حركة المرور والتلاعب بها.
- XSS (البرمجة النصية عبر المواقع)- تطبيقات الويب، بطبيعتها، معرضة للخطر إذا لم يتم التحقق من صحتها أو الهروب منها بشكل صحيح؛ حيث أن XSS في تطبيق PWA المثبت يكون ضارًا بشكل خاص لأنه يؤثر على التطبيق الذي يثق به المستخدمون أكثر.
- البرامج النصية الضارة بواسطة CSP الضعيف:تسمح سياسة أمان المحتوى غير المحددة جيدًا بتحميل موارد غير آمنة أو نصوص مضمنة خطيرة.
- CSRF- قد يؤدي الفشل في حماية الإجراءات الحساسة باستخدام الرموز والرؤوس المناسبة إلى تشغيل طلبات غير مصرح بها نيابة عن المستخدم المعتمد.
- حقن SQL في الخلفية- ليس خاصًا بتطبيق الويب التقدمي (PWA)، ولكنه لا يزال ساري المفعول إذا لم يقم الخادم بتطهير المدخلات.
- التلاعب بملف APK:قد تقوم القنوات غير الرسمية بتوزيع ملفات APK معدلة تحتوي على تعليمات برمجية ضارة (على الرغم من أن ملف WebAPK الذي تم إنشاؤه بواسطة Chrome لا يتم توزيعه بنفسك، إلا أنه يشكل مخاطرة عامة إذا قام المستخدم بتثبيت حزم تابعة لجهات خارجية).
- الاستمرارية الإدراكية:بعد التثبيت، يمكن حذف ملف APK من وحدة التخزين دون توقف التطبيق عن العمل، مما يجعل من الصعب على المستخدم اكتشاف القطع الأثرية المشبوهة.
تم اكتشاف حملات حقيقية: الحالة المصرفية التي تم تحليلها بواسطة ESET
قام باحثو شركة ESET بتوثيق حملة تصيد غير عادية تستهدف عملاء الخدمات المصرفية عبر الهاتف المحمول.، مع التركيز على جمهورية التشيك، مع حالات معزولة في المجر وجورجيا. تميزت هذه التقنية بتثبيت تطبيق تصيد احتيالي من موقع تابع لجهة خارجية دون الحاجة إلى سماح المستخدم بـ "مصادر غير معروفة".
- على نظام Android، تحول تطبيق PWA إلى WebAPK يبدو أنه جاء من Google Play.أثناء استخدام نظام iOS، طُلب من الضحية إضافة تطبيق ويب تقدمي (PWA) إلى الشاشة الرئيسية. في كلا الحالتين، كانت التطبيقات الناتجة غير قابلة للتمييز تقريبًا عن التطبيقات الأصلية.
- قنوات التوزيعمكالمات آلية تُحذر من "تطبيق مصرفي قديم" وتُرسل رسائل نصية قصيرة تحتوي على الرابط؛ وحملات رسائل نصية جماعية؛ وإعلانات خبيثة على منصات التواصل الاجتماعي مع دعوات للعمل مثل "تنزيل التحديث". بعد فتح رابط الموقع، سيظهر للمستخدم صفحة تُحاكي قائمة متجر Play أو موقعًا مُستنسخًا من تطبيق المصارف، وسيُطلب منه تثبيت "إصدار جديد".
- البنية التحتية للمهاجمينلُوحظت متغيرات تُخزّن بيانات الاعتماد عبر بوت تيليجرام باستخدام واجهة برمجة التطبيقات الرسمية، بينما تستخدم أخرى خوادم قيادة وتحكم تقليدية مزودة بلوحة إدارة. تشير الأدلة إلى وجود مجموعتين منفصلتين على الأقل وراء هذا النشاط.
- لماذا هذا ممكن؟تطبيقات الويب التقدمية (PWAs) متعددة المنصات، وعند تثبيتها كملفات WebAPK، تُدمج في نظام أندرويد دون عرض تنبيهات "مصدر غير موثوق"، ومن هنا تأتي الفعالية الاجتماعية لهذا المخطط. أبلغت شركة ESET البنوك المتضررة بالنتائج على الفور، وتعاونت معها لتعطيل نطاقات التصيد الاحتيالي وخوادم القيادة والتحكم.
أفضل الممارسات للتخفيف من المخاطر
- تقوية HTTPS والرؤوس:شهادات صالحة، وHSTS، وإعادة توجيه HTTPS، وسياسة أمان المحتوى الصارمة (CSP) التي تقيد مصادر البرامج النصية/الموارد.
- تعامل مع عامل الخدمة باعتباره برنامجًا بالغ الأهمية: مراجعات الأمان، وتحكم واضح في الإصدارات، وإبطال آمن لذاكرة التخزين المؤقت، واختبار التحديثات. تجنب الأنماط التي تُسهّل إفساد ذاكرة التخزين المؤقت.
- منع XSS/CSRF: يُنقّي ويُخفِف المُدخلات، ويستخدم قوالب آمنة، ورموزًا مضادة لـ CSRF، ورؤوس SameSite لملفات تعريف الارتباط. يدعم سلامة الموارد الفرعية (SRI) للتبعيات الخارجية.
- إدارة الأذونات الدنيا والسياقية:اطلب الأذونات في الوقت المناسب، وقدم نسخًا واضحة وقابلة للعكس؛ وراجع بشكل دوري الأذونات التي لا يزال تطبيقك يحتاج إليها.
- تحديث PWA والخادم بشكل متكرر- إصلاح الثغرات الأمنية المعروفة والتحقق من أن Chrome يكتشف ويطبق WebAPKs الجديدة عندما تتغير خصائص البيان الرئيسية.
- التوزيع المسؤولوجّه مستخدميك لتثبيت تطبيقاتك من نطاقك الرسمي؛ وحذرهم من الروابط في الرسائل النصية/المكالمات/الإعلانات. إذا كنت ترغب في النشر على متجر Play، فاختر "أنشطة الويب الموثوقة" بدلاً من محاولة تحميل ملف WebAPK مُنشأ من Chrome.
- مراقبة العلامة التجارية والتصيد الاحتيالي- تراقب تسجيلات النطاقات المشابهة، والإعلانات المشبوهة، والذكر على وسائل التواصل الاجتماعي؛ وتساعدك أدوات استخبارات التهديدات على الرد قبل تفاقم الأمور.