موبائل ڈیولپمنٹ میں سیکیورٹی: یہ کیا ہے، کیا خطرات ہیں اور کیسے دفاع کریں

اہم خطرات: OWASP Mobile Top 10

OWASP Mobile Top 10 کیا ہے؟

OWASP (Open Web Application Security Project) ایک غیر منافع بخش تنظیم ہے جو موبائل سیکیورٹی کی سب سے خطرناک کمزوریوں کی درجہ بندی شائع کرتی ہے۔ OWASP Mobile Top 10 ایک فہرست ہے جو ڈویلپرز کو یہ سمجھنے میں مدد دیتی ہے کہ پہلے کس چیز پر توجہ مرکوز کرنی ہے۔ 2024 کے ورژن میں، غیر محفوظ ذخیرہ، کمزور تصدیق اور غیر محفوظ نیٹ ورک کمیونیکیشن سے متعلق مسائل درجہ بندی میں سرفہرست ہیں۔

M1: غیر محفوظ ڈیٹا اسٹوریج — سب سے عام مسئلہ: پاس ورڈز، ٹوکنز اور ذاتی ڈیٹا بغیر انکرپشن کے SharedPreferences، NSUserDefaults یا مقامی فائلوں میں رہ جاتے ہیں۔ M2: کمزور تصدیق — سرور سائیڈ تصدیق کی کمی، کمزور پاس ورڈز۔ M3: غیر محفوظ نیٹ ورک کمیونیکیشن — HTTPS کی کمی یا غلط SSL سرٹیفکیٹ تصدیق۔ M4 اور M5 کا تعلق کرپٹوگرافی اور غلط API استعمال سے ہے۔

M6: غیر محفوظ اختیار — ایک صارف درخواست میں ID بدل کر دوسرے صارف کے ڈیٹا تک رسائی حاصل کر سکتا ہے۔ M7: کوڈ انجیکشن (SQL Injection, XSS)۔ M8: ایپ ہیرا پھیری — ری پیکیجنگ، کوڈ تبدیلی۔ M9 اور M10 — تیسرے فریق کی لائبریریوں کے ذریعے ڈیٹا لیک اور ریورس انجینئرنگ۔ ان میں سے ہر خطرے کے لیے ثابت شدہ جوابی اقدامات موجود ہیں، اور IT Sectr میں ہم 2017 سے تمام پروجیکٹس میں ان کا اطلاق کر رہے ہیں۔

Man-in-the-Middle (MITM) حملے

MITM حملہ اس وقت ہوتا ہے جب حملہ آور ایپلیکیشن اور سرور کے درمیان ٹریفک کو روکتا ہے۔ یہ DNS spoofing، ARP spoofing یا غیر محفوظ Wi-Fi نیٹ ورک سے منسلک ہو کر ممکن ہے۔ تحفظ کے لیے SSL/TLS سرٹیفکیٹ اور Certificate Pinning استعمال کیا جاتا ہے۔

Certificate Pinning ایک طریقہ کار ہے جس میں ایپلیکیشن تصدیق کرتی ہے کہ سرور کا سرٹیفکیٹ ایپلیکیشن کوڈ میں پہلے سے محفوظ کردہ سرٹیفکیٹ سے ملتا ہے۔ چاہے حملہ آور پراکسی (مثلاً Burp Suite) کے ذریعے سرٹیفکیٹ بدل دے، ایپلیکیشن کنکشن مسترد کر دے گی۔ Pinning دو قسم کا ہوتا ہے: Public Key Pinning اور Certificate Hash Pinning۔

انکرپشن اور ہیشنگ: AES, RSA, SSL/TLS

ہم آہنگ انکرپشن: AES

AES (Advanced Encryption Standard) ایک ہم آہنگ انکرپشن الگورتھم ہے، جو ڈیوائس پر ڈیٹا سیکیورٹی کی بنیاد ہے۔ AES ڈیٹا کو انکرپٹ اور ڈیکرپٹ کرنے کے لیے ایک ہی کلید استعمال کرتا ہے۔ AES 128، 192 یا 256 بٹ کی کلیدوں کو سپورٹ کرتا ہے۔ موبائل ڈیولپمنٹ میں، AES-256 ڈیوائس پر ڈیٹا (فائلیں، کیش، مقامی ڈیٹابیس میں ریکارڈ) کو انکرپٹ کرنے کے لیے استعمال ہوتا ہے۔

