পাঠ ৫২ · ৫৭-এর মধ্যে · মডিউল ১২
Home / Courses / Mobile App Development / সিকিউরিটি ফান্ডামেন্টাল

মোবাইল অ্যাপ সিকিউরিটি ফান্ডামেন্টাল

Mobile app security fundamentals
৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • কেন মোবাইল অ্যাপে "ডেটা কোথায় সংরক্ষিত হচ্ছে" সাধারণ ওয়েব কুকি/সেশন ম্যানেজমেন্টের চেয়েও বেশি গুরুত্বপূর্ণ
  • প্লেইন key-value স্টোরেজ বনাম secure enclave/keychain-style স্টোরেজের পার্থক্য
  • একটি সত্যিকারের পলিসি-চেক ফাংশন লিখে দেখা কোন key-গুলো "sensitive" বলে সন্দেহজনক
  • সঠিক কনফিগারেশন (token সঠিক জায়গায়) বনাম ভুল কনফিগারেশন (token ভুল জায়গায়) — উভয়ের প্রকৃত ফলাফল

১ · মোবাইলে সিকিউরিটি কেন আলাদা

সিকিউরিটির সাধারণ ভিত্তি — এনক্রিপশন, হ্যাশিং, প্রমাণীকরণ — এই কোর্সের বিষয় নয়; Cybersecurity কোর্সে সেগুলো বিস্তারিত শেখানো হয়েছে। মোবাইলে বাড়তি ঝুঁকির জায়গা হলো: একটি ফোন হারিয়ে যাওয়া বা চুরি হওয়া সহজ, এবং একবার কারো হাতে ডিভাইসটি পৌঁছালে ইনস্টলড অ্যাপের লোকাল ফাইল পরীক্ষা করা সম্ভব হতে পারে (বিশেষত rooted/jailbroken ডিভাইসে)। তাই মোবাইলে sensitive ডেটা ঠিক কোথায় সংরক্ষণ করা হচ্ছে — সেটাই সবচেয়ে সাধারণ ও সবচেয়ে বিপজ্জনক ভুলের জায়গা।

প্লেইন key-value store
যেমন Android-এর SharedPreferences বা iOS-এর UserDefaults — দ্রুত ও সহজ, কিন্তু ডিফল্টভাবে এনক্রিপ্ট করা নয়। থিম/সেটিংসের মতো নন-sensitive ডেটার জন্য উপযুক্ত।
Secure enclave / keychain
যেমন iOS Keychain বা Android Keystore — OS-লেভেল এনক্রিপশন ও হার্ডওয়্যার-ব্যাকড সুরক্ষা সহ। auth token, পাসওয়ার্ড, রিফ্রেশ টোকেনের মতো sensitive ডেটার জন্য এখানেই রাখা উচিত।

২ · একটি সত্যিকারের স্টোরেজ-পলিসি চেক

নিচে দুটো আলাদা dict — plain_store (এনক্রিপ্ট-না-করা) ও secure_store (keychain-স্টাইল) — সিমুলেট করা হচ্ছে। একটি ফাংশন audit_plain_store() লেখা হচ্ছে যা plain_store-এর প্রতিটি key পরীক্ষা করে দেখে তার নামে SENSITIVE_MARKERS-এর কোনো সাব-স্ট্রিং আছে কি না — থাকলে সেটিকে একটি নীতি-লঙ্ঘন হিসেবে রিপোর্ট করে। দুটো পরিস্থিতি চালানো হচ্ছে — একটি সঠিক কনফিগারেশন, একটি ভুল।

Python
# sensitive বলে সন্দেহজনক key-নামের সাব-স্ট্রিং তালিকা
SENSITIVE_MARKERS = ["token", "password", "secret", "session_key", "credential"]

def is_sensitive_key(key):
    lowered = key.lower()
    return any(marker in lowered for marker in SENSITIVE_MARKERS)

def audit_plain_store(plain_store):
    """plain_store (এনক্রিপ্ট-না-করা key-value store)-এর প্রতিটি key পরীক্ষা করে --
    sensitive-লাগা কোনো key থাকলে তা নীতি-লঙ্ঘন হিসেবে রিপোর্ট করে।"""
    return [key for key in plain_store if is_sensitive_key(key)]

