أمان التطبيقات في عصر الذكاء الاصطناعي الوكيل

مرحبًا، أنا "كريستين".

مرحبًا، أنا سابس.

ونحن هنا لنتحدّث معكم اليوم عن الأمان في عصر الذكاء الاصطناعي الوكيل.

في العام الماضي، قدّمنا مكافآت تزيد قيمتها عن مليونَي دولار أمريكي في برنامج Android Bug Hunters، وأكثر من 200 ألف دولار أمريكي للأجهزة الجوّالة.

في عصرنا الحالي الذي يعتمد على الوكلاء، يتطوّر أمان التطبيقات باستمرار.

لنتحدّث عن الأدوات التي تساعدنا في حلّ هذه المشاكل بسرعة وفعالية.

لتحسين أداء الوكلاء في ما يتعلّق بأمان Android، لا يكمن الحلّ في تحسين الطلبات.

وهي أدوات ومهام سير عمل تساعد الوكلاء في فهم سلاسل الأدوات وواجهة برمجة التطبيقات لدينا للمساعدة في الحفاظ على أمان تطبيقك.

إذًا، الساعة الآن 4:30 بعد الظهر.

يوم الخميس

أنت بصدد إصدار نسخة جديدة، ويظهر خطأ واحد فقط في عملية الدمج المتواصل (CI): تم تسجيل مستقبِل بث بدون علامة تصدير.

سواء كنت تعمل في فريق صغير وتتولى جميع المهام، أو في فريق كبير حيث يتم إجراء عمليات التحقّق من الأمان أثناء إصدار التطبيق، فإنّ الواقع هو نفسه.

نحن مهندسو منتجات، ونطرح ميزات عالية الجودة بسرعة، ولسنا بالضرورة باحثين في مجال الأمان.

إذًا، ما هو رد الفعل الطبيعي؟

لذا، نرسل هذا التحذير إلى أداة وكيل ونطلب من الوكيل إصلاح المشكلة.

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

وقد لا يعرف أنّ تطبيقك تم إنشاؤه من وحدات ميزات ديناميكية أو حِزم APK متعددة.

فهو يرى ملفًا، وليس قطعة أثرية مشحونة.

قد لا يعرف أو لا يتمكّن من تتبُّع تدفق البيانات من واجهة مستخدم Kotlin إلى منطق KMP المشترَك في طلبات JNI الأصلية بلغة C++‎.

فهو يرى طبقة واحدة فقط.

أخيرًا وليس آخرًا، قد لا يكون على دراية بالحدّ الأدنى لحزمة SDK أو نُسخ إصدار Gradle.

لذا، وجّهنا أحد الوكلاء إلى التطبيق وطلبنا منه إجراء تدقيق أمني.

تم العثور على ست نتائج.

وهنا تكمن المشكلة.

كل واحد منهم ليس على خطأ.

ويمكن الدفاع عنها، ولكن واحدًا منها فقط هو الخطأ الذي بدأنا به بالفعل.

أما الباقي فهو مزيج من الممارسات الجيدة، والأمور التي يجب التحقيق فيها بشكل أكبر، والتخمينات، والأمور التي قد لا تنطبق حتى.

الآن، يمكنك توسيع نطاق ذلك إلى قاعدة رموز برمجية حقيقية، مع المزيد من التحذيرات، وفي كل طلب سحب، ستشعر برغبة في الوصول إلى suppress lint.

ستحصل على التغيير لدمج هذا التغيير، أو قد تفوتك ثغرة أمنية تمامًا.

وهكذا تتسلّل الثغرات الأمنية الحقيقية.

لم تكن الأداة مهملة، بل كانت حذرة، ولكن الحذر ليس مثل الفائدة.

لنجعل هذا ملموسًا.

لنفترض أنّك طلبت من الوكيل "تدقيق كل مكوّن تم تصديره في هذا التطبيق بحثًا عن ثغرة Intent Redirection".

