ကျွန်တော်တွေ့ဖူးသော Backend Security အလွဲများ

ကျွန်တော် ရေးဖူးတဲ့ Project တွေ / ယူဖတ်ဖူးတဲ့ code တွေမှာ တွေ့ခဲ့ရဖူးတဲ့အထဲက Security အလွဲလေးတွေကို ပြန်ပြီး မျှဝေပေးချင်ပါတယ်။ ကျွန်တော်ရေးဖူးတဲ့ Project တွေထဲမှာတော့ တွေ့တာတွေ ပြင်ထားပြီးပြီနော် (သွားစမ်းနေမှာစိုးလို့ ကာရသေးတယ် :3)။

1. Block SQL injection by base 64 encode

   တစ်ချို့ developer တွေက URL ကို base64 encode လုပ်လိုက်ရင် SQL Inject လုပ်လို့မရတော့ဘူးလို့ ထင်တတ်ကြတယ်။ တကယ်က အဲ့တာ ဘာမှ မဆိုင်ဘူးနော် attacker တွေက Encode/Decode ကို developer တွေထက် အများကြီးကျွမ်းပါတယ်။ ဒါကြောင့် ဒီလို ပေါက်ကရလုပ်မဲ့အစား သေချာလုံခြုံအောင်ရေးရပါမယ်။

2. XSS protection responsible is only for frontend developers

   ဒါကြီးကလဲ အလွဲကြီးပဲ backend developer တွေ interview မှာ XSS ကိုဘယ်လို ကာကွယ်မလဲမေးလိုက်ရင် ဖြေတတ်ကြရင်တောင် ကိုယ်တိုင် protect လုပ်ခဲ့တဲ့သူတွေက နည်းတယ်။ XSS ကိုကာကွယ်ဖို့က နှစ်ဖက်စလုံးမှာ တာဝန်ရှိပါတယ်။ ဒါကြောင့် backend ကလည်း string တွေကို မသိမ်းခင် XSS code တွေ ပါမလာဖို့ သေချာစီစစ်ရပါမယ်။

3. OTP verify by frontend

   ဒါမျိုးလည်းတွေ့ဖူးတယ် OTP ကို response ထဲ ထည့်ပေးလိုက်ပြီး frontend ရောက်မှ တိုက်စစ်တာမျိုးပေါ့။ ဒါမျိုးကတော့ လုံးဝ မလုပ်သင့်တာမျိုးပါ။ လုပ်တဲ့သူလည်း တကယ်ရှိတယ်နော် :D။ Response ထဲမှာ လျှို့ဝှက်ကုတ်တွေ လုံးဝ ထည့်မပေးသင့်ပါဘူး။

4. အမှားနှစ်ခုပေါင်းရင် အမှန်

   ဒါမျိုးက သတိမူဂူမမြင်ဆိုတာမျိုး၊ သတိမထားမိရင် ဖြစ်တတ်ပြီး အန္တရာယ်ရှိတဲ့ ကိစ္စမျိုးပါ။ ဥပမာ အောက်နမူနာကကုတ်ကို ဖတ်ကြည့်ပါ။ verify လုပ်တဲ့ ဖုန်းရဲ့ OTP ကလည်း cache ထဲမှာ ရှိမနေဘူး၊ request ထဲမှာလည်း OTP ပါမလာဘူးဆိုရင် true လို့ return ပြန်သွားမှာပါ။ ဒါမျိုးရေးမဲ့အစား cache ထဲမှာ OTP ရှိ/မရှိ အရင်စစ်သင့်ပြီး request ထဲမှာလည်း OTP ပါဖို့ သေချာစစ်သင့်ပါတယ်။

    public static function otpVerify($request): bool
    {
        $cacheKey = 'otp_' . $request->phone;
        return Cache::get($cacheKey) == $request->otp;
    }
   

5. Trusting on pre-checked credentials

   ဒါမျိုးကလည်း အတွေ့အကြုံနည်းသေးတဲ့ အချို့ developer တွေ လုပ်တာ တွေ့ရဖူးပါတယ်။ OTP ကို frontend မှာ check တာမျိုးနဲ့ နည်းနည်းတော့တူတယ်။ သူက ဘယ်လိုလွဲတာလည်းဆိုတော့
   User pin မှန်လားလို့ backend ကို လှမ်းစစ်တယ် မှန်တယ်လို့ response ရတယ်ဆိုရင် next endpoint ကို ထပ်ခေါ်တယ် အဲ့မှာကျ pin ကို ပြန် မစစ်တော့တာမျိုးပေါ့။ attacker က ပထမ response ကို ပြင်လိုက်မယ်ဆိုရင် pin မသိပဲ bypass လို့ရသွားမှာပါ။ ဒါမျိုးလုပ်မဲ့အစား တကယ့် action လုပ်မဲ့ endpoint ကိုပဲ pin ပါထည့်ခေါ်ပြီး backend က တစ်ခါတည်းစစ်ပြီးမှ action ကို လုပ်ပေးတာက ရေးရတာလည်း ပိုသက်သာပြီး လုံခြုံရေးအရလည်း ပိုကောင်းပါတယ်။

6. Not checking hash on payment webhook

   ဒီတစ်ခုကတော့ အရမ်းအရေးကြီးပါတယ်။ Payment system တွေနဲ့ ချိတ်ဆက်တဲ့အခါမှာ။ ကိုယ့်ဘက်က webhook တစ်ခု ထုတ်ပေးရပါတယ်။ Payment server ဘက်မှာ payment success ဖြစ်သွားတဲ့အခါမှာ ကိုယ့်ဘက်က webhook ကို ခေါ်ပြီး ငွေပေးချေမှု အောင်မြင်ကြောင်း အသိပေးပါတယ်။ အဲ့ post request ထဲမှာ order id, payemnt ammount စနဲ့ အချက်အလက်တွေနဲ့အတူတူ အဲ့ဒီအချက်အလက်တွေကို secret key နဲ့ ပေါင်းပြီး hash ထားတဲ့ verification string တစ်ခု ပါပါတယ်။ ကိုယ့်ဘက်က လက်ခံတဲ့ webhook မှာ payment info တွေကို ဘဏ်ဘက်က လုပ်တဲ့အတိုင်း ပြန်စီ၊ secret key နဲ့ပေါင်းပြီး hash ပြန်လုပ်ရပါတယ် ပြီးတော့မှ hash နှစ်ခု တူမတူ စစ်ပြီး မှန်ကန်တော့မှ processing ဆက်လုပ်ရပါတယ်။ အဲ့နေရာမှာ hash verify မလုပ်ပဲ လက်ခံမိတဲ့အခါမှာ attacker က အချက်အလက်အတုတွေပို့ပြီး ကိုယ့် ရဲ့ ရောင်းကုန်တွေကို ငွေမပေးပဲနဲ့ ရယူသွားနိုင်တယ်။ အဲ့လို ပေါ့ဆတဲ့ Developer တကယ် မရှိဘူးလို့ မထင်ပါနဲ့ မကြာသေးတဲ့ ကာလမှာမှ နာမည်ကြီး ကျောင်းတစ်ကျောင်းမှာ အဲ့လိုပေါက်နေလို့ Report လုပ်တဲ့ bounty hunter ကို bounty တော်တော် ပေးလိုက်ရသေးတယ် ကြားပါတယ်။

စိတ်ကူးရှိတုန်း ခေါင်းထဲ လောလောဆယ် မှတ်မိသလောက်ရေးချလိုက်တာပါ။ နောက်မှတ်မိတာတွေ ရှိရင်လည်း ထပ်ဖြည့်ပေးပါအုံးမယ်။