Web application ေတြအတြက္ attacker ေတြအသံုးမ်ားတဲ႔ နညး္တစ္ခုျဖစ္တဲ႔ CSRF (cross-site request forgery) အေၾကာင္းကို ေရးပါမယ္။
one-click attack သို႔မဟုတ္ session riding လို႔လည္း သိၾကပါတယ္။sea-surf လို႔တစ္ခါတစ္ေလ အသံထြက္တယ္လို႔လည္း မွတ္သားရပါတယ္။
CSRF attack အေၾကာင္းအရင္ရွင္းျပပါမယ္။
သင္ဟာ web application တစ္ခုကိုသံုးေနတယ္ဆိုပါဆို႔။ အဲဒီ application ကိုသံုးဖို႔အတြက္ ပထမဆံုး login ၀င္ဖို႔လိုပါမယ္။ အဲဒီေနာက္ သင္႔ password ေျပာင္းတာ၊ file အသစ္ေတြတင္တာ ၊ download လုပ္ခြင့္ရွိမယ္လို႔ယူဆၾကပါစို႔။ ဒါဆို ဒီ application ဟာ file upload download ကို user တစ္ဦးခ်င္းစီအတြက္ အလုပ္လုပ္ေပးေနပါတယ္။
user မဟုတ္တဲ႔ သူကိုေတာ႔ ေပးမ၀င္ပါဘူး။attacker ဟာ သင္မဟုတ္ေပမယ့္ သင္ကဲ႔သို႔ ဟန္ေဆာင္ကာ password ကိုေျပာင္းတာလုပ္ႏုိင္ပါတယ္။ file တင္တာေတြလည္းလုပ္ ႏိုင္ပါတယ္။
CSRF attack လုပ္ဖို႔အတြက္ ပထမဆံုးအေနနဲ႔ေတာ႔ တကယ့္ user တစ္ေယာက္ ရဲ႕ request ေတြကိုေတာ႔ အတိအက်သိထားရပါတယ္။ password ေျပာင္းမယ္ဆိုရင္ ဘယ္လို URL ဘယ္လို form data ဘယ္လို method ေတြသံုးတယ္ကို ၾကိဳသိဖို႔ေတာ႔လိုအပ္ပါမယ္။ဒါကလည္း attacker ကိုယ္တုိင္ account တစ္ခုလုပ္ခြင့္ ရွိသြားရင္ အားလံုး သိႏိုင္သြားျပီျဖစ္ပါတယ္။ဘာေၾကာင့္လဲဆိုေတာ႔ user အားလံုးရဲ႕ password ေျပာင္းမယ့္ url နဲ႔ form data ျပီးေတာ႔ method ေတြက အတူတူျဖစ္ေနလို႔ပါပဲ။ တစ္ေယာက္တစ္မ်ိဳးေရးေပးဖို႔လည္း မျဖစ္ျပန္ပါဘူး။
example: http://mywebapp.com/user/changepwd ?password=newpass&confirmpwd=newpass
ဘယ္လို လုပ္သြားလဲကိုဆက္ရွင္းပါမယ္။ CSRF attack လုပ္ခံရမယ့္ သူဟာ အဲဒီ application ကို သူ႔ရဲ႕ ကိုယ္ပိုင္ username ,password နဲ႔ login ၀င္ထားျပီးသားျဖစ္ရပါမယ္။ application တစ္ခုကို သင္login ၀င္ ခဲ႔ျပၤီဆိုပါဆို႔ password ေျပာင္းတာနဲ႔ အျခားအရာေတြကို လြပ္လြပ္လပ္လပ္ လုပ္လို႔ရသြားျပီျဖစ္ပါတယ္။ဒါေၾကာင့္ တစ္ခုခုလုပ္မယ္ဆိုရင္ username password ျပန္ေရးေပးေနရ တာမ်ိဳး မရွိေတာ႔ပါဘူး။ဒါေၾကာင့္ တစ္ခါ login ၀င္ျပီးသြားတာနဲ႔ အဲဒီ သူကို ယံုၾကည္ရေသာ account ပိုင္ရွင္အစစ္လုိ႔ယူဆသြားပါတယ္။အဲဒီမွာ attack လုပ္ခံရေတာ႔တာပါပဲ။
ဒါေၾကာင့္ attacker ဟာ သင္ရဲ႕႔ login ၀င္ထားျပီးသား အေျခအေနကို အသံုးခ်ျပီး သူျပဳလုပ္လိုတဲ႔ request ေတြကို သင္႔အေနနဲ႔ ျပဳလုပ္မိေအာင္ဖန္တီးေတာ႔မွာျဖစ္ပါတယ္။
အေပၚမွာပါတဲ႔ example link ကိုၾကည့္ပါ။password ေျပာင္းဖို႔အတြက္ အဲဒီ link ကို run လိုက္ရင္ ရျပီဆိုတာသိသာပါတယ္။ဒါေပမယ့္ login ၀င္ထားမွ ရႏိုင္မွာျဖစ္ပါတယ္။ဒါဆို login ၀င္ထားျပီးသားသူကို မိမိလိုခ်င္တဲ႔ password ေျပာင္းေစမယ့္ link request ကို run ေစေအာင္ ဘယ္လိုလုပ္မလဲ။
အမ်ားအားျဖင့္ email နဲ႔ chat box သို႔မဟုတ္ fake web page ဖန္တီးျပီး လုပ္ေလ႔ရွိပါတယ္။သင္စိတ္၀င္စားမယ့္ အေၾကာင္းအရာေတြကို ေဖာ္ျပထားတဲ႔ အခါမွာ သင္ဟာစိိတ္၀င္စားစြာ ၀င္ၾကည့္မွာေသခ်ာပါတယ္။
ဥပမာ ဖုန္းေဘလ္ တစ္ႏွစ္စာ အလကား ရမယ့္ကံစမ္းခြင့္ လို page မ်ိဳး ။ဘယ္လိုလဲ စိတ္၀င္စားမယ္မဟုတ္လား။ဒါဆို သင္၀င္ၾကည့္မွာေသခ်ာတယ္။အဲဒီအခါ သူေထာင္ေခ်ာက္ထဲေရာက္သြားပါျပီ။ဒါေပမယ့္ ဒီအႏၱရာယ္ကေနကာကြယ္ဖုိ႔က အသံုးျပဳတဲ႔ user မဟုတ္ပါဘူး။ attacker ကေန တိုက္ခုိက္လိုတဲ႔ web application ဘက္က မိမိ user ေတြအတြက္ ကာကြယ္ေပးရမွာပါ။
attacker ေတြက web page သို႔မဟုတ္ email ေတြမွာ attack လုပ္မယ့္ link ကို image အေနနဲ႔ ထည့္တတ္ၾကပါတယ္။ image tab ရဲ႕ src attribute မွာ attack link ကို ထည့္လိုက္ျခင္းအားျဖင့္ အဲဒီ web page သို႔မဟုတ္ email ကို ဖြင့္လိုက္တဲ႔အခါ image ရဲ႕ source data ကို ရယူဖုိ႔ request လႊတ္ေပးလိုက္တဲ႔အခါ attacking ျဖစ္သြားပါတယ္။ဒါေပမယ့္ browser ကလည္း ရိုးရိုး request တစ္ခုလို႔ပဲ ျမင္မွာပါ။
example:
<img src="http://mywebapp.com/user/changepwd ?password=newpass&confirmpwd=newpass" alt="logo"/>
တစ္ခ်ိဳ႕ request ေတြက POST method နဲ႔ သံုးထားတဲ႔အခါမွာေတာ႔ အထက္ကနည္းဟာ အဆင္မေျပေတာ႔ပါဘူး။အထက္ကနည္းဟာ get method သံုးထားတဲ႔ form request ေတြကို attack လုပ္ရာမွာေတာ႔အဆင္ေျပႏိုင္ပါတယ္။
ေနာက္တစ္မ်ိဳးအေနနဲ႔ post method ကို လႊတ္ႏိုင္ဖို႔ fake web page ကိုတည္ေဆာက္ၾကျပန္ပါတယ္။အဲဒီ web page ထဲမွာ Iframe တစ္ခုပါေနပါမယ္။ အဲဒီ Iframe ကေန form page တစ္ခုကို load ေခၚေပးပါမယ္။ အဲဒီ form ကို javascript နဲ႔ auto submit ျဖစ္ေစေအာင္ ေရးထားပါတယ္။ဒါဆိုရင္ user ဟာ အဲဒီ web page ကို ၀င္ၾကည့္မိတာနဲ႔ iframe ထဲက form ဟာ submit ျဖစ္သြားမွာျဖစ္ပါတယ္။ submit လုပ္တဲ႔အတြက္ redirect လုပ္သြားတာကို မသိေစရန္အတြက္ iframe ကို hidden လုပ္ထားပါေသးတယ္။
အဲဒီ form ရဲ႕ request ေၾကာင့္ သင့္ password ဟာေျပာင္းသြားျပီျဖစ္ပါတယ္။
ဒီေလာက္ဆိုရင္ CSRF attack ဘယ္လို လုပ္သလဲဆိုတာသိေလာက္မယ္ထင္ပါတယ္။တကယ္ေတာ႔ user ကိုယ္တိုင္က ကိုယ္႔ျပႆနာ ကိုယ္ရွာမိေစတာမ်ိဳး ျဖစ္ေအာင္ လုပ္ထားတာပါ။
Protection for CSRF
attack လုပ္ႏိုင္တာကိုသိ ျပီဆိုရင္ protect လည္းလုပ္ႏိုင္ေအာင္ ၾကိဳးစားၾကရပါမယ္။ server ဟာ user login ၀င္ျပီးသြားတာနဲ႔ အဲဒီ computer ရဲ႕ သံုးလိုက္တဲ႔ browser ကို ယံုၾကည္စြာလက္ခံထားပါတယ္။အဲဒီအားနည္းခ်က္ေၾကာင့္ အျခား attack link ေတြကို အဲဒီ browser ကေန လႊတ္ေပးျခင္းအားျဖင့္ ဘယ္သူဘယ္၀ါ မခြဲျခားပဲလက္ခံလိုက္ျခင္းျဖစ္ပါတယ္။ကာကြယ္ရန္ အသံုးမ်ားတဲ႔နည္းကေတာ႔ CSRF token ပဲျဖစ္ပါတယ္။user တစ္ေယာက္အတြက္ session တစ္ခုကို စတင္ေပးလိုက္တာနဲ႔ ခန္႔မွန္းရက္အလြန္ခက္ခဲတဲ႔ long cryptographic values တစ္ခုကို random ဖန္တီျပီး အဲဒီ user ရဲ႕ session အေနနဲ႔ သိမ္းထားေပးပါတယ္။အဲဒီေနာက္ user ရဲ႕ form တိုင္းမွာ အဲဒီ token ကို hidden အေနနဲ႔ ပါ၀င္ေနေစပါတယ္။ အဲဒီ form submit လုပ္လိုက္တဲ႔အခါ CSRF token ဟာ server သို႔ျပန္လည္ေရာက္ရွိလာပါတယ္။ အဲဒီေနာက္ လက္ရွိ login ၀င္ထားတဲ႔ user ရဲ႕ CSRF token နဲ႔ တိုက္စစ္ျပီး မွန္ကန္မွသာ request ကိုဆက္လုပ္မွာျဖစ္ပါတယ္။
attacker အေနနဲ႔ fake web page တစ္ခုမွာ form ဖန္တီးႏိုင္ေပမယ့္ အဲဒီ user ရဲ႕ CSRF token ကိုေတာ႔ သိႏိုင္မွာမဟုတ္ပါဘူး။ဘာလို႔လည္းဆိုေတာ႔ token ေတြဟာလည္း user တစ္ဦးနဲ႔တစ္ဦးမတူတဲ႔အတြက္ မသိႏိုင္ေတာ႔ပါဘူး။ျပီးေတာ႔ session တစ္ခုတိုင္းမွာလည္း အသစ္ျပန္ေျပာင္းသြားတဲ႔အတြက္ ခန္႔မွန္ရန္ခက္ခဲသြားမွာျဖစ္ပါတယ္။
ေနာက္တစ္မ်ိဳးအေနနဲ႔ form request တစ္ခုတိုင္းမွာ csrf token ကို ေျပာင္းလဲပစ္လိုက္တာမ်ိဳးျဖစ္ပါတယ္။
ဒါေၾကာင့္ attacker အတြက္ ခန္႔မွန္းဖို႔ ပိုမိုခက္ခဲသြားပါတယ္။ဒါေပမယ့္ အသံုးျပဳတဲ႔ application user အတြက္လည္း အခက္အခဲေတြရွိလာ ပါေသးတယ္။ form submit ကို reload လုပ္ခြင့္ မရွိတာမ်ိဳး နဲ႔ ajax request ေတြအတြက္ ခက္ခဲတာမ်ိဳးေတြ၇ွိလာျပန္ပါတယ္။
<form action="https://example.com/tweet" method="POST"> <input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn"> <input type="text" name="tweet"> <input type="submit"> </form>Password ေျပာင္းႏိုင္တဲ႔ form တစ္ခု ဖန္တီးရာမွာလည္း old password ကို ျပန္ေတာင္းျခင္းျဖင့္ CSRF ကို ပိုမိုကာကြယ္ေပးႏိုင္ပါတယ္။
ဒါေလာက္ဆို ေယဘူယ်ေလာက္ေတာ႔ သိႏိုင္မယ္ထင္ပါတယ္။ေက်းဇူးတင္ပါတယ္။
EmoticonEmoticon