امنیت برنامه در عصر عاملی

سلام، من کریستن هستم.

سلام، من هم سَبز هستم.

و ما اینجا هستیم تا امروز درباره امنیت در عصر عاملی با شما صحبت کنیم.

در سال گذشته، بیش‌از ۲ میلیون دلار پاداش برای برنامه «شکارچیان اِشکال Android» و بیش‌از ۲۰۰ هزار دلار برای تلفن همراه پرداخت کردیم.

در عصر عاملی امروز، امنیت برنامه به‌طور مداوم درحال تکامل است.

بنابراین، بیایید درباره ابزارهایی صحبت کنیم که به ما کمک می‌کنند این مشکلات را به‌سرعت و به‌طور مؤثر حل کنیم.

برای بهبود عملکرد عامل‌ها درزمینه امنیت Android، پاسخْ پیام‌واره بهتر نیست.

این ابزارها و گردش‌های کاری به نمایندگان کمک می‌کند تا زنجیره ابزارها و API ما را درک کنند و به حفظ امنیت برنامه‌تان کمک کنند.

بنابراین، ساعت ۴:۳۰ بعدازظهر است.

در یک روز پنج‌شنبه.

درحال انتشار نسخه هستید و CI قرمز می‌شود، فقط یک خطا: گیرنده رویداد ثبت‌شده بدون پرچم برون‌برد ثبت شده است.

بنابراین، چه در تیم کوچکی باشید که همه کارها را خودتان انجام می‌دهید، چه در تیم بزرگی باشید که بررسی‌های امنیتی در زمان انتشار نسخه انجام می‌شود، واقعیت یکسان است.

ما مهندسان محصول هستیم که ویژگی‌های با کیفیت بالا را به‌سرعت عرضه می‌کنیم و لزوماً پژوهشگران امنیتی نیستیم.

پس غریزه طبیعی چیست؟

بنابراین، آن هشدار را به ابزار عاملی می‌دهیم و از عامل می‌خواهیم آن را اصلاح کند.

اما ابزار عاملی، که بدون بافت پروژه شما کار می‌کند، سه نقطه کور دارد.

ممکن است نداند برنامه شما از واحد ویژگی پویا یا دسته‌های چند APK ساخته شده است.

فایل می‌بیند، نه محصول ارسال‌شده.

ممکن است نتواند جریان داده را از Kotlin UI شما به منطق مشترک KMP شما در فراخوانی‌های بومی C++ JNI ردیابی کند.

فقط یک لایه را می‌بیند.

و درنهایت، ممکن است از حداقل کیت توسعه نرم‌افزار یا انواع ساخت Gradle شما آگاه نباشد.

بنابراین، نماینده‌ای را به برنامه ارجاع دادیم و درخواست ممیزی امنیتی کردیم.

شش یافته برگشت.

و نکته اینجاست.

تک‌تک آن‌ها درست است.

هر دو قابل‌دفاع هستند، اما فقط یکی از آن‌ها همان اشکالی است که در ابتدا با آن شروع کردیم.

بقیه موارد ترکیبی از روش‌های خوب، چیزهایی برای بررسی بیشتر، گمانه‌زنی، و چیزهایی است که ممکن است حتی قابل‌اجرا نباشد.

بنابراین، اکنون آن را به یک پایگاه کد واقعی با هشدارهای بیشتر تبدیل می‌کنید و در هر درخواست واکشی، وسوسه می‌شوید که به suppress lint دسترسی پیدا کنید.

باید تغییر را دریافت کنید تا بتوانید آن تغییر را ادغام کنید، یا حتی ممکن است آسیب‌پذیری را به‌طور کامل ازدست بدهید.

و این‌گونه است که آسیب‌پذیری‌های واقعی از فیلترها عبور می‌کنند.

این ابزار بی‌دقت نبود، بلکه دقیق بود، اما دقیق بودن با مفید بودن یکی نیست.

بیایید این را ملموس کنیم.