هذه مهمة أمنية حقيقية، وفي تطبيق متعدد الوحدات، تكون مهمة كبيرة.

هذا هو نوع الطلب الذي تظهر فيه التكلفة فعليًا.

وبدون إرشادات خاصة بنظام Android، لن يكون لدى الوكيل استراتيجية للإجابة عن هذا السؤال.

لذلك، فإنه يستخدم القوة الغاشمة.

وقد تقرأ وحدات لا تصدّر أي شيء على الإطلاق.

وقد يعيد استنتاج ما يجعل إعادة توجيه intent قابلة للاستغلال من المبدأ الأول.

وقد يتّبع مسارات لم يكن من الممكن الوصول إليها من قبل.

أنت تدفع مقابل الاستكشاف، وليس التحليل.

المهارة هي ما يوفّر الاستراتيجية المفقودة.

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

ولا يعيد اكتشاف القواعد لأنّها مقدَّمة من المهارة.

في الوقت الحالي، أطلقنا مهارتَين أمنيَّتَين: "أمان الأهداف" و"الأذونات".

يتعلّق أمان Intent بما يمكن للتطبيقات الأخرى أن تجعل تطبيقك يفعله.

يحتفظ تطبيقك بالأذونات وجلسة تسجيل الدخول التي لا يحتفظ بها.

لذلك، كل مكوّن يتم تصديره وكل intent مؤجّلة يتم تسليمها هي طريقة محتملة لشخص ما للتصرّف من خلالك.

وتساعد هذه المهارة في الحماية من ذلك.

تساعد مهارة الأذونات في سدّ الفجوة بين الأذونات المُعلَن عنها والأذونات التي يتم فرضها فعليًا.

ويمكن أن يساعدك في كتابة عملية التحقّق من الأذونات المناسبة.

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

ويكشف أيضًا عن طلبات الأذونات المفرطة.

على سبيل المثال، طلب إذن وصول واسع النطاق في حين أنّ "أداة اختيار الصور" كافية.

استخدِمها مع Android CLI، ثم اسأل: "التدقيق في أمان Intent."

ما مِن إعدادات.

ما مِن ضبط للقواعد.

وبالتالي، لن يكون الناتج عبارة عن مجموعة من التحذيرات.

إنّها مراجعة.

إليك خطأ، وإليك سبب أهميته لتطبيقك، وإليك الحل.

إليكم نصيحة احترافية.

يسهّل استخدام Android CLI العثور على التطبيقات وتثبيتها.

android skills list
android skills add android-intent-security
android skills add android-permissions-security

وبما أنّ المهارة تعرف بالضبط ما تبحث عنه في مشروعك، فإنّها ترى تطبيقك بالطريقة التي يتم بها شحنه فعليًا.

وتراعي الحد الأدنى لإصدار حزمة تطوير البرامج (SDK) لكي يتم تجميع الإصلاح، ومسارات الملفات الحقيقية، وأرقام الأسطر الحقيقية.

إليك المراجعة التي ستتلقّاها.

ويشير إلى الملف والسطر المحدَّدَين، ويشرح التهديد الحقيقي وسبب التغيير، وليس فقط ما يقوله Lint.

ويشير إلى المهارة التي استخدمها.

قرأ إعدادات التصميم، ورأى أنّ الحد الأدنى لإصدار حزمة تطوير البرامج (SDK) هو 26، واختار ContextCompat ليعمل الإصلاح، وقدّم لك ملف مقارنة لتطبيقه.

هذا هو التحذير الذي بدأنا به، ولكن الآن مع إصلاح مقترح وسبب إضافي.

وبالتالي، تكتشف المهارات السابقة الأخطاء الأمنية.

لنتحدّث الآن عن مجال آخر، وهو الامتثال لسياسات التطبيقات.

على سبيل المثال، لنفترض أنّك مطوّر تطبيقات جديد يتطلّع إلى إطلاق تطبيق على "متجر Google Play".

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

