মোবাইল ডেভেলপমেন্টে নিরাপত্তা: এটি কী, কী কী হুমকি রয়েছে এবং কীভাবে রক্ষা করবেন

প্রধান হুমকি: 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: অনিরাপদ অনুমোদন — একজন ব্যবহারকারী একটি অনুরোধে আইডি প্রতিস্থাপন করে অন্য ব্যবহারকারীর ডেটা অ্যাক্সেস করতে পারে। M7: কোড ইনজেকশন (SQL Injection, XSS)। M8: অ্যাপ ম্যানিপুলেশন — রিপ্যাকেজিং, কোড প্রতিস্থাপন। M9 এবং M10 — তৃতীয় পক্ষের লাইব্রেরির মাধ্যমে ডেটা ফাঁস এবং রিভার্স ইঞ্জিনিয়ারিং। এই প্রতিটি হুমকির জন্য প্রমাণিত প্রতিকার বিদ্যমান, এবং IT Sectr-এ আমরা 2017 সাল থেকে সমস্ত প্রকল্পে সেগুলি প্রয়োগ করছি।

Man-in-the-Middle (MITM) আক্রমণ

MITM আক্রমণ ঘটে যখন একজন আক্রমণকারী অ্যাপ্লিকেশন এবং সার্ভারের মধ্যে ট্রাফিক আটকায়। এটি DNS স্পুফিং, ARP স্পুফিং বা একটি অনিরাপদ 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

অবফাসকেশন: ProGuard এবং R8

ProGuard Android-এর জন্য Java বাইটকোডের অবফাসকেশন, কম্প্রেশন এবং অপ্টিমাইজেশনের একটি টুল, যা রিভার্স ইঞ্জিনিয়ারিংয়ের বিরুদ্ধে কোড নিরাপত্তা বাড়ায়। R8 হল এর উত্তরসূরি, Android Studio 3.4 থেকে Gradle-এ একীভূত। R8 চারটি কাজ সম্পাদন করে: কম্প্রেশন (অব্যবহৃত ক্লাস এবং পদ্ধতি সরিয়ে দেয়), অপ্টিমাইজেশন (পদ্ধতি ইনলাইন করে, কোড সরল করে), অবফাসকেশন (ক্লাস এবং পদ্ধতির নাম ছোট নামে পরিবর্তন করে) এবং প্রি-ভেরিফিকেশন (বাইটকোড পরীক্ষা)।

DexGuard উন্নত সুরক্ষা সহ ProGuard-এর একটি বাণিজ্যিক সংস্করণ: স্ট্রিং এনক্রিপশন, রিসোর্স অবফাসকেশন, রিপ্যাকেজিং থেকে সুরক্ষা, APK অখণ্ডতা নিয়ন্ত্রণ। বেশিরভাগ প্রকল্পের জন্য, R8 যথেষ্ট, তবে আর্থিক এবং ব্যাঙ্কিং অ্যাপ্লিকেশনের জন্য, DexGuard অতিরিক্ত সুরক্ষা স্তর সরবরাহ করে। R8 build.gradle এর মাধ্যমে সক্রিয় করা হয়: minifyEnabled = true এবং proguardFiles।

Root এবং Jailbreak Detection

Root Detection (Android) এবং Jailbreak Detection (iOS) এমন প্রক্রিয়া যা পরীক্ষা করে যে ডিভাইসে সুপারইউজার সুবিধা প্রাপ্ত হয়েছে কিনা। আপোসকৃত ডিভাইসগুলিতে, প্রসেস মেমোরি পড়া, ট্রাফিক আটকানো এবং কোড প্রতিস্থাপন করা সম্ভব। Android-এ পরীক্ষার জন্য, SU বাইনারি ফাইলের উপস্থিতি, পরীক্ষার স্বাক্ষর কী এবং অ-মানক বিল্ড ফ্ল্যাগ ব্যবহার করা হয়।

RASP (Runtime Application Self-Protection) একটি প্রযুক্তি যা এক্সিকিউশনের সময় অ্যাপ্লিকেশনকে রক্ষা করে। RASP ডিবাগিং, রিপ্যাকেজিং, কোড ইনজেকশনের প্রচেষ্টা সনাক্ত করে এবং হুমকি শনাক্ত হলে অ্যাপ্লিকেশনটি শেষ করে দেয়। RASP সমাধানের উদাহরণ: Dexter, Guardsquare, Promon। RASP রানটাইমে কাজ করে এবং অসঙ্গতিতে প্রতিক্রিয়া জানায় — স্ট্যাটিক অবফাসকেশনের বিপরীতে, যা এক্সিকিউশনের আগে কোড রক্ষা করে।

রিভার্স ইঞ্জিনিয়ারিং একটি কম্পাইলড অ্যাপ্লিকেশন থেকে সোর্স কোড পুনরুদ্ধারের প্রক্রিয়া। টুল: JADX (APK ডিকম্পাইলার), Ghidra, IDA Pro, Hopper। রিভার্স ইঞ্জিনিয়ারিংয়ের বিরুদ্ধে সুরক্ষা হল অবফাসকেশন, স্ট্রিং এনক্রিপশন, অখণ্ডতা পরীক্ষা এবং Root Detection-এর সমন্বয়। সম্পূর্ণ সুরক্ষা নেই — লক্ষ্য হল আক্রমণকারীর জন্য রিভার্স ইঞ্জিনিয়ারিংকে যথেষ্ট ব্যয়বহুল করা।