def report(label, plain_store, secure_store):
    violations = audit_plain_store(plain_store)
    print(f"== {label} ==")
    print(f"  plain store keys : {list(plain_store.keys())}")
    print(f"  secure store keys: {list(secure_store.keys())}")
    if violations:
        print(f"  [FAIL] নীতি লঙ্ঘন -- sensitive key ভুল জায়গায় (plain store) সংরক্ষিত: {violations}")
    else:
        print(f"  [PASS] plain store-এ কোনো sensitive key পাওয়া যায়নি -- নীতি মানা হয়েছে")
    print()
    return violations

# পরিস্থিতি ১ -- সঠিক: auth token ও refresh token secure store-এ সংরক্ষিত
plain_ok = {"theme_preference": "dark", "font_size": "large", "onboarding_seen": True}
secure_ok = {"auth_token": "eyJhbGciOiJIUzI1NiJ9.example", "refresh_token": "9f8e7d6c5b4a"}
violations_ok = report("সঠিক কনফিগারেশন", plain_ok, secure_ok)

# পরিস্থিতি ২ -- ভুল: auth token ভুলবশত plain store-এ সংরক্ষিত
plain_bad = {"theme_preference": "dark", "auth_token": "eyJhbGciOiJIUzI1NiJ9.example"}
secure_bad = {}
violations_bad = report("ভুল কনফিগারেশন", plain_bad, secure_bad)

assert violations_ok == [], f"সঠিক কনফিগারেশনে কোনো ভায়োলেশন থাকার কথা না, পাওয়া গেছে: {violations_ok}"
assert violations_bad == ["auth_token"], f"'auth_token' ফ্ল্যাগ হওয়ার কথা ছিল, পাওয়া গেছে: {violations_bad}"
print("যাচাই সফল: পলিসি-চেক ফাংশনটি সঠিক কনফিগারেশনকে পাস দিয়েছে এবং ভুল কনফিগারেশনকে সঠিকভাবে ফ্ল্যাগ করেছে।")

    
লক্ষ্য করুন audit_plain_store() শুধুই plain_store-এর key-নাম পরীক্ষা করে — secure_store-এ যাই থাকুক না কেন তা কখনো ফ্ল্যাগ হয় না, কারণ সেটিই সঠিক জায়গা। পরিস্থিতি ১-এ "auth_token" ও "refresh_token" শুধু secure_ok-তে আছে, তাই violations_ok খালি তালিকা। পরিস্থিতি ২-এ "auth_token" ভুলবশত plain_bad-তে আছে — is_sensitive_key("auth_token") সত্যি হওয়ায় (কারণ "token" সাব-স্ট্রিং মেলে) এটি violations_bad-এ ধরা পড়ে।
মূল কথা · Key takeaway

মোবাইল সিকিউরিটির প্রথম ও সবচেয়ে সাধারণভাবে এড়ানো যায় এমন ভুল হলো sensitive ডেটাকে ভুল স্টোরেজে রাখা — একটি এনক্রিপ্ট-না-করা key-value store-এ auth token রাখলে, ডিভাইস আপোসকৃত (compromised) হলে সেই টোকেনও উন্মুক্ত হয়ে যায়। একটি স্বয়ংক্রিয় পলিসি-চেক (উপরের মতো) কোড রিভিউ বা CI-তে একীভূত করলে এই ধরনের ভুল প্রোডাকশনে পৌঁছানোর আগেই ধরা পড়ে। এনক্রিপশন কীভাবে কাজ করে তার বিস্তারিত জন্য Cybersecurity কোর্স দেখুন।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ কেন theme_preference-এর মতো একটি key প্লেইন store-এ রাখা নিরাপদ, কিন্তু auth_token নয়?

theme_preference-এর মান ("dark"/"light") ফাঁস হলে ব্যবহারকারীর কোনো প্রকৃত ক্ষতি হয় না — এটি sensitive নয়। কিন্তু auth_token ফাঁস হলে যে কেউ সেই টোকেন ব্যবহার করে ব্যবহারকারীর অ্যাকাউন্টে প্রবেশ করতে পারে, নতুন করে লগইন-পাসওয়ার্ড না জেনেই — তাই এটি এনক্রিপ্টেড, OS-সুরক্ষিত স্টোরেজে রাখা জরুরি।

প্র ০২ is_sensitive_key() ফাংশনটি key-এর নাম দেখে সিদ্ধান্ত নেয়, key-এর মান দেখে নয় — এটি কি একটি সীমাবদ্ধতা?

