Mobile Security အခြေခံများ

နားလည်ထားရမယ့် အချက်

ဒီအခန်းထဲက mobile security သင်ခန်းစာတိုင်းက root idea တစ်ခုတည်းကို ပြန်ညွှန်းနေကြပါတယ် - client ကို ဘယ်တော့မှ မယုံပါနဲ့။ mobile app တစ်ခုဟာ user ကိုယ်တိုင် ထိန်းချုပ်တဲ့ hardware နဲ့ operating system ပေါ်မှာ run နေတဲ့ software တစ်ခုပါပဲ။

တကယ်အရေးကြီးတဲ့ rule ဘယ်တစ်ခုမဆို - price, permission, user authenticate ဖြစ်မဖြစ်, action တစ်ခု ခွင့်ပြုမပြု - app က ဘာစစ်ထားပြီးသားဖြစ်ဖြစ် သင့် backend မှာ ထပ်ပြီး enforce ပြန်လုပ်ရပါတယ်။ client-side check ဆိုတာ ရိုးသားတဲ့ user တွေအတွက် အဆင်ပြေစေချက်ပါပဲ၊ security boundary ဘယ်တော့မှ မဖြစ်နိုင်ပါဘူး။

logging discipline ကလည်း logic တူတူပါပဲ - password, access ဒါမှမဟုတ် refresh token, payment detail, sensitive personal data တစ်ခုမှ log file ထဲ ခေတ္တလောက်ပဲဖြစ်ဖြစ်, development ထဲမှာဖြစ်ဖြစ် ဘယ်တော့မှ ရောက်မသွားပါစေနဲ့။

root ဒါမှမဟုတ် jailbreak လုပ်ထားတဲ့ device တွေအကြောင်း လက်တွေ့ကျကျ ရှုမြင်ပါ - client-side security ယူဆချက် အချို့ ပြင်ဆင်ထားတဲ့ device ပေါ်မှာ ပိုအားနည်းသွားပါတယ်၊ ဒါကြောင့် device-level trust ထက် server-side validation က ပိုအရေးကြီးရတာပါ၊ ဒီကာကွယ်မှုတွေကို ဖြတ်ကျော်နည်း ဖော်ပြရမယ့် အကြောင်းရင်း မဟုတ်ပါဘူး။

LAYERED MOBILE SECURITY MODEL
-----------------------------
LAYERED MOBILE SECURITY MODEL
-------------------------------
  Layer 1: Never Trust the Client
  Layer 2: Secure Storage Classification
  Layer 3: Logging Discipline
  Layer 4: Server-Side Validation (final authority)

  Each layer backs up the one above it.
  Server-Side Validation cannot be skipped by any layer.

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

သင့် app ရဲ့ အထိခိုက်လွယ်ဆုံး action တွေကို လှည့်ကြည့်ပြီး တစ်ခုချင်းစီအတွက် ရိုးရိုးသားသား မေးပါ - client က မမျှော်လင့်ထားတာတစ်ခု ပို့လိုက်ရင် server က ဖမ်းမိမလား, ဒါမှမဟုတ် app ရဲ့ စကားကို ယုံကြည်ရုံပဲလား။

• order တင်ခြင်း, discount သုံးခြင်း, feature ဖွင့်ခြင်း, account setting ပြောင်းခြင်း။
• 'app ကို ယုံကြည်တယ်' ဆိုတဲ့ အဖြေရလာတဲ့နေရာတိုင်းကို server-side check အစစ်တစ်ခုနဲ့ ပိတ်ပါ။

သင့် app က local မှာ တကယ်သိမ်းထားတာတွေကို list လုပ်ပြီး ရိုးသားစွာ classify လုပ်ပါ၊ credential category ထဲက ဘာမဆို သင့်လျော်တဲ့ secure storage ဆီ ရွှေ့ပါ။

• client ကို ဘယ်တော့မှ မယုံပါနဲ့ - တကယ်အရေးကြီးတဲ့ rule ကို app က ဘာစစ်ထားပြီးဖြစ်ဖြစ် backend မှာ ထပ်ပြီး enforce ပြန်လုပ်ရပါတယ်။
• local data ကို ရိုးရိုးသားသား classify လုပ်ပါ - harmless preference, credential, sensitive personal data ခွဲခြားပြီး သင့်လျော်အောင် သိမ်းပါ။
• root ဒါမှမဟုတ် jailbreak လုပ်ထားတဲ့ device ဆိုတာ client-side workaround နဲ့ ဖြေရှင်းရမယ့် ပဟေဠိမဟုတ်ဘဲ server-side validation ကို ပိုအားထားရမယ့် အကြောင်းအရင်းတစ်ခုပါ။

Mobile Security အခြေခံ Checklist

• backend က business rule အားလုံးကို server-side မှာ validate လုပ်ပါတယ် - client-side check တစ်ခုတည်းကို ဘယ်တော့မှ မယုံပါနဲ့။
• sensitive data ကို classify လုပ်ပြီး သင့်လျော်အောင် သိမ်းထားပါတယ် - secure storage vs normal storage ခွဲခြားပါ။
• password, token, payment info ကို log ထဲ ဘယ်တော့မှ မရေးမိပါစေနဲ့။
• permission တွေကို အနည်းဆုံး လိုအပ်သလောက်ပဲ တောင်းပြီး user ကို ရှင်းပြပါ။
• အခွင့်အာဏာအစစ်ရှိတဲ့ secret တွေကို app binary ထဲ ဘယ်တော့မှ တိုက်ရိုက်မထည့်ပါနဲ့။

အတူတူ စမ်းရေးကြည့်မယ်

function evaluateTrustBoundary(check) {
  if (check.validatedServerSide) {
    return {
      verdict: "safe",
      reason: `${check.checkName} is enforced server-side, so a modified client can't bypass it.`
    };
  }
  if (check.validatedClientSide && !check.validatedServerSide) {
    return {
      verdict: "risky",
      reason: `${check.checkName} is only checked client-side -- a modified client could bypass it entirely.`
    };
  }
  return { verdict: "unknown", reason: "No validation described for this check." };
}

const riskyCheck = { checkName: "Discount price validation", validatedClientSide: true, validatedServerSide: false };
const safeCheck = { checkName: "Discount price validation", validatedClientSide: true, validatedServerSide: true };

console.log("Risky check:", evaluateTrustBoundary(riskyCheck));
console.log("Safe check:", evaluateTrustBoundary(safeCheck));

risky check (client-side ပဲ validate လုပ်ထား) က { verdict: 'risky' } ကို modified client ဖြင့် bypass နိုင်ကြောင်း reason နဲ့ ပြန်ပေးပါတယ်။ safe check (နှစ်ဖက်စလုံး validate) ကတော့ { verdict: 'safe' } ကို server-side enforce လုပ်ထားလို့ modified client က bypass မလုပ်နိုင်ကြောင်း reason နဲ့ ပြန်ပေးပါတယ်။

OWASP Mobile Top 10 — How Mobile Apps Work