နားလည်ထားရမယ့် အချက်
Cybersecurity Basics course က API key ကို secret အဖြစ် သဘောထားရမယ်ဆိုတာ ရှင်းပြပြီးသားပါ—ဒီ lesson ကတော့ ဒီအယူအဆကို token နဲ့ session အထိ ချဲ့ပေးမယ်။
token (သို့) session identifier တစ်ခုဟာ လုပ်ဆောင်ချက်အရ credential တစ်ခုပါ—ကိုင်ဆောင်ထားသူဟာ သက်တမ်းကုန်တဲ့အထိ ဒီ user အဖြစ် လုပ်ဆောင်နိုင်တယ်။
- token ကို ယာယီအနေနဲ့တောင် log ဘယ်တော့မှ မလုပ်ပါနဲ့—log တွေက copy ကူးတယ်၊ ကြာကြာ သိမ်းထားလေ့ရှိတယ်။
- token ကို Git ထဲ ဘယ်တော့မှ commit မလုပ်ပါနဲ့—history က ထာဝရ မှတ်ထားလိမ့်မယ်။
- server-only token ကို client-side code ဆီ ဘယ်တော့မှ မဖော်ထုတ်ပါနဲ့—ဘယ်သူမဆို developer tools နဲ့ ဖတ်နိုင်တယ်။
- token ကို ဘယ်အခါမှ HTTPS ကနေသာ ပို့ပါ—plaintext transit ကို ဖမ်းယူနိုင်တယ်။
Session လုံခြုံရေးကလည်း ဒီယုတ္တိတူပါတယ်—secure, HttpOnly cookie, SameSite setting, real expiry policy အားလုံးက အရေးကြီးတယ်။
- Secure, HttpOnly cookie တွေက session token ကို client-side script တွေက လက်မလှမ်းမှီစေတယ်။
- SameSite setting တွေက cookie ကို cross-site request တွေနဲ့ ဘယ်တော့ ပို့မလဲဆိုတာ ကန့်သတ်ပေးတယ်။
- Session တွေဟာ သင့်တော်တဲ့ inactivity ကာလကျော်ရင် သက်တမ်းကုန်သင့်တယ်။
- user logout လုပ်တဲ့အချိန် session ကို အပြည့်အဝ invalidate ဖြစ်ရမယ်။
ဒါတွေကို အစအဆုံး ကိုယ်တိုင် တည်ဆောက်ဖို့ မလိုပါဘူး—established, audited library (သို့) framework တွေက ဒီပြဿနာတွေကို ဖြေရှင်းပြီးသားပါ။
TOKEN / SESSION LIFECYCLE
-------------------------
ISSUED (login succeeds)
|
v
USED -- must be over HTTPS, never logged, never in Git
|
+-- server-only token? --> NEVER expose to client-side code
|
v
EXPIRES (timeout) or INVALIDATED (logout)
|
v
DEAD -- token/session no longer usableလက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
အောက်က function က token ကို code အပိုင်းတစ်ခုက ဘယ်လို handle လုပ်လဲဆိုတာအတွက် အမြန် reviewer တစ်ယောက်လို အလုပ်လုပ်တယ်—boolean လေးခုနဲ့ ဖော်ပြပါ၊ ဘယ်အမှားရှိလဲ အတိအကျ ပြန်ပြောပေးမယ်။
| အမှား | ဘာလို့အရေးကြီးလဲ |
|---|---|
| Logging the token | Log တွေက copy ကူးတယ်၊ tool တွေဆီ ပို့တယ်၊ ကြာကြာ သိမ်းထားတယ်။ |
| Committing to Git | နောက်ပိုင်း ဖျက်ပေမယ့် history က ထာဝရ မှတ်ထားလိမ့်မယ်။ |
| Exposing to client-side code | app သုံးသူ ဘယ်သူမဆို developer tools နဲ့ ဖတ်နိုင်တယ်။ |
| Skipping HTTPS | token ကို လမ်းကြားမှာ ဖမ်းယူနိုင်တယ်။ |
risky snippet (token ကို log လုပ်ပြီး client ဆီ ဖော်ထုတ်—RISKY) နဲ့ safe snippet (လေးခုစလုံး မရှိ—SAFE) နှစ်ခုနဲ့ run ကြည့်ပါ။
code review လုပ်တဲ့အခါ ကိုယ်တိုင်ရေးသည်ဖြစ်စေ AI assistant ရေးသည်ဖြစ်စေ ဒီလို check ကို mental checklist အနေနဲ့ သုံးပါ။
ကိုယ်တိုင် ဘယ်တော့မှ မတည်ဆောက်ပါနဲ့
Session/token handling ကို အစအဆုံး ကိုယ်တိုင် ဘယ်တော့မှ မရေးပါနဲ့။ established, audited library (သို့) framework တွေကိုသာ သုံးပါ—ကိုယ်တိုင်ရေးရင် serious vulnerability တစ်ခု ဖြစ်စေနိုင်တဲ့ အမြန်ဆုံးနည်းလမ်းတစ်ခုပါ။
အတူတူ စမ်းရေးကြည့်မယ်
function scanTokenHandling(snippet) {
const mistakes = [];
if (snippet.loggingToken) {
mistakes.push("Token is written to logs — logs are read by many people/tools and often stored long-term.");
}
if (snippet.committingToGit) {
mistakes.push("Token is committed to Git — history keeps it forever, even after later removal.");
}
if (snippet.exposingServerTokenToClient) {
mistakes.push("A server-only token is sent to client-side code — anyone using the app can read it.");
}
if (!snippet.usingHTTPS) {
mistakes.push("Token travels over a non-HTTPS connection — it can be intercepted in transit.");
}
return {
mistakeCount: mistakes.length,
mistakes,
verdict: mistakes.length === 0 ? "SAFE" : "RISKY",
};
}
const riskyExample = scanTokenHandling({
loggingToken: true,
committingToGit: false,
exposingServerTokenToClient: true,
usingHTTPS: true,
});
const safeExample = scanTokenHandling({
loggingToken: false,
committingToGit: false,
exposingServerTokenToClient: false,
usingHTTPS: true,
});
console.log("Risky snippet:");
console.log(JSON.stringify(riskyExample, null, 2));
console.log("\nSafe snippet:");
console.log(JSON.stringify(safeExample, null, 2));Risky snippet:
{
"mistakeCount": 2,
"mistakes": [
"Token is written to logs — logs are read by many people/tools and often stored long-term.",
"A server-only token is sent to client-side code — anyone using the app can read it."
],
"verdict": "RISKY"
}
Safe snippet:
{
"mistakeCount": 0,
"mistakes": [],
"verdict": "SAFE"
}၅ မိနစ် စမ်းကြည့်
scanTokenHandling ထဲကို ပဉ္စမမြောက် check တစ်ခု ထပ်ထည့်ပါ—token မှာ သက်တမ်းကုန်ချိန် လုံးဝမသတ်မှတ်ထားခြင်း (neverExpires: true)။ ဒါကို ရှင်းလင်းတဲ့အကြောင်းပြချက်နဲ့ အမှားတစ်ခုအဖြစ် flag လုပ်ပါ၊ ပြီးရင် ဒီ field အသစ်ကို ထည့်ပြီး risky/safe example နှစ်ခုစလုံးကို ပြန် run ကြည့်ပါ။
သတိလေးတစ်ချက်
"debug လုပ်ဖို့သာ" ဆိုပြီး token ကို log လုပ်ပြီး၊ log ကိုယ်တိုင်က credential ရဲ့ သက်တမ်းရှည်ကူးယူမှုတစ်ခု ဖြစ်နေတာကို မေ့ခြင်း။
Secure, HttpOnly, SameSite ကို ရှင်းရှင်းလင်းလင်း သတ်မှတ်မထားဘဲ cookie တစ်ခုဟာ default အနေနဲ့ လုံခြုံတယ်လို့ ယူဆခြင်း။
OWASP Session Management Cheat Sheet — Digital Privacy & Modern Security