تُجري مهارة "سياسة Play" تحليلاً ثابتًا لقاعدة الرموز البرمجية.

إذا كنت تنشر تطبيقًا حاليًا على متجر Google Play، يمكن أيضًا إجراء المقارنة بين مصادر بيانات متعددة بين تحليل الرمز الثابت وبيانات متجر Google Play.

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

سير العمل مشابه للمهارات الأخرى التي ناقشناها: استيراد التطبيق، ثم طلب "مراجعة هذا التطبيق للتأكّد من امتثاله لسياسات Google Play قبل إرساله".

ستظهر لك لقطة شاشة لتقرير كمثال على اليمين، وأوامر Android CLI لتثبيته أدناه.

android skills list
android skills add play-policy-insights

كل ما تحدثنا عنه حتى الآن يحدث قبل شحن التطبيق: تدقيق الأهداف، والتحقق من الأذونات، والتحقق من الامتثال.

هذا هو أمان وقت الإنشاء، وهو ضروري.

ولكن هناك فئة كاملة من التهديدات التي لا تظهر إلا بعد طرح حزمة APK في السوق وتشغيلها على أجهزة قد لا تتحكّم فيها.

تجيب واجهة Play Integrity API عن ثلاثة أسئلة في وقت التشغيل لا يمكن للرمز البرمجي الخاص بك الإجابة عنها: هل هذا إصدار حقيقي وغير مُعدَّل من تطبيقك؟

هل يعمل هذا التطبيق على جهاز Android أصلي؟

وهل هذا حساب مستخدم على Play؟

لذا، يمكنك استخدام واجهة Play Integrity API للحصول على بيانات حول سلامة التطبيق وسلامة الجهاز وغير ذلك.

بالإضافة إلى تسهيل وتسريع عملية نشر تطبيقك بشكل أكثر أمانًا، نسهّل أيضًا عملية تأمين إيرادات تطبيقك وسمعته.

لذا، احمِ مؤسستك من الاحتيال وإساءة الاستخدام.

تساعدك لوحة بيانات "محمي من خلال Google Play" الجديدة، التي يمكنك الاطّلاع عليها هنا، في مراقبة وضبط وسائل الدفاع المتعلّقة بسلامة التطبيق وتوزيعه وتحقيق الربح منه، وكل ذلك في مكان واحد.

سنعمل أيضًا على تقليل وقت الاستجابة لعمليات التحقّق في Play Integrity API، ما يتيح لك استخدامها خلال رحلات المستخدمين التي تتطلّب سرعة عالية لحظر التهديدات والأجهزة التي تشكّل خطرًا بشكل أسرع.

لقد ناقشنا للتو ميزات وأدوات Android التي تساعد في الحفاظ على أمان التطبيقات، ولكن ماذا عن المستخدمين؟

لنلقِ نظرة أولاً على ميزة "الحماية من كلمات المرور الصالحة لمرة واحدة في رسائل SMS".

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

يسمح إذن الرسائل القصيرة للتطبيق بالوصول إلى بيانات المراسلة، بما في ذلك البيانات الحسّاسة مثل كلمات المرور الصالحة لمرة واحدة.

لذلك، قدّمنا بعض واجهات برمجة التطبيقات في تطبيقك لتتمكّن من تنفيذ ذلك، وبالتالي لن تحتاج إلى طلب أذونات واسعة النطاق للرسائل القصيرة، ولكن سيظل بإمكانك الحصول على رموز المرور الصالحة لمرة واحدة (OTP) عبر الرسائل القصيرة لإثبات الهوية.

تتيح واجهة SMS Retriever API لتطبيقك التحقّق تلقائيًا من كلمات المرور الصالحة لمرة واحدة (OTP) بدون الحاجة إلى أذونات واسعة النطاق للوصول إلى الرسائل القصيرة.

يمكنك إلحاق تجزئة مكوّنة من 11 حرفًا تحدّد تطبيقك بالرسالة، وسيسلّمك النظام هذه الرسالة فقط.