AES موڈز: GCM (تجویز کردہ) — ڈیٹا کی تصدیق فراہم کرتا ہے، CBC — بلاک چیننگ کے ساتھ بنیادی موڈ، ECB — غیر محفوظ، اسے استعمال نہ کریں۔ iOS کے لیے، AES CommonCrypto (CCOptions) کے ذریعے دستیاب ہے، Android کے لیے — Java Cryptography Architecture (JCA) میں Cipher کے ذریعے۔ اہم: انکرپشن کلید کبھی بھی ایپلیکیشن کوڈ میں محفوظ نہیں ہونی چاہیے — Keychain/Keystore استعمال کریں۔

غیر ہم آہنگ انکرپشن: RSA — کلیدوں کا ایک جوڑا (عوامی اور نجی) استعمال کرتا ہے۔ RSA ڈیٹا کی چھوٹی مقدار کو انکرپٹ کرنے کے لیے استعمال ہوتا ہے — عام طور پر کلائنٹ اور سرور کے درمیان ہم آہنگ کلید کے تبادلے کے لیے۔ کم از کم RSA کلید کی لمبائی 2048 بٹ ہے (4096 تجویز کردہ)۔ iOS پر، RSA Security Framework (SecKeyCreateRandomKey) کے ذریعے دستیاب ہے، Android پر — Android Keystore میں KeyPairGenerator کے ذریعے۔

ہیشنگ اور SSL/TLS

ہیشنگ (SHA-256, SHA-3) ڈیٹا کا ایک مقررہ لمبائی کی سٹرنگ میں ناقابل واپسی تبدیلی ہے۔ ہیشز ڈیٹا کی سالمیت کی تصدیق اور پاس ورڈز ذخیرہ کرنے کے لیے استعمال ہوتی ہیں۔ پاس ورڈز کے لیے، bcrypt، scrypt یا Argon2 استعمال کرنا یقینی بنائیں — سادہ SHA-256 رینبو ٹیبل حملوں کے لیے خطرناک ہے۔ SSL/TLS کلائنٹ اور سرور کے درمیان نیٹ ورک ٹریفک کو انکرپٹ کرنے کا ایک پروٹوکول ہے۔ جدید معیار TLS 1.3 ہے، جو Perfect Forward Secrecy (PFS) فراہم کرتا ہے۔

TLS 1.3 اپنے پیشروؤں سے تیز ہے: ہینڈ شیک دو کے بجائے ایک راؤنڈ ٹرپ لیتا ہے۔ Android پر، کم از کم TLS ورژن SSLSocket کے ذریعے کنفیگر کیا جاتا ہے، iOS پر — ATS (App Transport Security) کے ذریعے، جو ڈیفالٹ طور پر TLS 1.2 یا اس سے اوپر کی ضرورت ہے۔ ATS کو صرف مخصوص ڈومینز کے لیے جواز کے ساتھ غیر فعال کیا جا سکتا ہے۔

محفوظ ذخیرہ: Keychain اور Keystore

iOS: Keychain

Keychain (کیچین) iOS / macOS میں پاس ورڈز، انکرپشن کلیدوں، سرٹیفکیٹس اور ٹوکنز کے لیے ایک محفوظ ذخیرہ ہے۔ Keychain میں ڈیٹا ہر ڈیوائس کے لیے منفرد ہارڈویئر کلید سے انکرپٹ ہوتا ہے۔ Keychain تک رسائی Security Framework (SecItemAdd, SecItemCopyMatching) کے ذریعے کنٹرول کی جاتی ہے۔ ڈیوائس لاک ہونے پر Keychain خود بخود لاک ہو جاتا ہے اور Secure Enclave کا استعمال کرتے ہوئے انکرپٹ ہوتا ہے۔

Android: Keystore

Android Keystore کرپٹوگرافک کلیدوں کے لیے ایک سسٹم اسٹوریج ہے، جو ایپلیکیشن سے الگ ہے۔ Android 6.0 (API 23) سے شروع ہو کر، Keystore سیکیورٹی چپ والے آلات پر ہارڈویئر سپورٹ (TEE — Trusted Execution Environment) استعمال کرتا ہے۔ Keystore میں کلیدیں کبھی بھی محفوظ علاقہ نہیں چھوڑتیں — ایپلیکیشن کو صرف انکرپشن اور دستخطی کارروائیوں کے لیے ایک ہینڈل ملتا ہے۔