হ্যাঁ — যদি কেউ একটি auth token "user_settings" নামের key-তে রেখে দেয়, এই সাধারণ চেকটি সেটি ধরতে পারবে না, কারণ নামে কোনো sensitive marker নেই। বাস্তব সিকিউরিটি অডিটে নামকরণ-নীতির পাশাপাশি মান-প্যাটার্ন যাচাই (যেমন JWT-এর মতো ফরম্যাট চেনা) এবং কোড-রিভিউ নিয়মও ব্যবহৃত হয় — এই পাঠের চেকটি একটি প্রথম-স্তরের, দ্রুত স্বয়ংক্রিয় নিরাপত্তা-জাল হিসেবে বোঝা উচিত, একমাত্র সুরক্ষা হিসেবে নয়।

প্র ০৩ যদি কেউ SENSITIVE_MARKERS তালিকা থেকে "token" ভুলবশত সরিয়ে ফেলে, তাহলে উপরের কোড সেলের দ্বিতীয় assert-এর কী হবে?

is_sensitive_key("auth_token") তখন False রিটার্ন করবে (কারণ বাকি কোনো marker — "password", "secret", "session_key", "credential" — "auth_token"-এর সাথে মেলে না), তাই violations_bad খালি তালিকা [] হবে — assert violations_bad == ["auth_token"] ব্যর্থ হয়ে AssertionError তুলবে। এটাই দেখায় SENSITIVE_MARKERS তালিকাটিই এই পুরো নিরাপত্তা-চেকের একমাত্র ভিত্তি — এটি অসম্পূর্ণ হলে পুরো চেকটিও দুর্বল হয়ে যায়।

অনুশীলন

  1. চিন্তা করুন: একটি "মনে রাখুন" (remember me) ফিচারযুক্ত লগইন স্ক্রিন কল্পনা করুন যা ব্যবহারকারীর ইমেইল ও একটি দীর্ঘমেয়াদি refresh token সংরক্ষণ করে। এই দুটো ডেটা কোন কোন স্টোরেজে যাবে বলে মনে হয়, এবং কেন আলাদা?

    ইমেইল ঠিকানাটি প্লেইন store-এ রাখা যেতে পারে (এটি একা ফাঁস হলে সরাসরি অ্যাকাউন্ট-অ্যাক্সেস দেয় না, যদিও এটি ব্যক্তিগত তথ্য বলে সতর্কতা প্রয়োজন), কিন্তু refresh token অবশ্যই secure store-এ যাবে — এটি দীর্ঘমেয়াদি এবং ফাঁস হলে দীর্ঘ সময় ধরে অ্যাকাউন্ট-অ্যাক্সেসের ঝুঁকি তৈরি করে। এটাই মূল নীতি — ডেটার sensitivity অনুযায়ী স্টোরেজ বেছে নেওয়া, সবকিছু এক জায়গায় না রাখা।

  2. পরীক্ষা করুন: উপরের কোড সেলে plain_bad-এ আরেকটি key যোগ করুন — "api_secret_key": "sk_live_xxx" — এবং কোডটি আবার চালিয়ে দেখুন violations_bad-এ কী পরিবর্তন হয়।

    "api_secret_key"-তে "secret" সাব-স্ট্রিং থাকায় is_sensitive_key() এটিকেও True চিহ্নিত করবে — তাই violations_bad এখন দুটো এন্ট্রি ধারণ করবে: ["auth_token", "api_secret_key"]। মূল assert violations_bad == ["auth_token"] তখন ব্যর্থ হবে, কারণ প্রত্যাশিত তালিকাটিও আপডেট করা প্রয়োজন — এটি দেখায় টেস্ট নিজেই কোডের সাথে সিঙ্কে রাখতে হয়।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

  • কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ অ্যাপ লাইফসাইকেল, মোবাইল UI/UX, MVVM/MVI আর্কিটেকচার, নেটিভ বনাম ক্রস-প্ল্যাটফর্ম, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, ডিভাইস ফিচার ও ডিপ্লয়মেন্ট — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
  • Cybersecurity কোর্স সহোদর কোর্স এনক্রিপশন, হ্যাশিং, প্রমাণীকরণসহ সিকিউরিটির সাধারণ ভিত্তি সেই কোর্সেই বিস্তারিত শেখানো হয়েছে।
  • সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks ও Mobile App Development — সব এক জায়গায়।
আগের পাঠ
মোবাইলের জন্য UI/অটোমেশন টেস্টিং