نویسنده: رضا فروزان
وب‌سایت: https://01st.ir
سطح آموزش: مقدماتی تا متوسط
نوع آموزش: تئوری، آزمایشگاهی و عملی
پیش‌نیازها: آشنایی مقدماتی با کامپیوتر، نصب نرم‌افزار و دستورات سادهٔ ترمینال

مقدمه: آیا واقعاً می‌توان امنیت اندروید را آزمایش کرد؟

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

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

در این آموزش قرار نیست صرفاً چند ابزار معرفی کنیم. هدف این است که یاد بگیریم یک متخصص امنیت چگونه یک محیط اندرویدی را بررسی می‌کند، شواهد فنی جمع‌آوری می‌کند، نقاط ضعف را تشخیص می‌دهد و برای رفع آن‌ها راهکار ارائه می‌دهد.

تفاوت مهم: تست نفوذ اندروید با هک غیرمجاز گوشی دیگران یکسان نیست. در تست نفوذ حرفه‌ای، محدودهٔ آزمایش مشخص است، مجوز لازم وجود دارد و هر یافته باید مستند و قابل بازبینی باشد.

فصل اول: شناخت معماری امنیتی اندروید

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

۱.۱. هستهٔ لینوکس

اندروید بر پایهٔ هستهٔ لینوکس ساخته شده است. هسته وظایفی مانند مدیریت حافظه، پردازش‌ها، دسترسی به منابع سخت‌افزاری و کنترل بخش مهمی از مجوزهای سطح سیستم را بر عهده دارد.

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

۱.۲. Android Application Sandbox

هر اپلیکیشن در یک محیط ایزوله اجرا می‌شود. برای مثال، یک برنامهٔ یادداشت‌برداری نباید بتواند صرفاً به دلیل نصب‌شدن روی گوشی، فایل‌های خصوصی برنامهٔ بانکی را بخواند.

این جداسازی به‌تنهایی امنیت کامل را تضمین نمی‌کند؛ برنامه ممکن است اطلاعات حساس را در محل نامناسب ذخیره کند، مجوزهای غیرضروری درخواست دهد یا از یک مؤلفهٔ آسیب‌پذیر استفاده کند.

۱.۳. مجوزهای اپلیکیشن

مجوزها تعیین می‌کنند برنامه تحت شرایط مشخص به چه قابلیت‌هایی دسترسی داشته باشد؛ برای نمونه:

• دوربین برای ثبت تصویر
• میکروفون برای ضبط صدا
• موقعیت مکانی برای تعیین محل کاربر
• مخاطبان برای دسترسی به دفترچهٔ تلفن
• اعلان‌ها و قابلیت‌های ویژهٔ سیستم

وجود یک مجوز به‌تنهایی به معنای آسیب‌پذیری نیست. باید بررسی کرد که آیا مجوز واقعاً برای عملکرد برنامه ضروری است و آیا داده‌های حاصل از آن به شکل ایمن مدیریت می‌شوند.

۱.۴. فایل APK چیست؟

APK بستهٔ نصب یک اپلیکیشن اندرویدی است. این فایل ممکن است شامل موارد زیر باشد:

• فایل AndroidManifest.xml
• کد کامپایل‌شده در قالب DEX
• منابع گرافیکی و متنی
• کتابخانه‌های بومی
• اطلاعات امضا و ساخت برنامه

در ارزیابی امنیت، بررسی APK می‌تواند اطلاعات ارزشمندی دربارهٔ مجوزها، مؤلفه‌های برنامه، پیکربندی شبکه و نحوهٔ نگهداری اطلاعات ارائه کند.

۱.۵. روت‌بودن دستگاه چه اهمیتی دارد؟

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

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

فصل دوم: ساخت آزمایشگاه امن تست نفوذ اندروید

برای انجام تمرین‌ها به یک کامپیوتر، یک محیط اندرویدی آزمایشی و چند ابزار تحلیل نیاز داریم.