مثلاً از عاملتان می‌خواهید: «همه مؤلفه‌های صادرشده در این برنامه را ازنظر هدایت قصد برنامه بررسی کن.»

این یک وظیفه امنیتی واقعی است و در یک برنامه چندپودمانی، وظیفه بزرگی است.

این نوع درخواست جایی است که هزینه واقعاً نشان داده می‌شود.

و بدون راهنمایی خاص Android، نماینده هیچ استراتژی‌ای برای آن سؤال ندارد.

بنابراین، از روش حمله جستجوی فراگیر استفاده می‌کند.

ممکن است ماژول‌هایی را بخواند که اصلاً چیزی صادر نمی‌کنند.

ممکن است دوباره از اصل اول استخراج کند که چه چیزی باعث می‌شود هدایت مجدد قصد قابل‌سوءاستفاده باشد.

ممکن است مسیرهایی را دنبال کند که هرگز قابل دسترسی نبوده‌اند.

شما برای کاوش پرداخت می‌کنید، نه تحلیل.

مهارت چیزی است که استراتژی گم‌شده را فراهم می‌کند.

برای مثال، مهارت‌های امنیتی Android دستورالعمل‌هایی را به عامل شما ارائه می‌دهد که از راهنمایی‌های فعلی پیروی می‌کنند، همان توالی مراحلی که یک محقق امنیتی درواقع دنبال می‌کند، و عامل از حدس زدن دست می‌کشد.

قوانین را دوباره کشف نمی‌کند چون قوانین توسط مهارت ارائه شده‌اند.

درحال‌حاضر، دو مهارت امنیتی راه‌اندازی کرده‌ایم: «امنیت هدف» و «اجازه‌ها».

امنیت هدف به این مربوط می‌شود که برنامه‌های دیگر چه کارهایی می‌توانند ازطریق برنامه شما انجام دهند.

برنامه شما اجازه‌ها و جلسه ورود به سیستمی دارد که آن‌ها ندارند.

بنابراین، هر مؤلفه صادرشده و هر قصد معوقی که توزیع می‌کنید، راهی بالقوه برای کسی است که ازطریق شما اقدام کند.

این مهارت به محافظت دربرابر این مشکل کمک می‌کند.

مهارت اجازه‌ها کمک می‌کند فاصله بین اجازه‌ای که اعلام شده و اجازه‌ای که واقعاً اعمال شده است کاهش یابد.

این ابزار می‌تواند به شما کمک کند بررسی اجازه‌های مناسب را بنویسید.

این کار کمک می‌کند تا مشخص شود آیا ارائه‌دهنده‌ای با مسیر نویسه عام به‌جای یک دایرکتوری، کل پایگاه داده را اعطا می‌کند یا نه.

همچنین اجازه‌های بیش‌ازحد را شناسایی می‌کند.

برای مثال، درخواست دسترسی گسترده در جایی که انتخاب‌گر عکس کافی است.

از آن با Android CLI استفاده کنید و سپس بپرسید: «Audit for intent security.»

پیکربندی‌ای وجود ندارد.

بدون تنظیم قانون.

بنابراین، خروجی دیواری از هشدارها نیست.

مرور است.

اینجا یک اشکال وجود دارد، اینجا دلیل اهمیت آن برای برنامه‌تان است، و اینجا راه‌حل آن است.

و این هم نکته حرفه‌ای.

استفاده از Android CLI پیدا کردن و نصب را آسان می‌کند.

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

و چون این مهارت دقیقاً می‌داند در پروژه شما دنبال چه چیزی بگردد، برنامه شما را همان‌طور که واقعاً عرضه می‌شود می‌بیند.

این ابزار به حداقل کیت توسعه نرم‌افزار شما احترام می‌گذارد تا اصلاحیه، مسیرهای فایل واقعی، و شماره خطوط واقعی را کامپایل کند.

این مروری است که دریافت می‌کنید.

