25/01/2025
Bug report writing tips for you guys !
Bug Hunting Tipတွေလဲတင်တာနည်းနည်းများနေပြီဆိုတော့ ဒီနေ့မှာ -
"Bug Report တစ်ခုကို အလွယ်တကူနဲ့ ထိထိရောက်ရောက်ဘယ်လိုရေးသင့်လဲ။ Reportတစ်ခုမှာ အရေးကြီးတဲ့အချက်တွေက ဘာတွေလဲ၊
ဘာကြောင့်လဲ?"
-ဆိုတဲ့ အကြောင်းအရာနဲ့ပတ်သက်ပြီး Beginnerနားလည်မယ့်ပုံစံမျိုးနဲ့ ရှင်းပြပေးပါမယ်
👨💻👨💻
ပထမဆုံးအနေနဲ့ Bug Reportတင်တဲ့အခါမှာ အဓိကပါ၀င်တဲ့အချက်တွေ ဘယ်နခုရှိမလဲဆိုတာအရင်ကြည့်ရအောင် -
1. Title
(ခေါင်းစဥ်)
2. Vulnerable URL Or Endpoint
(ယိုပေါက်ရှိနေတဲ့ url or endpoint)
3. Steps To Reproduce
(အဆင့်တစ်ခုစီ ရှင်းပြခြင်း)
4. Proof Of Concept[PoC]
(သက်သေပြခြင်း)
5. Affected payloads
(ထိုးဖောက်လို့ရစေတဲ့ code)
6. Impact Rating
(ယိုပေါက်ရဲ့ထိခိုက်နိုင်ခြေ)
7. Impact Detail
(ဘယ်လိုထိခိုက်မှုရှိနိုင်လဲ)
8. Mediation
(ကာကွယ်ရန် အကြံပေးခြင်း)
9. Kindly regards
(လေးစားစွာဖြင့် reportတင်ခြင်း)
10. Attach Poc Video or Screenshots
(သက်သေပြဖို့အထောက်အထားများထည့်ခြင်း)
-
အထက်မှာပြောပြခဲ့တဲ့ အချက် ၁၀ချက်ကတော့ Bug reportတစ်ခုမှာ မပါမဖြစ်ပါ၀င်တဲ့ အရေးကြီးတဲ့အချက်တွေဖြစ်ပါတယ်👨💻
ဒီအချက် ၁၀ချက်ကို အကျယ်တ၀င့် ရှင်းပြပေးပြီး reportရေးတဲ့အခါ ဘယ်လိုရေးသင့်ကြောင်းတွေကိူပါ
သိသလောက်ပြောပြပေးပါမယ်
ဆိုတော့ ပထမ အချက်ကို Bug reportမှာ စပြီးမရေးခင်မှာ အရေးကြီးတဲ့ အဆင့်တစ်ဆင့် ရှိပါတယ် -
အဲ့တာကတော့ ကိုယ်ရထားတဲ့ Bugတစ်ခုက တကယ့်
bugဆိုတာ ဟုတ်ရဲ့လား? မဟုတ်ဘူးလား? ဆိုတဲ့ Confirmation အဆင့်တစ်ခုပဲဖြစ်ပါတယ်။
ဒီအဆင့်က အခုမှစလုပ်တဲ့ Hunterတွေမှားလေ့ရှိတဲ့အဆင့်တစ်ခုပါ။
( ဥပမာ- javascript source codeထဲကနေ api_key ဆိုတဲ့ နောက်က valueတစ်ခုကိုတွေ့တိုင်း api key leakageဆိုပြီး ထင်နေတာမျိုးတွေပေါ့)
ဒီ confirmationအဆင့်ကို သိရှိဖို့ ကိုယ်ရထားတဲ့ bugကို ၃ကြိမ် ၃ခါလောက် ကိုယ်တိုင် manual testပြန်လုပ်ကြည့်ပါ။
ဒီလိုလုပ်ကြည့်တဲ့အခါမှာ စဥ်းစားရမယ့်အချက်တွေက-
1. ကိုယ်ရထားတဲ့ bugက owasp top 10မှာ ဘယ်အမျိုးအစားထဲမှာပါလဲ။
2. တကယ်ပဲ user or server sideအတွက် ထိခိုက်မှုရောရှိရဲ့လား၊ ကိုယ်တစ်ယောက်ထဲပဲ(self) သက်ရောက်မှုရှိနေတဲ့ bugတခုလား။
3. ဒီBugအမျိုးအစားကprogram ruleရဲ့ out of scope bugအမျိုးအစားထဲမှာပါနေလား။
ဒီအချက်၃ချက်ကို သေသေချာချာစစ်ပြီးလို့ ထိခိုက်နိုင်bugဆိုတာမသေချာရင်တော့ မတင်သင့်ပါဘူး N/A နဲ့တင် ပွဲသိမ်းခံရနိုင်ပြီး၊ ဒီထက်ပိုဆိုးရင် pointပါ အလျှော့ခံရနိုင်ပါတယ်။
တကယ် bugအစစ်ဖြစ်တယ်ဆိုတာ သေချာပြီဆိုရင်တော့ စလိုက်ကြရအောင် 👨💻-
No.1 : Title (ခေါင်းစဥ်) 🧠🧠
ဒီ Titleဆိုတဲ့အဆင့်ကတော့ Bugတစ်ခုတွေတဲ့အခါမှာ
အဲ့ဒီ Bugရဲ့ အမျိုးအစား(type)၊ ထိခိုက်နိုင်ခြေ(impact detail)၊ နည်းလမ်း(technique)၊ ယိုပေါက်တည်ရှိတဲ့နေရာ(vulnerable point) စတဲ့ အချက်အလက်တွေကို တစ်ကြောင်းထဲနဲ့ unique ဖြစ်အောင် ရေးဖို့ စဥ်းစားရပါမယ်။ ဥပမာ - ကိုယ်က log in form တစ်ခုမှာ reflected xssတစ်ခုရထားပြီး၊ အဲ့ဒီxssကနေတဆင့်
keyloggerတစ်ခုပြုလုပ်ပြီး userတွေရဲ့ username/passwordတွေကို ခိုးယူနိုင်တယ်ဆိုပါတော့ Titleမှာ -
Reflected XSS in login form can perform account takeover(ATO)
(translate : loging formမှာရှိတဲ့ rxssက atoလုပ်လို့ရနေတယ်)
ဒီလိုမျိုးပေါ့ - ကိုယ့်ရဲ့ယိုပေါက်တစ်ခုလုံးကို ခြုံပြီးတော့
တစ်ကြောင်းထဲနဲ့ uniqueဖြစ်ဖြစ်ရေးဖို့ပါ။
ဒီနေရာမှာ ရှင်းလဲရှင်းရမယ်၊ နားလည်လဲလွယ်ရမယ်၊ မှန်လဲမှန်ကန်ရမယ်။
ဒီအချက် ၃ခုက အဓိကပါ။
No.2 : Vulnerable Url or Endpoint ❗️❗️
ဒီအဆင့်ကတော့ ယိုပေါက်တည်ရှိနေတဲ့(ဖြစ်နေတဲ့)
url ဒါမှမဟုတ် apiဆိုရင် endpoint ကို copyကူးပြီး
ထည့်။ ကောင်းတာကတော့ url parameterမှာ ယိုပေါက်ရှိနေတာဆိုရင် vulnerableဖြစ်နေတဲ့ parameterရဲ့ value နေရာမှာ [] square bracketလေးထည့်ပြီး [vulnerable] or [vulnerable_area] ဆိုပြီးရေးရင် ပိုကောင်းတယ်။
အထက်က xss caseအတိုင်းပြောမယ်ဆိုရင် -
https://exam.com/login.html?text=[vulnerable]
အထက်ပါ ပုံစံအတိုင်းပေါ့။
No.3 : Steps To Reproduce 👨🏫👨🏫
ဒီအဆင့်ကတော့ အတော်လေး အရေးကြီးပါတယ်။ ဒီအဆင့်ကို ကြည့်ပြီး programရဲ့ developer teamတွေ bugcrowd ရဲ့validator (ယိုပေါက်စစ်ဆေးပေးသူ) တွေက စစ်ဆေးပြီး Bugဟုတ်မဟုတ်ဆိုတာကို စစ်ဆေးပေးတာကြောင့်မလို့ပါ။
ဒီအဆင့်မှာက English skillကောင်းစရာမလိုပါဘူး
စကားလုံးနည်းနည်းလေးနဲ့ ထိထိရောက်ရောက် သူတို့နားလည်အောင် ရှင်းပြပေးနိုင်ရင် ရပါပြီ။ သူတို့သေသေချာချာနားလည်သွားမှ ကိုယ့်အနေနဲ့ Bountyရဖို့သေချာမှာပါ။ မဟုတ်ရင် informational ဆိုတဲ့ statusနဲ့ reportကို closedသွားပါလိမ့်မယ်။
ဘယ်လိုရေးရမလဲဆိုတာကို အထက်ပါ XSS reportအနေနဲ့ပြောရမယ်ဆိုရင် -
Step To Reproduce
step1. Navigate to this url : https://exam.com/login.html?text=user_login
(အဆင့်၁ - ဒီ urlကို ၀င်ပါပေါ့)
step2. Then add the xss payload in the 'text' parameter's value
(အဆင့်၂ - xss payloadကို textဆိုတဲ့ parameterထဲမှာထည့်ပါ)
step3. then enter to that url, you will see the result of xss payload
(အဆင့်၃ - enterလိုက်ရင် xss payloadရဲ့resultကိုမြင်နေရပါလိမ့်မယ်ပေါ့)
အထက်ပါ အတိုင်း အလွယ်တကူနဲ့ရှင်းရှင်းလင်းလင်းရေးနိုင်ပါတယ်။
No.4 : Proof of Concept [PoC] 📠📠
ဒီအဆင့်ကတော့ အထက်က အဆင့်နဲ့အတူတူအရေးကြီးပါတယ်။ ရေးသားတဲ့ပုံစံကတော့ အထက်ကSteps to reproduceအဆင့်နဲ့ တူတယ်လို့ ထင်ရပေမယ့် တကယ်တမ်းဆို မတူပါဘူး။
Steps to reproduceဆိုတဲ့ အဆင့်က သူတို့ကို နားလည်အောင်ရှင်းပြရင်း ဘယ်လိုထည့်ပါ၊ ဘယ်လိုလုပ်ပါ၊ ဘယ်လိုလုပ်ရင် ဒီယိုပေါက်ကိုတွေ့နိုင်ပါတယ် ဆိုတာကို
သူတို့ကို confirmခိုင်းတဲ့အဆင့်ပါ။
ဒါပေမယ့် PoC အဆင့်ကတော့ ကိုယ်ကိုယ်တိုင်က ဘယ်လိုမျိုး exploitလုပ်ထားပါတယ်ဆိုတာကို သက်သေပြရမယ့်နေရာပါ။ ဒီနေရာမှာလဲ english skillအရမ်းရှိစရာမလိုလဲ ဖြစ်ပါတယ်။
လွယ်လွယ်ကူကူစကားလုံးတွေနဲ့ ရှင်းရှင်းလင်းလင်းဖြစ်အောင်ရေးပါ။
အထက်ပါ XSS reportကိုပဲ ဥပမာအနေနဲ့ pocနေရာကိုရေးပြပါမယ်။
Proof Of Concept(PoC)
step1. When i logged in my account, i found a login page url containing 'text' parameter.
(ငါ့အကောင့်ကို login၀င်ခဲ့တုန်းက login pageမှာ textဆိုတဲ့ parameterကိုတွေ့ခဲ့တယ်)
step2. Then, i changed the 'text' parameter value
"user_login" to "x
"
(အဲ့ဒီနောက်မှာ ငါ text valueကို user_loginဆိုတာကနေ xss payloadကို ပြောင်းလဲလိုက်တယ်)
step3. then, i got a prompt called 'xss'
(အဲ့နောက်မှာ xssလို့ခေါ်တဲ့ promptတစ်ခုကို ငါရခဲ့တယ်)
အထက်ပါ ပုံစံ ရှင်းရှင်းလင်းလင်းလေး ရေးနိုင်ပါတယ်။ PoC နဲ့ Step To Reproduceရဲ့ရေးသားပုံကို ပြန်ယှဥ်ကြည့်ပါ။ Step to reproduceက ခိုင်းတဲ့သဘောနဲ့ ရေးထားတာဖြစ်ပြီး၊ PoCကတော့ ကိုယ်တိုင်လုပ်ခဲ့တာကို ရေးထားတာဆိုတာ သိသာစေပါတယ်။
No.5 : Affected Payload 💉💉
ဒီအဆင့်ကတော့ Reporterတော်တော်များများက သီးသန့်ခွဲပြီးရေးမနေပဲနဲ့ PoC stepတွေမှာပဲ payloadတွေကို တန်းထည့်ပြီးရေးတတ်ကြပါတယ်။ အဲ့လိုထည့်ရေးလဲရပါတယ်။ ဒါပေမယ့် ကျွန်တော်ကိုယ်တိုင်က Affected payloadဆိုပြီး Titleတစ်ခုနဲ့ခွဲရေးရတာကို ပိုသဘောကျပါတယ်။
ဥပမာ - XSSတစ်ခုကို excuteလုပ်တဲ့အခါမှာ web serverက waf( web app firewall ) ခံထားတယ်ဆိုပါတော့၊ အဲ့ဒီလို wafတွေကို bypassပြီးpayloadထည့်တဲ့
အခါမှာ ဘယ်payloadကတော့ ထည့်လို့ရပြီး၊ ဘယ်payloadကတော့ wafရဲ့ blockတာ ခံရတယ်ဆိုတာမျိုးကို သီးသန့်ပြောပြချင်လို့ပါ။
ဥပမာ- အထက်က XSS caseမှာဆို
Affected Payloads -
alert(1) (blocked by waf)
(blocked by waf)
(bypassed)
အထက်ပါအတိုင်း Wafရဲ့ blockတာခံရတဲ့ payloadတွေနဲ့ သုံးလို့ရတဲ့payloadကို ခွဲခြားပြီး ရေးလို့ရတာကြောင့်မလို့ Affected payloadကို သီးသန့်ခွဲပြီးရေးရတာကို သဘောကျတာ ဖြစ်ပါတယ်။
No.6 : Impact Rating ⭕️⭕️
ဒီအဆင့်ကတော့ ကိုယ်တွေ့တဲ့ ယိုပေါက်ရဲ့
ထိခိုက်နိုင်ချေအတိုင်းအတာကိုရေးရမှာဖြစ်ပါတယ်။
ဒီအဆင့်ကိုရေးဖို့အတွက် ကိုယ့်ရဲ့ bugက ဘယ်လောက်အဆင့်ထိ ထိခိုက်စေနိုင်လဲ၊ user sideကိုပဲထိခိုက်စေတာလား၊ server sideကိုထိခိုက်စေတာလား စတဲ့ အချက်တွေကတဆင့် စဥ်းစားရပါတယ်။
ဥပမာ - IDORကနေ user accountတွေအကုန်လုံးကို useridတွေသိတာနဲ့ DELETEလုပ်လို့ရနေတယ်ဆိုပါတော့။ useridက 1,2,3,4 ဆိုပြီး အလွယ်တကူ bruteforceတိုက်လို့ရနေတဲ့ idလား?? ဒါမှမဟုတ်ရင်
hashနဲ့ရေးထားတဲ့ userid လား?? ဆိုတဲ့အပေါ်မှာ မူတည်ပြီး - bruteforceတိုက်လို့ရနေတဲ့ useridရှိနေတယ်ဆိုရင်တော့ ဒီ IDOR bugက critical or highဖြစ်နိုင်ပြီးတော့၊ bruteforceတိုက်လို့မရပဲ uniqueဖြစ်နေတဲ့ useridဆိုရင်တော့ low or mediumနဲ့ပဲ တင်လို့ရပါလိမ်မယ်။
ဒီimpact ratingအဆင့်က အချို့ platformတွေမှာဆိုရင် သူတို့ရဲ့ standardထားထားတဲ့ cvss scoreတွေ နဲ့အခြား rating systemတွေနဲ့ ဆုံးဖြတ်ပေးထားတယ်ဆိုပေမယ့်။ ကိုယ်ရဲ့Bugရဲ့ impactကတော့ ကိုယ်ကိုယ်တိုင် သေသေချာချာ confirmလုပ်ပြီး reportမှာ ထည့်ပြီး ရေးတာက ပိုကောင်းပါတယ်။
No.7 : Impact Detail 💾💾
ဒီအဆင့်မှာတော့ ထိခိုက်နိုင်ခြေအကြောင်းကို သေသေချာချာ detailကျကျရေးရပါမယ်။ ဥပမာ - ခုနကxssမှာဆို javascript codeနေရာမှာ prompt() ဆိုတာကို မသုံးပဲ Login formနေရာမှာရတဲ့ xssဖြစ်တဲ့အတွက်ကြောင့် Key logger scriptတစ်ခုခုကိုသာ ထည့်ပြီး executeလုပ်လိုက်မယ်ဆိုရင် victim userရဲ့ username တွေ passwordတွေကို attackerက ရရှိနိုင်ကြောင်းကို ရေးသင့်ပါတယ်။ Command injection bugရခဲ့တယ်ဆိုရင်လဲ ဒီအဆင့်ကနေ Network pivottingတွေ အဆင့်ထိ ဘယ်လိုသွားလို့ရတယ်ဆိုတာတွေပါ ထည့်ရေးရင်ပိုကောင်းပါတယ်။
No.8 : Mediation 🛡️🛡️
ဒီအဆင့်ကတော့ ကိုယ်bugတင်တဲ့ programရဲ့
Dev Teamကို ဒီBugကို ဘယ်လိုမျိုး fixလုပ်သင့်တယ် ဆိုတဲ့အကြောင်းကိုရှင်းပြရမယ့် အဆင့်ပါ။
ဥပမာ - ခုနက XSS reportအရဆို
Mediation
- add a strong server side validation in 'text' parameter's value
အထက်ပါပုံစံအတိုင်း text parameterမှာ ခိုင်ခံ့တဲ့ server sideစစ်ထုတ်ခြင်း ကို တပ်ဆင်သင့်ကြောင်း ပြောပြနိုင်ပါတယ်။
ဒီအဆင့်လေးပါရင် Programတွေက ပိုပြီးသဘောကျတာကြောင့်မလို့ မေ့မနေပဲ ထည့်ရေးသင့်ပါတယ်။
No.9 : Kindly Regards 🙇♂️🙇♂️
ဒီအဆင့်ကတော့ Reportတစ်ခုရဲ့ အထက်ပါအဆင့်တွေ အကုန်ရေးပြီးသွားတဲ့အခါမှာ endingအနေနဲ့ လေးစားစွာနဲ့ reportတင်လိုက်ပါတယ်ဆိုပြီး ပြောတဲ့အနေနဲ့ reportရဲ့အဆုံးမှာ -
Kindly regards,
[Nickname]
ဆိုပြီး Nicknameနေရာမှာ ကိုယ့်ရဲ့ nicknameကိုထည့်ပြီး Reportရေးတာကို အဆုံးသတ်နိုင်ပါတယ်။
No.10 : Attach PoC video or screenshots 📸🎥
Reportရေးပြီးသွားပြီဆိုရင် ကိုယ်Exploitလုပ်တုန်းက ဘယ်လိုexploitလုပ်ထားတယ်
ဆိုတာကို Program ရဲ့ teamတွေကို သက်သေပြဖို့အတွက် recordယူထားတဲ့ PoC videoဖြစ်စေ၊ PoC screenshotလေးတွေဖြစ်စေ PoC attachments
အနေနဲ့ Uploadတင်ပြီးမှ Reportကို တင်လိုက်ပါ။
အချို့ Programတွေက PoC screenshotတွေ PoC videoတွေ တစ်ခုခုမပါဘူးဆိုရင် အရမ်းအငြင်းသန်တာကြောင့်မလို့ပါ။
-
| အထက်က အဆင့်10ဆင့်ကို အစဥ်လိုက်သေသေချာချာရေးပြီး Reportတစ်ခုကိုကောင်းကောင်းတင်နိုင်ပါတယ်|
-
အထက်ပါ အဆင့်10ဆင့်ကတော့ Beginnerတွေအနေနဲ့ Bug report တစ်ခုကို ရေးတဲ့အခါမှာ သိထားသင့်တဲ့ Tipတွေ Trickတွေကို အဆင့်အလိုက် သေသေချာချာရှင်းပြပေးခဲ့တာဖြစ်ပါတယ်။
ဒီအဆင့် ၁၀ဆင့်ကို သေသေချာချာ နားလည်ရင်ပဲ Localပဲလာလာ Globalပဲလာလာ Bug reportရေးပြီးတင်နိုင်မှာပဲဖြစ်ပါတယ်🧞♂️
Thanks for reading & have a great bug hunting !