۲.۱. ابزارهای موردنیاز

ابزار	کاربرد
Android Studio	ساخت و اجرای شبیه‌ساز اندروید
Android SDK Platform-Tools	ارتباط با دستگاه از طریق ADB
JADX	مشاهدهٔ ساختار و کد بازسازی‌شدهٔ APK
MobSF	تحلیل امنیتی ایستا و پویا با توجه به تنظیمات آزمایشگاه
Docker	اجرای ساده‌تر برخی ابزارهای تحلیل
Git	دریافت و مدیریت کد پروژه‌های آزمایشی

نکته: JADX کد منبع اصلی را به‌صورت کامل بازیابی نمی‌کند؛ خروجی آن کدی بازسازی‌شده است که ممکن است نام‌ها یا ساختارهای آن تغییر کرده باشند.

۲.۲. نصب Android Studio

۱. Android Studio را از وب‌سایت رسمی توسعه‌دهندگان اندروید دریافت کنید.

۲. نصب را انجام دهید و در بخش SDK Manager، ابزارهای Android SDK و Platform-Tools را نصب کنید.

۳. از بخش Device Manager یک دستگاه مجازی بسازید.

۴. یک تصویر سیستم‌عامل اندروید متناسب با شبیه‌ساز انتخاب کنید.

۵. شبیه‌ساز را اجرا کنید و منتظر بمانید صفحهٔ اصلی اندروید ظاهر شود.

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

۲.۳. اتصال به شبیه‌ساز با ADB

ADB مخفف Android Debug Bridge است. این ابزار به توسعه‌دهندگان و متخصصان امنیت اجازه می‌دهد در محیط مجاز، اطلاعات تشخیصی دستگاه را بررسی کنند.

ترمینال ویندوز یا ترمینال سیستم خود را باز کنید و دستور زیر را اجرا کنید:

adb devices

اگر شبیه‌ساز به‌درستی اجرا شده باشد، معمولاً شناسه‌ای از آن همراه با وضعیت device نمایش داده می‌شود.

اگر هیچ دستگاهی نمایش داده نشد:

• بررسی کنید شبیه‌ساز کاملاً راه‌اندازی شده باشد.
• مطمئن شوید Platform-Tools نصب شده است.
• در صورت نیاز، مسیر پوشهٔ platform-tools را به متغیر PATH اضافه کنید.

در مرحلهٔ بعد، نسخه و مشخصات عمومی اندروید را بررسی کنید:

adb shell getprop ro.build.version.release

برای مشاهدهٔ سطح API سیستم:

adb shell getprop ro.build.version.sdk

و برای مشاهدهٔ مشخصات مدل گزارش‌شده توسط دستگاه:

adb shell getprop ro.product.model

تمرین شمارهٔ ۱: خروجی سه دستور بالا را ثبت کنید و در گزارش خود بنویسید که هرکدام چه اطلاعاتی در اختیار شما قرار می‌دهد. این اطلاعات برای شناسایی محیط آزمایش ضروری‌اند، اما به‌تنهایی وجود یا نبود آسیب‌پذیری را ثابت نمی‌کنند.

فصل سوم: آشنایی عملی با ADB و بررسی دستگاه

در این فصل یاد می‌گیریم اطلاعات پایهٔ دستگاه آزمایشگاهی خود را جمع‌آوری کنیم.

۳.۱. بررسی نسخهٔ سیستم‌عامل

adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.sdk

شمارهٔ نسخه و سطح API را یادداشت کنید. سپس بررسی کنید که آیا نسخهٔ مورد استفاده هنوز به‌روزرسانی امنیتی دریافت می‌کند یا خیر. صرفاً جدیدبودن شمارهٔ نسخه تضمین نمی‌کند تمام اصلاحات امنیتی نصب شده‌اند.

۳.۲. فهرست برنامه‌های نصب‌شده

برای مشاهدهٔ بسته‌های برنامه‌ها:

adb shell pm list packages