SharedPreferences اور NSUserDefaults حساس ڈیٹا ذخیرہ کرنے کے لیے ڈیزائن نہیں کیے گئے ہیں — یہ سادہ متن میں معلومات ذخیرہ کرتے ہیں۔ ڈیٹا کے تحفظ کے لیے، EncryptedSharedPreferences (Android) استعمال کریں یا UserDefaults (iOS) میں محفوظ کرنے سے پہلے ڈیٹا کو انکرپٹ کریں۔ IT Sectr میں، ہم ہمیشہ رسائی ٹوکنز اور پاس ورڈز کے لیے Keychain اور Keystore استعمال کرتے ہیں۔

تصدیق: OAuth 2.0, JWT اور بایومیٹرکس

OAuth 2.0 اور OpenID Connect

OAuth 2.0 ایک تفویض کردہ اجازت پروٹوکول ہے جو پاس ورڈ منتقل کیے بغیر صارف کے وسائل تک محفوظ رسائی فراہم کرتا ہے۔ موبائل ایپلیکیشنز میں، سب سے زیادہ استعمال PKCE (Proof Key for Code Exchange) کے ساتھ Authorization Code Flow ہے۔ PKCE اجازت نامے کے کوڈ کو روکے جانے سے روکتا ہے — موبائل ایپلیکیشنز کے لیے ایک لازمی ضرورت۔

OpenID Connect (OIDC) صارف کی تصدیق کے لیے OAuth 2.0 کے اوپر ایک توسیع ہے۔ OIDC JWT فارمیٹ میں ایک ID Token شامل کرتا ہے جس میں صارف کی معلومات (نام، ای میل، آئی ڈی) ہوتی ہے۔ OAuth 2.0 + OIDC بہاؤ میں شامل ہیں: صارف کو لاگ ان پیج پر ری ڈائریکٹ کرنا، اجازت نامے کا کوڈ حاصل کرنا، ٹوکنز کے لیے کوڈ کا تبادلہ (access + refresh + id)، API درخواستوں کے لیے رسائی ٹوکن کا استعمال۔

JWT: رسائی، ریفریش اور سیشن ٹوکن

JWT (JSON Web Token) ایک کمپیکٹ، URL-محفوظ ٹوکن فارمیٹ ہے جس میں JSON فارمیٹ میں دعوے (claims) ہوتے ہیں۔ JWT تین حصوں پر مشتمل ہوتا ہے: ہیڈر (قسم اور دستخطی الگورتھم)، پے لوڈ (ڈیٹا) اور دستخط۔ رسائی ٹوکن API تک رسائی کے لیے ایک قلیل مدتی ٹوکن (15-60 منٹ) ہے۔ ریفریش ٹوکن دوبارہ لاگ ان کیے بغیر نیا رسائی ٹوکن حاصل کرنے کے لیے ایک طویل مدتی ٹوکن (دن/ہفتے) ہے۔

سیشن ٹوکن ایک روایتی طریقہ ہے جہاں سرور ڈیٹابیس یا Redis میں سیشن محفوظ کرتا ہے، اور کلائنٹ کو ایک بے ترتیب شناخت کنندہ ملتا ہے۔ موبائل ڈیولپمنٹ میں، JWT کو ترجیح دی جاتی ہے: اسے سرور سائیڈ سیشن اسٹوریج کی ضرورت نہیں ہوتی، اپنے اندر تمام معلومات رکھتا ہے اور تصدیق کرنا آسان ہے۔ تاہم، JWT کو فوری طور پر منسوخ نہیں کیا جا سکتا — یہ ایک سمجھوتہ ہے جو رسائی ٹوکن کی مختصر زندگی اور ریفریش ٹوکن کے استعمال سے حل ہوتا ہے۔

بایومیٹرک تصدیق

iOS پر Face ID اور Touch ID، Android پر فنگر پرنٹ تصدیق — بایومیٹرک تصدیق کے طریقے جو صارف کی منفرد جسمانی خصوصیات استعمال کرتے ہیں۔ iOS پر، بایومیٹرکس LocalAuthentication (LAContext) کے ذریعے کام کرتا ہے، Android پر — BiometricPrompt (Android 9+) یا FingerprintManager (متروک) کے ذریعے۔ بایومیٹرکس ایپ کو غیر مقفل کرنے، ادائیگیوں کی تصدیق کرنے اور محفوظ ڈیٹا تک رسائی کے لیے استعمال ہوتا ہے۔