وإذا لم تتمكّن من التحكّم في تنسيق الرسالة، استخدِم واجهة SMS User Consent API.

يعرض النظام طلبًا واحدًا يظهر لمرة واحدة.

ينقر المستخدم على "السماح" أو "الرفض"، وإذا سمح، ستتلقّى هذه الرسالة الواحدة.

لا حاجة إلى إذن واسع النطاق للوصول إلى الرسائل القصيرة SMS.

قد تحتاج بعض التطبيقات إلى الموقع الجغرافي الدقيق لمرة واحدة فقط لإكمال المهام.

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

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

وهو عنصر في واجهة مستخدم Android يمكن لمطوّري التطبيقات تخصيصه وتضمينه.

أطلقنا الإصدار الأولي من مكتبة Jetpack لزر مشاركة الموقع الجغرافي في يونيو.

يمكنك هنا الاطّلاع على الأذونات المطلوبة لتفعيل زر مشاركة الموقع الجغرافي في ملف بيان Android.

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton"/>

<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

    <application
        android:icon="@mipmap/ic_launcher"
        android:label="LocationButtonSample"
        android:theme="@style/Theme.PinPoint">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

يجب الإفصاح عن إذن تحديد الموقع الجغرافي العادي من خلال إضافة علامة الإذن onlyForLocationButton، إلى جانب إذن USE_LOCATION_BUTTON المخصّص الذي تتطلّبه خدمة العرض عن بُعد في النظام.

وعلى اليسار، يظهر رمز Jetpack لتنفيذ ذلك.

...
import androidx.core.locationbutton.compose.LocationButton

@Composable
fun LocationPermissionScreen(onPermissionGranted: () -> Unit, onPermissionDenied: () -> Unit) {
    // Renders the secure system-trusted Location Button composable
    LocationButton(
        // Callback triggered when the user taps the secure button and makes a decision on the permission dialog
        onPermissionResult = { isGranted ->
            if (isGranted) {
                onPermissionGranted()
            } else {
                onPermissionDenied()
            }
        },
...

يمكنك أن ترى هنا أننا ننشئ زر مشاركة الموقع الجغرافي ونبدأ عملية استدعاء.

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

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

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

ولكن عندما يكون "وضع الحماية المتقدّمة" مفعَّلاً، يعرف تطبيقك أنّ هذا المستخدم يريد أقصى قدر من الحماية، لذا يمكنك طلب المصادقة بالمقاييس الحيوية تلقائيًا في كل عملية تحويل.

يوفّر وضع "الحماية المتقدّمة" مجموعة من الإعدادات المحدّدة مسبقًا والمصمّمة لتعزيز حماية الجهاز.

في ما يلي، نوضّح لك كيفية دمج هذه الميزة في تطبيقك.

عليك طلب الإذن والاستعلام عن وضع الحماية المتقدّمة والتحقّق مما إذا كان المستخدم قد فعّل وضع الحماية المتقدّمة باستخدام خدمة نظام مدير وضع الحماية المتقدّمة على الجهاز فقط.

class AdvancedProtectionManager() {
  // Check the current status
  fun isAdvancedProtectionEnabled(): Boolean

  // Be alerted when status changes
  fun registerAdvancedProtectionCallback(executor: Executor,
                                         callback: Callback)

  fun unregisterAdvancedProtectionCallback(callback: Callback)
}

interface Callback() {
  // Called when advanced protection state changes
  fun onAdvancedProtectionChanged(enabled: Boolean)
}

بعد ذلك، يمكنك الاستماع إلى التغييرات في وقت التشغيل من خلال تسجيل دالة الاستدعاء.

لقد تناولنا الكثير من المواضيع اليوم.

إليك روابط سريعة إذا أردت معرفة المزيد عنها.

سنتوقف هنا لثانية حتى تتمكن من تدوين عناوين URL التي تحتاجها.

شكرًا لك.

شكرًا لك.