Mobile Secret Management

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

mobile app binary ဆိုတာ private အရာ မဟုတ်ပါဘူး။ ဒါက download, install ဖြစ်ပြီး သင်ထိန်းချုပ်ထားလို့မရတဲ့ device တွေပေါ်မှာ နှစ်ပေါင်းများစွာ version အမျိုးမျိုးနဲ့ စိတ်ဝင်စားသူတိုင်းလက်ထဲ ရောက်နေနိုင်ပါတယ်။

API key, server credential, third-party service အတွက် signing secret စသည်တို့ - app binary ထဲမှာ ပါသွားပြီဆိုရင် ဘယ်လိုပဲ obfuscate ဒါမှမဟုတ် encode လုပ်ထားထား တကယ်တမ်း secret မကျန်တော့ပါဘူး။ obfuscation ဟာ နှေးစေတယ်ဆိုတာမှလွဲပြီး ရပ်တန့်နိုင်စွမ်း မရှိပါဘူး။

credential တစ်ခုက database ထဲ write access, payment method ကနေ ငွေကောက်ခံနိုင်မှု, third-party service ပေါ်က admin rights လိုမျိုး အခွင့်အာဏာအစစ်ကို ပေးထားရင် ဒါဟာ app ထဲမှာ ဘယ်တော့မှ မရှိသင့်ပါဘူး။

ဖြေရှင်းချက်ကတော့ architecture ကို ပြင်ခြင်းပါ၊ ချောမွေ့စွာ ဖျောက်ထားခြင်း မဟုတ်ပါဘူး - သင့် backend ကသာ real secret credential ကို ကိုင်ဆောင်ထားပြီး app က backend ကိုသာ ဆက်သွယ်ကာ backend ကနေ third-party service ကို server ကိုယ်စားပြု ဆက်သွယ်ပါတယ်။

web ထက်တောင် mobile မှာ ဒါက ပိုအရေးကြီးပါတယ် - web deployment ကို မိနစ်အနည်းငယ်အတွင်း patch လုပ်ပြီး redeploy လုပ်နိုင်ပေမယ့် device သန်းချီပေါ်ရောက်နေပြီးသား app binary ကိုတော့ ပြန်ဆွဲမရတော့ဘဲ device တွေက ဘယ်တော့မှ install လုပ်မှာမသိတဲ့ နောက်ထပ် update တစ်ခုနဲ့ပဲ အစားထိုးလို့ရပါတယ်။

BACKEND-PROXY PATTERN FOR MOBILE SECRETS
----------------------------------------
BACKEND-PROXY PATTERN FOR MOBILE SECRETS
-------------------------------------------
GOOD PATTERN
  Mobile App --> Your Backend (holds secret) --> 3rd-party API

BAD PATTERN (do not do this)
  Mobile App --> [Secret Bundled Directly] --> 3rd-party API
                     X inspectable in the shipped binary

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

သင့် app ထဲ ယခုတိုက်ရိုက် ကုတ်ထားတဲ့ configuration value တစ်ခုချင်းစီကို လှည့်ကြည့်ပြီး နှစ်စု ခွဲပါ။

• app ထဲထားနိုင်တာ - base API URL, client အတွက် publishable/restricted key, analytics id။
• app ထဲ လုံးဝမပါရမယ်တာ - data write, ငွေရွှေ့ပြောင်း, admin rights နဲ့ လုပ်ဆောင်နိုင်တာ။

ဒီအမှားရဲ့ ချောမွေ့တဲ့ version နှစ်ခုကို သတိထားပါ - ယနေ့ အန္တရာယ်မရှိပုံပေါ်နေပေမယ့် dashboard ထဲက permission ပြောင်းလဲမှုကြောင့် နောက်ပိုင်း privileged ဖြစ်လာတဲ့ key တစ်ခု၊ ပြီးတော့ config file ဒါမှမဟုတ် environment file ထဲမှာ ရှိပြီး shipped binary ထဲ ပါသွားနေတဲ့ secret တစ်ခုပါ။

• mobile app binary ကို inspect နိုင်တယ်လို့ သဘောထားရမှာဖြစ်ပြီး obfuscation ဟာ စစ်ဆေးမှုကို နှေးစေတယ်ဆိုတာမှလွဲပြီး တားဆီးလို့မရပါဘူး။
• အခွင့်အာဏာအစစ်ရှိတဲ့ credential မှန်သမျှက backend ပေါ်မှာသာ ရှိသင့်ပြီး app ထဲ ဘယ်တော့မှ တိုက်ရိုက်မထည့်ရပါဘူး။
• web ထက် ဒါကပိုအရေးကြီးပါတယ် - install ဖြစ်ပြီးသား app binary ကို web deployment လို ချက်ချင်း patch လုပ်လို့မရပါဘူး။

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

function scanConfigForBundledSecrets(config) {
  const secretPattern = /secret|private[_-]?key|server[_-]?key/i;
  const safeMarkers = ["via-backend", "proxied"];
  const flagged = [];

  for (const [key, value] of Object.entries(config)) {
    if (safeMarkers.includes(value)) continue;
    const looksPrivileged = secretPattern.test(key);
    if (looksPrivileged) {
      flagged.push({ key, reason: "Looks like a privileged secret bundled directly in the app." });
    }
  }

  return { flaggedCount: flagged.length, flagged };
}

const riskyConfig = {
  STRIPE_SECRET_KEY: "sk_live_51H8xExampleNotReal",
  PAYMENT_SERVER_SECRET: "ex_srv_secret_998877",
  MAPS_API_KEY: "AIzaRestrictedPublicKeyExample"
};

const saferConfig = {
  STRIPE_SECRET_KEY: "via-backend",
  PAYMENT_SERVER_SECRET: "via-backend",
  MAPS_API_KEY: "AIzaRestrictedPublicKeyExample"
};

console.log("Risky config:", scanConfigForBundledSecrets(riskyConfig));
console.log("Safer config:", scanConfigForBundledSecrets(saferConfig));

risky config မှာ STRIPE_SECRET_KEY နဲ့ PAYMENT_SERVER_SECRET ဆိုတဲ့ key နှစ်ခုကို app ထဲ တိုက်ရိုက် embed ထားတဲ့ privileged secret အဖြစ် flaggedCount: 2 ပြပါတယ်။ safer config ကတော့ နှစ်ခုစလုံးကို 'via-backend' လို့ သတ်မှတ်ထားလို့ flaggedCount: 0 ဖြစ်ပါတယ်။

OWASP Mobile Application Security (MASTG) — How Mobile Apps Work