اہم باریکیاں: بایومیٹرکس ایک آسان UX ہے، لیکن سرور تصدیق کا متبادل نہیں ہے۔ کامیاب بایومیٹرک تصدیق کے بعد، ایپلیکیشن کو سرور سے رسائی ٹوکن حاصل کرنا چاہیے۔ Android پر، یقینی بنائیں کہ ڈیوائس کلاس 3 (مضبوط) بایومیٹرکس استعمال کر رہی ہے، نہ کہ صرف کیمرہ پر مبنی چہرے کی شناخت (کلاس 1)۔

کوڈ پروٹیکشن: ProGuard, R8 اور Root Detection

Obfuscation: ProGuard اور R8

ProGuard Android کے لیے Java بائٹ کوڈ کا obfuscation، کمپریشن اور آپٹیمائزیشن کا ایک ٹول ہے، جو ریورس انجینئرنگ کے خلاف کوڈ سیکیورٹی بڑھاتا ہے۔ R8 اس کا جانشین ہے، Android Studio 3.4 سے Gradle میں ضم ہے۔ R8 چار کام انجام دیتا ہے: کمپریشن (غیر استعمال شدہ کلاسز اور طریقوں کو ہٹاتا ہے)، آپٹیمائزیشن (طریقوں کو ان لائن کرتا ہے، کوڈ آسان کرتا ہے)، obfuscation (کلاسز اور طریقوں کے نام مختصر ناموں میں بدلتا ہے) اور پری-تصدیق (بائٹ کوڈ چیک)۔

DexGuard بہتر تحفظ کے ساتھ ProGuard کا ایک تجارتی ورژن ہے: سٹرنگ انکرپشن، وسائل کا obfuscation، ری پیکیجنگ سے تحفظ، APK سالمیت کنٹرول۔ زیادہ تر پروجیکٹس کے لیے، R8 کافی ہے، لیکن مالیاتی اور بینکنگ ایپلیکیشنز کے لیے، DexGuard اضافی سیکیورٹی پرت فراہم کرتا ہے۔ R8 build.gradle کے ذریعے فعال کیا جاتا ہے: minifyEnabled = true اور proguardFiles۔

Root اور Jailbreak کا پتہ لگانا

Root Detection (Android) اور Jailbreak Detection (iOS) ایسے میکانزم ہیں جو چیک کرتے ہیں کہ ڈیوائس پر سپر یوزر مراعات حاصل ہوئی ہیں یا نہیں۔ سمجھوتہ شدہ آلات پر، پروسیس میموری پڑھنا، ٹریفک روکنا اور کوڈ تبدیل کرنا ممکن ہے۔ Android پر جانچ کے لیے، SU بائنری فائل کی موجودگی، ٹیسٹ دستخطی کلیدیں اور غیر معیاری بلڈ فلیگ استعمال کیے جاتے ہیں۔

RASP (Runtime Application Self-Protection) ایک ٹیکنالوجی ہے جو ایپلیکیشن کو عملدرآمد کے دوران تحفظ فراہم کرتی ہے۔ RASP ڈیبگنگ، ری پیکیجنگ، کوڈ انجیکشن کی کوششوں کا پتہ لگاتا ہے اور خطرات کا پتہ چلنے پر ایپلیکیشن کو ختم کر دیتا ہے۔ RASP حل کی مثالیں: Dexter, Guardsquare, Promon۔ RASP رن ٹائم پر کام کرتا ہے اور بے ضابطگیوں پر رد عمل ظاہر کرتا ہے — جامد obfuscation کے برعکس، جو عملدرآمد سے پہلے کوڈ کی حفاظت کرتا ہے۔

ریورس انجینئرنگ ایک کمپائلڈ ایپلیکیشن سے سورس کوڈ بازیافت کرنے کا عمل ہے۔ ٹولز: JADX (APK ڈی کمپائلر), Ghidra, IDA Pro, Hopper۔ ریورس انجینئرنگ کے خلاف تحفظ obfuscation، سٹرنگ انکرپشن، سالمیت کی جانچ اور Root Detection کا ایک مجموعہ ہے۔ مکمل تحفظ موجود نہیں ہے — مقصد حملہ آور کے لیے ریورس انجینئرنگ کو کافی مہنگا بنانا ہے۔