این ابزار به فایل و خط دقیق اشاره می‌کند، تهدید واقعی را توضیح می‌دهد، و دلیل تغییر را شرح می‌دهد، نه اینکه فقط بگوید Lint این‌طور می‌گوید.

این پاسخ به مهارتی که استفاده کرده است ارجاع می‌دهد.

پیکربندی ساخت را می‌خواند، حداقل کیت توسعه نرم‌افزار ۲۶ را می‌بیند، و ContextCompat را انتخاب می‌کند تا اصلاحیه کار کند، و تفاوت را به شما می‌دهد تا بتوانید آن را اعمال کنید.

این همان هشداری است که با آن شروع کردیم، اما اکنون با یک راه‌حل پیشنهادی و استدلال اضافه شده است.

بنابراین، مهارت‌های قبلی اشکالات امنیتی را شناسایی می‌کنند.

اکنون بیایید درباره حوزه دیگری صحبت کنیم، یعنی رعایت خط‌مشی برنامه.

برای مثال، فرض کنید توسعه‌دهنده برنامه جدیدی هستید که می‌خواهید برنامه‌تان را در «فروشگاه Play» راه‌اندازی کنید.

تکمیل فرم ایمنی داده گام مهمی در راه‌اندازی برنامه‌تان است، بنابراین بیایید از هر ابزاری که می‌توانیم استفاده کنیم تا مطمئن شویم قبل‌از ارسال برنامه، آن را به‌درستی انجام می‌دهیم.

مهارت خط‌مشی Play تجزیه‌وتحلیل ایستا روی پایگاه کد شما انجام می‌دهد.

اگر برنامه موجودی را در «فروشگاه Play» منتشر می‌کنید، این ابزار می‌تواند آن تحلیل کد ایستا را با اظهارنامه‌های «فروشگاه Play» نیز ارجاع متقابل دهد.

اجرای این مهارت می‌تواند به شما کمک کند مشکلات احتمالی خط‌مشی Play را قبل‌از ارسال برنامه (نه بعداز آن) شناسایی کنید و به تسریع فرایند ارسال کمک می‌کند.

گردش کار مشابه مهارت‌های دیگری است که درباره آن‌ها صحبت کردیم: آن را وارد کنید و سپس بپرسید: «این برنامه را قبل‌از ارسال برای مطابقت با خط‌مشی Google Play ممیزی کن.»

در سمت چپ، نماگرفتی از گزارش نمونه و در پایین، فرمان‌های Android CLI برای نصب آن را خواهید دید.

android skills list
android skills add play-policy-insights

بنابراین، هر آنچه تاکنون درباره آن صحبت کرده‌ایم قبل‌از ارسال اتفاق می‌افتد: ممیزی اهداف، بررسی اجازه‌ها، اعتبارسنجی مطابقت.

این امنیت زمان ساخت است و ضروری است.

اما دسته کاملی از تهدیدها وجود دارد که فقط زمانی وجود دارند که APK شما در جهان منتشر شده باشد و روی دستگاه‌هایی اجرا شود که ممکن است شما آن‌ها را کنترل نکنید.

Play Integrity API در زمان اجرا به سه سؤال پاسخ می‌دهد که کد شما نمی‌تواند درباره خودش پاسخ دهد: آیا این ساخت اصلی و تغییرنیافته برنامه شما است؟

آیا این برنامه در دستگاه Android واقعی اجرا می‌شود؟

و آیا این حساب کاربری Play است؟

بنابراین، می‌توانید از Play Integrity API برای برگرداندن حکم درباره تمامیت برنامه، تمامیت دستگاه، و موارد دیگر استفاده کنید.

علاوه‌بر اینکه انتشار ایمن‌تر برنامه‌تان را سریع‌تر و آسان‌تر می‌کنیم، ایمن کردن درآمد و اعتبار برنامه‌تان را نیز آسان‌تر می‌کنیم.

بنابراین، از کسب‌وکارتان دربرابر کلاهبرداری و سوءاستفاده دفاع کنید.

