ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်
Stored XSS — attacker ရေးတဲ့ script ကို database ထဲ သိမ်းပြီး page ကို ဝင်ကြည့်တဲ့သူတိုင်းအတွက် run ဖြစ်ပါတယ် (ဥပမာ comment section)။ Reflected XSS — malicious link ကို victim click လိုက်တာနဲ့ URL parameter ထဲက script ချက်ချင်း run ဖြစ်ပါတယ်။ Script run ဖြစ်သွားရင် victim ရဲ့ cookie/session token ကို steal လုပ်နိုင်ပြီး victim ဟန်ဆောင်ပြီး account ကို access လုပ်နိုင်ပါတယ်။
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Comment box ထဲ <script>alert('hacked')</script> ရိုက်ထည့်ပြီး page ပေါ် raw HTML အဖြစ် render ဖြစ်သွားရင် XSS vulnerability ရှိတယ်ဆိုတာ သိနိုင်ပါတယ် (harmless alert box နဲ့ testing)။ Defense method — output encoding (user input ကို page ပေါ်ပြသခင် HTML entity အဖြစ် escape လုပ်ခြင်း, <script> ကို <script> လို ပြောင်းခြင်း) နဲ့ Content Security Policy (CSP) header သတ်မှတ်ခြင်းက script run ခွင့်ကို ကန့်သတ်ပေးပါတယ်။
အတူတူ ကြည့်မယ်
<!-- Vulnerable: user input rendered as raw HTML -->
<div>Comment: <script>alert('hacked')</script></div>
<!-- Safe: output-encoded -->
<div>Comment: <script>alert('hacked')</script></div>
<!-- Browser displays the text literally instead of running it -->XSS payload တစ်ခုက ဘယ်လို run ဖြစ်တယ်၊ output encoding က ဘယ်လို ကာကွယ်ပေးတယ်ဆိုတာ ရှင်းပြနိုင်မည်။၅ မိနစ် စမ်းကြည့်
Comment/feedback form ရှိတဲ့ website (permission ရှိသူ့ ပိုင်ဆိုင်တာ ဒါမှမဟုတ် intentionally vulnerable practice site) မှာ harmless <script>alert(1)</script> testing ကို concept-level ဖော်ရေးကြည့်ပါ (production site မှာ တကယ်မစမ်းရ)။
သတိလေးတစ်ချက်
Permission မရှိတဲ့ website ပေါ်မှာ XSS payload ကို 'စမ်းကြည့်' ခြင်းသည် တရားဥပဒေအရ ပြစ်မှုဖြစ်နိုင်ပါတယ် — ကိုယ်ပိုင် test environment ဒါမှမဟုတ် bug bounty program ခွင့်ပြုထားတဲ့ site မှာသာ practice ပါ။