برای نمایش بسته‌های برنامه‌های نصب‌شده توسط کاربر:

adb shell pm list packages -3

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

۳.۳. مشاهدهٔ اطلاعات یک اپلیکیشن مشخص

پس از نصب یک اپلیکیشن آزمایشی، نام بستهٔ آن را پیدا کنید. برای مثال، اگر نام بستهٔ برنامه com.example.lab باشد:

adb shell dumpsys package com.example.lab

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

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

adb help

۳.۴. ثبت شواهد

در یک ارزیابی حرفه‌ای، فقط اجرای دستور کافی نیست. باید مشخص باشد:

• چه زمانی آزمایش انجام شده است؟
• کدام دستگاه یا شبیه‌ساز بررسی شده است؟
• چه دستوری اجرا شده است؟
• خروجی چه بوده است؟
• این خروجی چه چیزی را ثابت می‌کند و چه چیزی را ثابت نمی‌کند؟

تمرین شمارهٔ ۲: یک گزارش کوتاه تهیه کنید که در آن نسخهٔ اندروید، سطح API، تعداد بسته‌های نمایش‌داده‌شده و نام بستهٔ اپلیکیشن آزمایشی ثبت شده باشد. اطلاعات شخصی یا شناسه‌های حساس را در گزارش عمومی منتشر نکنید.

فصل چهارم: تحلیل امنیتی اپلیکیشن اندروید

بخش بزرگی از مشکلات امنیتی موبایل به نحوهٔ طراحی و پیاده‌سازی اپلیکیشن‌ها مربوط می‌شود. در این مرحله، یک APK آزمایشی را از نظر ساختار و پیکربندی بررسی می‌کنیم.

۴.۱. بررسی APK با JADX

JADX ابزاری برای تبدیل کد DEX به نمایی قابل‌خواندن از کد است. نسخهٔ مناسب سیستم‌عامل خود را از مخزن رسمی پروژه دریافت کنید.

پس از اجرا، APK آزمایشی را در JADX باز کنید.

بخش‌های مهم برای بررسی:

۱. AndroidManifest.xml

۲. نام بسته و اطلاعات نسخه

۳. مجوزهای اعلام‌شده

۴. Activityها، Serviceها و Receiverها

۵. تنظیمات ارتباط شبکه

۶. محل استفاده از اطلاعات حساس در کد

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

۴.۲. بررسی AndroidManifest.xml

فایل Manifest مشخص می‌کند اپلیکیشن چه مؤلفه‌هایی دارد و چه قابلیت‌ها و تنظیماتی را اعلام کرده است.

مواردی که باید بررسی شوند:

• آیا برنامه مجوزهایی بیش از نیاز واقعی خود درخواست می‌کند؟
• آیا مؤلفه‌ای بدون ضرورت در دسترس برنامه‌های دیگر قرار گرفته است؟
• آیا Activity یا Service حساسی به‌درستی محافظت شده است؟
• آیا پیکربندی شبکه با نیازهای واقعی برنامه تناسب دارد؟
• آیا نسخهٔ هدف اندروید و تنظیمات امنیتی با الزامات روز سازگارند؟

یکی از موارد مهم، ویژگی android:exported است. اگر یک مؤلفه Export شده باشد، ممکن است از بیرون برنامه نیز قابل فراخوانی باشد؛ البته دسترسی واقعی به نوع مؤلفه، مجوزها، فیلترهای Intent و نسخهٔ سیستم‌عامل بستگی دارد.

Export بودن به‌خودی‌خود به معنای آسیب‌پذیری نیست. مسئله زمانی جدی می‌شود که یک مؤلفهٔ حساس بدون کنترل دسترسی مناسب، عملیات غیرمجاز انجام دهد.

۴.۳. بررسی مجوزهای خطرناک

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

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

