মোবাইল অ্যাপ সিকিউরিটি ফান্ডামেন্টাল
এই পাঠে যা শিখবেন
- কেন মোবাইল অ্যাপে "ডেটা কোথায় সংরক্ষিত হচ্ছে" সাধারণ ওয়েব কুকি/সেশন ম্যানেজমেন্টের চেয়েও বেশি গুরুত্বপূর্ণ
- প্লেইন key-value স্টোরেজ বনাম secure enclave/keychain-style স্টোরেজের পার্থক্য
- একটি সত্যিকারের পলিসি-চেক ফাংশন লিখে দেখা কোন key-গুলো "sensitive" বলে সন্দেহজনক
- সঠিক কনফিগারেশন (token সঠিক জায়গায়) বনাম ভুল কনফিগারেশন (token ভুল জায়গায়) — উভয়ের প্রকৃত ফলাফল
১ · মোবাইলে সিকিউরিটি কেন আলাদা
সিকিউরিটির সাধারণ ভিত্তি — এনক্রিপশন, হ্যাশিং, প্রমাণীকরণ — এই কোর্সের বিষয় নয়; Cybersecurity কোর্সে সেগুলো বিস্তারিত শেখানো হয়েছে। মোবাইলে বাড়তি ঝুঁকির জায়গা হলো: একটি ফোন হারিয়ে যাওয়া বা চুরি হওয়া সহজ, এবং একবার কারো হাতে ডিভাইসটি পৌঁছালে ইনস্টলড অ্যাপের লোকাল ফাইল পরীক্ষা করা সম্ভব হতে পারে (বিশেষত rooted/jailbroken ডিভাইসে)। তাই মোবাইলে sensitive ডেটা ঠিক কোথায় সংরক্ষণ করা হচ্ছে — সেটাই সবচেয়ে সাধারণ ও সবচেয়ে বিপজ্জনক ভুলের জায়গা।
যেমন Android-এর SharedPreferences বা iOS-এর UserDefaults — দ্রুত ও সহজ, কিন্তু ডিফল্টভাবে এনক্রিপ্ট করা নয়। থিম/সেটিংসের মতো নন-sensitive ডেটার জন্য উপযুক্ত।
যেমন iOS Keychain বা Android Keystore — OS-লেভেল এনক্রিপশন ও হার্ডওয়্যার-ব্যাকড সুরক্ষা সহ। auth token, পাসওয়ার্ড, রিফ্রেশ টোকেনের মতো sensitive ডেটার জন্য এখানেই রাখা উচিত।
২ · একটি সত্যিকারের স্টোরেজ-পলিসি চেক
নিচে দুটো আলাদা dict — plain_store (এনক্রিপ্ট-না-করা) ও secure_store
(keychain-স্টাইল) — সিমুলেট করা হচ্ছে। একটি ফাংশন audit_plain_store() লেখা হচ্ছে যা
plain_store-এর প্রতিটি key পরীক্ষা করে দেখে তার নামে SENSITIVE_MARKERS-এর কোনো
সাব-স্ট্রিং আছে কি না — থাকলে সেটিকে একটি নীতি-লঙ্ঘন হিসেবে রিপোর্ট করে। দুটো পরিস্থিতি চালানো হচ্ছে — একটি
সঠিক কনফিগারেশন, একটি ভুল।
# 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-এ ধরা পড়ে।
মোবাইল সিকিউরিটির প্রথম ও সবচেয়ে সাধারণভাবে এড়ানো যায় এমন ভুল হলো 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 তালিকাটিই এই পুরো নিরাপত্তা-চেকের একমাত্র ভিত্তি — এটি
অসম্পূর্ণ হলে পুরো চেকটিও দুর্বল হয়ে যায়।
অনুশীলন
-
চিন্তা করুন: একটি "মনে রাখুন" (remember me) ফিচারযুক্ত লগইন স্ক্রিন কল্পনা করুন যা
ব্যবহারকারীর ইমেইল ও একটি দীর্ঘমেয়াদি refresh token সংরক্ষণ করে। এই দুটো ডেটা কোন কোন স্টোরেজে যাবে বলে
মনে হয়, এবং কেন আলাদা?
ইমেইল ঠিকানাটি প্লেইন store-এ রাখা যেতে পারে (এটি একা ফাঁস হলে সরাসরি অ্যাকাউন্ট-অ্যাক্সেস দেয় না, যদিও এটি ব্যক্তিগত তথ্য বলে সতর্কতা প্রয়োজন), কিন্তু refresh token অবশ্যই secure store-এ যাবে — এটি দীর্ঘমেয়াদি এবং ফাঁস হলে দীর্ঘ সময় ধরে অ্যাকাউন্ট-অ্যাক্সেসের ঝুঁকি তৈরি করে। এটাই মূল নীতি — ডেটার sensitivity অনুযায়ী স্টোরেজ বেছে নেওয়া, সবকিছু এক জায়গায় না রাখা।
-
পরীক্ষা করুন: উপরের কোড সেলে
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 — সব এক জায়গায়।