داشبورد جدید «محافظت‌شده با Play» که در اینجا می‌بینید به شما کمک می‌کند دفاع‌های تمامیت، توزیع، و درآمدزایی‌تان را در یک جا پایش و پیکربندی کنید.

همچنین تأخیر آماده‌سازی را برای Play Integrity API کاهش می‌دهیم تا بتوانید از این بررسی‌ها درطول مسیرهای قطعی کاربر که سرعت در آن‌ها حیاتی است استفاده کنید و تهدیدها و دستگاه‌های پرخطر را سریع‌تر مسدود کنید.

خب، ما به‌تازگی درباره ویژگی‌ها و ابزارهای Android برای کمک به حفظ ایمنی برنامه‌ها صحبت کردیم، اما درباره کاربران شما چطور؟

بیایید ابتدا نگاهی به «محافظت از گذرواژه یک‌بارمصرف پیامکی» بیندازیم.

فرض کنید می‌خواهید درستی‌سنجی کاربر مبتنی بر پیامک را برای برنامه‌تان پیاده‌سازی کنید و کدهای درستی‌سنجی ارسال کنید.

اجازه پیامک به برنامه امکان می‌دهد به داده‌های پیام‌رسانی، ازجمله داده‌های حساس مثل گذرواژه‌های یک‌بارمصرف، دسترسی داشته باشد.

بنابراین، چند میانای برنامه‌سازی کاربردی در برنامه‌تان معرفی کرده‌ایم تا بتوانید آن را پیاده‌سازی کنید، بنابراین نیازی نیست اجازه‌های گسترده پیامک را درخواست کنید، اما همچنان می‌توانید کدهای گذرواژه یک‌بارمصرف پیامکی را برای درستی‌سنجی دریافت کنید.

‫SMS Retriever API به برنامه شما اجازه می‌دهد گذرواژه‌های یک‌بارمصرف را به‌طور خودکار و بدون اجازه‌های گسترده پیامک به‌تأیید برساند.

یک درهم‌ساز ۱۱ نویسه‌ای را که برنامه‌تان را شناسایی می‌کند به پیام اضافه می‌کنید و سیستم فقط همان یک پیام را به شما می‌دهد.

و اگر نمی‌توانید قالب پیام را کنترل کنید، از SMS User Consent API استفاده کنید.

سیستم یک پیام‌واره یک‌باره نشان می‌دهد.

کاربر روی «اجازه دادن» یا «رد کردن» تک‌ضرب می‌زند و اگر اجازه دهد، آن پیام را دریافت می‌کنید.

هنوز نیازی به اجازه گسترده پیامک نیست.

برخی‌از برنامه‌ها ممکن است برای تکمیل کردن کارها فقط یک‌بار به مکان دقیق نیاز داشته باشند.

اجازه دسترسی یک‌باره موجود اصطکاک زیادی برای کاربر ایجاد می‌کند، بنابراین توسعه‌دهندگان گاهی به‌جای آن اجازه دسترسی دقیق گسترده‌تری درخواست می‌کنند.

بنابراین، «دکمه مکان» ابزاری است که روشی آسان برای اعطای دسترسی یک‌باره به مکان دقیق به برنامه ارائه می‌دهد.

این یک عنصر میانای کاربر Android است که توسعه‌دهندگان برنامه می‌توانند آن را سفارشی‌سازی و جاسازی کنند.

اولین نسخه از کتابخانه آلفای Location Button 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)
}

و سپس، می‌توانید با ثبت کردن فراخوان برگشتی، به تغییرات زمان اجرا گوش دهید.

امروز موضوعات زیادی را بررسی کردیم.

بنابراین، در اینجا پیوندهای سریع و اگر دوست دارید درباره آن‌ها بیشتر بدانید، آورده شده است.

در اینجا کمی مکث می‌کنیم تا بتوانید نشانی‌های وب موردنیازتان را یادداشت کنید.

متشکریم.

متشکریم.