تمرین شمارهٔ ۳: یک اپلیکیشن آزمایشی را در JADX باز کنید و فهرست مجوزهای آن را استخراج کنید. در یک جدول سه ستون ایجاد کنید: نام مجوز، کاربرد مورد انتظار و ارزیابی شما از ضرورت آن. هیچ مجوزی را در دستگاه یا برنامهٔ دیگران بدون مجوز تغییر ندهید.

فصل پنجم: تحلیل خودکار با MobSF

MobSF یا Mobile Security Framework ابزاری برای کمک به تحلیل امنیتی اپلیکیشن‌های موبایل است. این ابزار می‌تواند بررسی‌های ایستا و در محیط مناسب، بررسی‌های پویا انجام دهد.

۵.۱. اجرای آزمایشگاه با Docker

اگر Docker روی کامپیوتر نصب است، می‌توانید از دستور زیر برای اجرای نسخهٔ کانتینری MobSF استفاده کنید:

docker run --rm -it \
  -p 127.0.0.1:8000:8000 \
  opensecurity/mobile-security-framework-mobsf:latest

این دستور نمونه برای محیطی است که Docker و دریافت تصویر کانتینر در آن به‌درستی پیکربندی شده‌اند. ممکن است بسته به نسخهٔ ابزار و سیستم‌عامل به تنظیمات متفاوتی نیاز باشد.

اتصال پورت به آدرس محلی 127.0.0.1 دسترسی مستقیم از شبکهٔ بیرونی را محدود می‌کند. برای استفادهٔ واقعی، راهنمای نسخهٔ جاری MobSF را مطالعه کنید و از قراردادن سرویس تحلیل بدون محافظت روی اینترنت خودداری کنید.

۵.۲. اجرای تحلیل

۱. محیط MobSF را در مرورگر محلی باز کنید.

۲. APK متعلق به خودتان یا یک برنامهٔ آزمایشگاهی دارای مجوز را انتخاب کنید.

۳. فایل را برای تحلیل ارسال کنید.

۴. منتظر بمانید گزارش تولید شود.

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

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

۵.۳. تفسیر گزارش

نتایج را به سه گروه تقسیم کنید:

• یافتهٔ تأییدشده: شواهد کافی برای اثبات یک ضعف مشخص وجود دارد.
• یافتهٔ نیازمند بررسی: ابزار یک الگوی مشکوک شناسایی کرده، اما تأیید دستی لازم است.
• هشدار اطلاعاتی: موردی برای آگاهی یا بازبینی گزارش شده که لزوماً آسیب‌پذیری نیست.

برای مثال، اگر ابزار دربارهٔ ارتباط HTTP هشدار بدهد، باید بررسی کنید آیا اطلاعات حساس واقعاً از طریق آن ارسال می‌شوند، آیا ارتباط فقط در محیط آزمایشگاهی است و چه کنترل‌هایی اعمال شده‌اند.

تمرین شمارهٔ ۴: یک APK آزمایشی را تحلیل کنید و سه یافتهٔ مهم گزارش را ثبت کنید. برای هر یافته، شواهد، اثر احتمالی، سطح اطمینان و پیشنهاد اصلاحی را بنویسید. صرفاً برچسب خطر ابزار را کپی نکنید.

فصل ششم: آزمایش عملی آسیب‌پذیری‌های رایج اندروید

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

۶.۱. سناریوی اول: ذخیره‌سازی ناامن اطلاعات

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

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

روش آزمایش:

۱. یک اپلیکیشن آزمایشگاهی را اجرا کنید.

۲. با یک حساب آزمایشی، اطلاعات ساختگی وارد کنید.

۳. مستندات و کد برنامه را بررسی کنید تا محل ذخیره‌سازی داده مشخص شود.

۴. با ابزارهای مجاز محیط توسعه، رفتار ذخیره‌سازی را مشاهده کنید.

۵. بررسی کنید آیا اطلاعات حساس بدون نیاز ذخیره می‌شوند یا در گزارش‌های تشخیصی ظاهر می‌شوند.

۶. نتیجه را ثبت و یک راهکار اصلاحی پیشنهاد کنید.

در اندروید، فضای خصوصی اپلیکیشن و سازوکارهای استاندارد ذخیره‌سازی معمولاً نقطهٔ شروع مناسبی هستند. رمزنگاری نیز باید با مدیریت صحیح کلید همراه باشد؛ رمزکردن داده با کلید ثابت و قرارگرفته در کد منبع، لزوماً حفاظت مؤثری ایجاد نمی‌کند.

۶.۲. سناریوی دوم: ارتباط ناامن شبکه

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

روش آزمایش:

۱. یک سرور آزمایشی تحت کنترل خود راه‌اندازی کنید.

۲. از اپلیکیشن آزمایشی بخواهید به همان سرور متصل شود.

۳. پیکربندی امنیت شبکهٔ برنامه را در کد و Manifest بررسی کنید.

۴. با ابزار تحلیل شبکه، فقط ترافیک محیط آزمایشی را مشاهده کنید.

۵. بررسی کنید آیا اطلاعات حساس از طریق اتصال امن منتقل می‌شوند و آیا اعتبارسنجی گواهی به‌درستی انجام می‌شود.

۶. در گزارش، نوع داده، مقصد ارتباط و شواهد مربوط به رمزنگاری را ثبت کنید.

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

۶.۳. سناریوی سوم: مؤلفه‌های قابل‌دسترسی از بیرون برنامه

Activityها، Serviceها و Broadcast Receiverها می‌توانند نقاط ورود مهمی برای بررسی امنیتی باشند.

روش آزمایش:

۱. Manifest اپلیکیشن آزمایشی را بررسی کنید.

۲. مؤلفه‌های Export شده را شناسایی کنید.

۳. مشخص کنید هر مؤلفه چه عملیاتی انجام می‌دهد.

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

۵. در محیط توسعه، سناریوهای مجاز فراخوانی و کنترل دسترسی را آزمایش کنید.

۶. نتایج را همراه با نسخهٔ برنامه و شواهد ثبت کنید.

وجود یک مؤلفهٔ Export شده به معنای وجود راه نفوذ نیست. یک مؤلفه ممکن است عمداً برای ارتباط با برنامه‌های دیگر منتشر شده باشد؛ مهم این است که آیا عملیات آن به شکل ایمن محافظت می‌شود.

۶.۴. سناریوی چهارم: افشای اطلاعات در Logها

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

روش آزمایش:

۱. یک اپلیکیشن آزمایشی را اجرا کنید.

۲. با حساب آزمایشی و اطلاعات ساختگی، چند عملیات عادی انجام دهید.

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

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

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

برای مشاهدهٔ گزارش‌های دستگاه آزمایشی می‌توان از دستور زیر استفاده کرد:

adb logcat

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

راهکار اصلاحی معمولاً حذف ثبت داده‌های حساس، کاهش سطح جزئیات گزارش‌ها در نسخهٔ انتشار و بازبینی مسیرهای خطای برنامه است.

۶.۵. سناریوی پنجم: ارزیابی احراز هویت و نشست

در اپلیکیشن‌های موبایل، کنترل دسترسی نباید صرفاً به ظاهر رابط کاربری وابسته باشد.

روش آزمایش:

۱. دو حساب آزمایشی مستقل ایجاد کنید.

۲. با هر حساب داده‌های مجزایی ثبت کنید.

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

۴. تلاش‌های مجاز و نامجاز را در محیط آزمایشی مقایسه کنید.

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

۶. نتایج را با شناسه‌های ساختگی و بدون افشای اطلاعات واقعی ثبت کنید.

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

فصل هفتم: تمرین پروژه‌محور در آزمایشگاه

اکنون باید آموخته‌ها را در یک پروژهٔ مشخص به کار ببریم.

پروژه: ارزیابی امنیت یک اپلیکیشن اندرویدی آزمایشی

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

مراحل اجرا:

۱. شبیه‌ساز اندروید را راه‌اندازی کنید.

۲. یک اپلیکیشن آزمایشی با مجوز استفاده انتخاب کنید.

۳. اطلاعات اولیهٔ برنامه را با ADB ثبت کنید.

۴. APK را با JADX بررسی کنید.

۵. تحلیل ایستا را با MobSF انجام دهید.

۶. مجوزها، مؤلفه‌ها و تنظیمات شبکه را ارزیابی کنید.

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

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

۹. برای هر مورد، راهکار اصلاحی پیشنهاد دهید.

۱۰. یک گزارش نهایی تهیه کنید.

قالب گزارش نهایی

بخش	محتوای موردنیاز
مشخصات آزمایشگاه	نسخهٔ اندروید، سطح API و نسخهٔ برنامه
محدودهٔ آزمایش	اپلیکیشن و قابلیت‌های مجاز
یافته	شرح دقیق مشکل احتمالی یا تأییدشده
شواهد	خروجی ابزار، تنظیمات یا مراحل بازتولید
اثر امنیتی	داده یا قابلیتی که ممکن است تحت تأثیر قرار گیرد
شدت	ارزیابی متناسب با اثر و شرایط واقعی
راهکار	اقدام مشخص برای رفع مشکل
آزمون مجدد	روش تأیید اصلاح پس از تغییر

معیار موفقیت پروژه

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

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

فصل هشتم: چگونه آسیب‌پذیری را اصلاح کنیم؟

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

توصیه‌های امنیتی برای توسعه‌دهندگان اندروید

• از فضای خصوصی اپلیکیشن برای نگهداری داده‌های داخلی استفاده کنید.
• داده‌های حساس را غیرضروری ذخیره نکنید.
• کلیدهای رمزنگاری را در کد منبع قرار ندهید.
• برای ارتباطات شبکه از TLS و اعتبارسنجی صحیح گواهی استفاده کنید.
• مؤلفه‌های Export شده را فقط در صورت نیاز در دسترس قرار دهید.
• برای عملیات حساس، کنترل دسترسی مناسب پیاده‌سازی کنید.
• رمز عبور و توکن نشست را در Logها ثبت نکنید.
• مجوزهای برنامه را به حداقل نیاز عملکردی محدود کنید.
• کتابخانه‌ها و وابستگی‌های نرم‌افزاری را به‌روزرسانی کنید.
• پس از هر اصلاح، آزمایش را تکرار کنید تا مشخص شود مشکل واقعاً برطرف شده است.

فصل نهم: مسیر پیشرفت برای تبدیل‌شدن به متخصص امنیت اندروید

پس از تسلط بر این تمرین‌ها، مسیر یادگیری را به شکل زیر ادامه دهید:

مرحلهٔ اول — مبانی: لینوکس، شبکه، معماری اندروید، مجوزها و ADB.

مرحلهٔ دوم — تحلیل اپلیکیشن: ساختار APK، Manifest، JADX و تحلیل ایستا.

مرحلهٔ سوم — آزمایش پویا: شبیه‌ساز، مشاهدهٔ رفتار برنامه، گزارش‌های تشخیصی و تحلیل ارتباطات آزمایشگاهی.

مرحلهٔ چهارم — توسعهٔ امن: یادگیری Kotlin، مدل مجوزهای اندروید، مدیریت نشست و ذخیره‌سازی امن.

مرحلهٔ پنجم — گزارش‌نویسی حرفه‌ای: ارزیابی ریسک، مستندسازی شواهد، ارائهٔ راهکار و آزمون مجدد.

برای ادامهٔ مطالعه، مستندات رسمی توسعه‌دهندگان اندروید و منابع OWASP Mobile Application Security را دنبال کنید.

جمع‌بندی

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

در این آموزش، مسیر ساخت آزمایشگاه، استفاده از ADB، تحلیل APK، کار با MobSF و بررسی چند دسته از مشکلات رایج امنیتی را مرور کردیم.

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