လမ္းၫြန္
XSS ဆိုတဲ့ Cross Site Scripting Attack ဟာ Web Site ေတြရဲ႕ လုံၿခဳံေရးဆိုင္ရာအားနည္းခ်က္ (vulnerabilities) ေတြကတဆင့္ Web Site ရဲ႕ Structure ထဲကို Java Script ေတြကို Attacker (Hacker) ေတြက ထည့္သြင္း
အသုံးျပဳနိုင္တဲ့ Attack တစ္မ်ိဳး ျဖစ္ပါတယ္။ လုံၿခဳံေရးဆိုင္ရာ အားနည္းခ်က္ (vulnerabilities) အမ်ားစုဟာ XSS (သို႔မဟုတ္) Cross-Site Scripting ရန္မွ ကာကြယ္မႈကို ေဆာင္႐ြက္သည့္အခါ Web Developer မ်ားဘက္မွ
၄င္းတို႔၏ Web Site ကို XSS ေပ်ာ့ကြက္မ်ား ျဖစ္ေပၚမလာေစရန္ လိုအပ္ေသာ အကာအကြယ္မ်ားဖန္တီးျခင္း၊ User မ်ားမွ ထည့္သြင္းလိုက္ေသာ အခ်က္အလက္မ်ားကို စိစစ္ လက္ခံျခင္း အစရွိသည့္ ေဆာင္႐ြက္မႈ မ်ား ကို ျပဳလုပ္ရမည္ ျဖစ္ပါသည္။
ရည္႐ြယ္ခ်က္မ်ားမွာ-
♦ Web page တြင္ Cross-Site scripting ေၾကာင့္ျဖစ္ေပၚလာနိုင္ေသာ လုံၿခဳံေရးဆိုင္ရာ
အားနည္းခ်က္ (vulnerabilities) မ်ားကိုသိရွိ နားလည္နိုင္ေစရန္။
♦ Cross-Site Attacks ျဖစ္ေပၚလာလွ်င္ အက်ိဳးသက္ေရာက္္နိုင္ေသာ
အားနည္းခ်က္ ေျဖရွင္းနည္းမ်ားကိုသိရွိထားရန္။
♦ Regular e×pression မ်ား၊ အမ်ိဳးအစားမ်ားကိုအသုံးျပဳ၍ ကန့္သတ္ထားေသာ input
အားနည္းခ်က္မ်ားကို စစ္ေဆးျခင္းႏွင့္ ASP.NET ရဲ႕ validator controls မ်ားျပဳလုပ္ျခင္း။
♦ Browser တြင္ Script code ပါတဲ့ HTML tag ကို e×ecute မလုပ္နိုင္ရန္ ကန့္သတ္ထားရန္
♦ အနတရာယ္ရွိသည္ဟု ယူဆနိုင္ေသာ HTML tags မ်ား၊ attributes မ်ားကို review
အားနည္းခ်က္ လုပ္ရန္ႏွင့္ ေျဖရွင္းရန္နည္းလမ္းမ်ားကို သိရွိနားလည္နိုင္ေစရန္တို႔ျဖစ္ပါသည္။
သုံးသပ္ခ်က္
XSS ဆိုတဲ့ Cross Site Scripting Attack ဟာ Web Site ေတြရဲ႕ လုံၿခဳံေရး ဆိုင္ရာ အားနည္းခ်က္ (vulnerabilities) ေတြက တဆင့္ Client-side script code ေတြနဲ႕ စတင္ လုပ္ေဆာင္ပါတယ္။ အဲဒီ script code ေတြက User ကို သပၤာမကင္း မျဖစ္ေစတဲ့အတြက္ User က သံသယမရွိပဲ ထို script code ကို သူ႕ရဲ႕ browser မွာ run လိုက္မွာ ျဖစ္ပါတယ္။ ထိုအခါ trusted site မွ script code ကို browser က download လုပ္လိုက္ေသာအခါ ထို code ကိုသကၤဪမကင္း မျဖစ္ေတာ့ပဲ လုပ္ေဆာင္သြားျခင္းပင္ ျဖစ္ပါတယ္။Cross Site scripting attacks ေတြက HTTP ႏွင့္ HTTPS (SSL) connection မ်ားမွာ အလုပ္လုပ္ျခင္း ပင္ ျဖစ္ပါတယ္။
Cross-site scripting attack ရဲ႕ အသုံး အမ်ားဆုံးေသာ နည္းလမ္းကေတာ့ attacker (၁) ေယာက္က trusted site (၁)ခုကိုသြားမယ့္ authentication cookies script (၁)ခုကို ေရးလိုက္ျခင္းအားျဖင့္ ထို cookies ကေန web address ကို attacker ကသိရွိသြားမွာ ျဖစ္ပါတယ္။ ထိုမွ ေန၍ attacker က user ႏွင့္သက္ဆိုင္ေသာ အရာအားလုံးကို လုပ္ေဆာင္လို႔ရသြားမွာျဖစ္ပါတယ္။
Web Application ၁ခုမွာ Cross-site scripting attack ျဖစ္ေပၚလာနိုင္တဲ့ vulnerabilities ေတြကေတာ့
♦ Input ကို စစ္ေဆးရာတြင္ မေအာင္ျမင္ျခင္း။
♦ Output ကို encode လုပ္ရာတြင္ မေအာင္ျမင္ျခင္း။
♦ Shared database တစ္ခုမွ trusting data မ်ားကို ထုတ္ယူျခင္း တို႔ျဖစ္ပါသည္။
လမ္းၫြန္ခ်က္မ်ားမွာ-
Cross-site scripting (XSS) attack ကို ကာကြယ္နိုင္မဲ့ အေရးပါေသာ countermeasures (၂)ခု ကေတာ့
♦ Input ကို ကန့္သတ္ျခင္း ႏွင့္
♦ Output ကို encode လုပ္ျခင္း တို႔ပဲျဖစ္ပါတယ္။
ဝင္လာေသာ input မ်ားကို ကန့္သတ္စစ္ေဆးျခင္း
ဝင္လာေသာ Input အားလုံးကို malicious code မ်ား ပါဝင္နိုင္တယ္လို႔ယူဆၿပီးေတာ့ type, length, format, range အားလုံးကို Validate လုပ္ထားရမယ္။
♦ ASP.NET မွာဆိုရင္ input ကို ကန့္သတ္သည့္ Server site validator controls မ်ားျဖစ္ေသာ RegularE×pressionValidator ႏွင့္ RangeValidor တို႔ ကို သုံးရပါမည္။
♦ Regular e×pression ကိုအသုံးျပဳ၍ server side code ကို check လုပ္ရန္အတြက္ System.Te×t.RegularE×pressions.Rege× ကို client-side ရဲ႕ HTML input controls (သို႔) တျခားsource ကေနလာတဲ့ query strings or cookies ကဲ့သို႔ေသာ input တို႔ကို supply လုပ္နိုင္မဲ့ input ကိုကန့္သတ္ထားရန္။
♦ Validate အမ်ိဳးအစားမ်ားျဖစ္ေသာ intergers, doubles, dates ႏွင့္ currency amounts တို႔ကို႔NET Framework data type ႏွင့္ equivalent ျဖစ္ေသာ input data အျဖစ္ convert လုပ္၍ ရရွိလာေသာ resulting conversion errors မ်ားကို handle လုပ္ရန္တို႔ျဖစ္ပါသည္။
Output ကို encode လုပ္ျခင္း
User ကေန ထည့္သြင္း လိုက္တဲ့ input (သို႔) database တို႔လိုမ်ိဳး (သို႔)၊ တျခား source ကေန ရရွိတဲ့ input ဆိုလွ်င္ HttpUtility.HtmlEncode method ကို အသုံးျပဳ၍ ရနိုင္ပါတယ္။ HtmlEncode ကို အသုံး ျပဳျခင္းျဖင့္ special
meaning အျဖစ္ characters မ်ားကို replace လုပ္နိုင္ပါတယ္။ဥပမာအားျဖင္ ့ - < is replaced with < and " is replaced with " အျဖစ္ေျပာင္း လဲနိုင္ပါတယ္။Data ကို encode လုပ္ျခင္းျဖင့္ browser ရဲ႕ E×ecute code ကိုမျဖစ္ေစပါဘူး။ Data ေတြက HTML Harmless ျဖစ္သကဲ့သို႔ rendered ပဲ ျဖစ္ေစပါတယ္။တူညီစြာပဲ input constructed ျဖစ္ခဲ့မယ္ဆိုရင္output URLs ကို encodeလုပ္ရန္အတြက္ HttpsUtility.UrlEncode ကိုအသုံးျပဳ နိုင္ပါတယ္။
အႏွစ္ခ်ဳပ္အခ်က္မ်ား
Cross-site scripting ကို ကာကြယ္ရန္ အတြက္ ေအာက္ေဖာ္ျပပါအဆင့္မ်ားကို လုပ္ေဆာင္ ရမွာျဖစ္ပါတယ္။
♦ Step(1)- ASP.NET ရဲ႕ Request ကို enabled လုပ္ထား/မထား စစ္ေဆးရပါမယ္။
♦ Step(2)- HTML Output ကေန ထြက္လာတဲ့ ASP.NET code ကို Review လုပ္ရန္။
♦ Step(3)- HTML Output မ်ားတြင္ input parameters မ်ား ပါ မပါ ကို စစ္ေဆးလုပ္ရန္။
♦ Step(4)- အနတရာယ္ ရွိသည္ဟု ယူဆ၍ ရေသာHTML tags မ်ားႏွင့္ attributes မ်ားကို Review
လုပ္ရန္။
♦ Step(5)- ေျဖရွင္းရန္ နည္းလမ္းမ်ား(countermeasures) ကို evaluate လုပ္ရန္တို႔ျဖစ္ပါတယ္။
Step(1)- ASP.NET ရဲ႕ Request က enabled ကို Check လုပ္ရန္
Machine.config မွာ request validation ကို Enable လုပ္နိုင္ပါတယ္။ထိုကဲ့သို႔လုပ္ျခင္းျဖင့္ server ရဲ႕ Machine.config file မွာ request validation ဟာ enable ျဖစ္ေနမွာ ျဖစ္ပါတယ္။ValidateRequest က true ျဖစ္ ၾကာင္း ေအာက္တြင္ ေဖာ္ျပထားေသာ e×ample code နဲ႕ Check လုပ္နိုင္ပါတယ္။
<system.web> <pages buffer="true" validateRequest="true" /> </system.web>
Page by page basic အေနျဖင့္ လည္း request validation ကို disable လုပ္နိုင္ပါတယ္။Pages က disable ျဖစ္မဘူး ဆိုရင္ေတာ့ ဒီ feature မလိုအပ္ပါဘူး။ဥပမာအားျဖင့္-ဒီ feature ကိုdisable လုပ္ရန္ လိုအပ္တဲ ့page
ကေတာ့ free-format, rich-te×t entry field design တို႔ကို လက္ခံရရွိတဲ့ HTML characters ကဲ့သို႔input ေတြပဲျဖစ္ ပါတယ္။ဒီလိုအမ်ိဳးအစား page ေတြကိုပိုမိုလုံၿခဳံစြာ handle လုပ္နိုင္ရန္အတြက္ နည္းလမ္းကိုေတာ့ step 5
ရဲ႕ Evaluate Countermeasures တြင္ ေတြ႕ရမွာ ျဖစ္ပါတယ္။ ASP.NET request validation ရဲ႕ Enable ကိုစစ္ရန္အတြက္
1. Create an ASP.NET page that disables request validation. To do this, set ValidateRequest="false", as shown in the following code example. 2. <%@ Page Language="C#" ValidateRequest="false" %> 3. <html> 4. <script runat="server"> 5. void btnSubmit_Click(Object sender, EventArgs e) 6. { 7. // If ValidateRequest is false, then 'hello' is displayed 8. // If ValidateRequest is true, then ASP.NET returns an exception 9. Response.Write(txtString.Text); 10. } 11. </script> 12. <body> 13. <form id="form1" runat="server"> 14. <asp:TextBox id="txtString" runat="server" Text="<script>alert('hello');</script>" /> 15. <asp:Button id="btnSubmit" runat="server" 16. OnClick="btnSubmit_Click" 17. Text="Submit" /> 18. </form> 19. </body> 20. </html>
ဒီ page ကို run လိုက္တဲ့အခါ t×tString ထဲမွာရွိတဲ့ script ေၾကာင့္ Hello ဆိုတဲ့ message bo× တစ္ခု ျပပါတယ္။ ValidateRequest="true" (သို႔) ValidateRequest page attribute ကို ဖယ္လိုက္ၿပီး ဒီ page ကို browse ျပန္လုပ္ၾကည့္တဲ့အခါ ေအာက္ပါ error message ျပပါတယ္။
A potentially dangerous Request.Form value was detected from the client (txtString="<script>alert('hello...").
၄င္း error မွာ ASP.NET request validation မွာ active ျဖစ္ၿပီး ၄င္းမွာ အနတရာယ္ျဖစ္နိုင္ေသာ HTML characters မ်ားပါတဲ့ input ကို reject လုပ္လိုက္ေသာေၾကာင့္ျဖစ္သည္။ မွတ္ခ်က္ ။ ။ ASP.NET request validation ကိုပဲ အားမကိုးပါႏွင့္။ ကိုယ္ပိုင္ input validation ကို စစ္တဲ့ ႀကိဳတင္ကာကြယ္မႈတစ္ခုကိုလည္း ျပဳလုပ္သင့္ပါတယ္။
Step(2)- HTML Output ကေနထြက္လာတဲ့ ASP.NET code ကို Review လုပ္ရန္။
ASP.NET က HTML ရဲ. Output ကို two ways နဲ.ျပဳလုပ္နိုင္တာ ကို ေအာက္ပါ e×ample code နဲ.ေဖာ္ျပနိုင္ပါတယ္။
Response.Write
<% =
ၿပီးရင္HTML နဲ. URL output ရဲ. Client ဆီကိုreturn ျပန္တဲ့ page ရဲ. Locate ကိုရွာေဖြနိုင္ပါတယ္။
Step(3)- HTML Output တြင္ပါဝင္ေသာ input parameters မ်ားကို Determine လုပ္ရန္။
Web design ႏွင့္ page code မွာပါဝင္တဲ့ input parameter ေတြကို analyze လုပ္ရမယ္။ Parameter ေတြက source အမ်ိဳးမ်ိဳး ကေနလာ နိုင္ပါတယ္။အသုံးမ်ားတဲ့ input source ေတြရဲ. list ကို ေအာက္တြင္
ေဖာ္ျပထားပါတယ္။
• Form fields, such as the following. • Response.Write(name.Text); • Response.Write(Request.Form["name"]); • Query Strings • Response.Write(Request.QueryString["name"]); • Query strings, such as the following: • Response.Write(Request.QueryString["username"]); • Databases and data access methods, such as the following: • SqlDataReader reader = cmd.ExecuteReader(); • Response.Write(reader.GetString(1)); Be particularly careful with data read from a database if it is shared by other applications. • Cookie collection, such as the following: • Response.Write( • Request.Cookies["name"].Values["name"]); • Session and application variables, such as the following: • Response.Write(Session["name"]); • Response.Write(Application["name"]
Source code ကို analysis လုပ္ရန္ အတြက္ simple test ၁ခုအေနနဲ.form field မွာ"XYZ"လို.ရိုက္ထည့္ၿပီး output ကို testingလုပ္ၾကည့္ပါ ။Browser မွာ "XYZ" လို.ျမင္ရၿပီ ဆိုရင္ေတာ့ HTML ရဲ. Source ကိုၾကည္.လို.ရပါတယ္။
More dynamic တြင္ ေတြ.ဖို. ဆိုရင္ေတာ့ inject <script>alert('hello');</script> ကို input field တြင္ ထည္.ပါ။ဒီ technique ကcases အားလုံးမွာ အလုပ္မလုပ္ နိုင္ပါဘူး။ ဘာေၾကာင့္လဲ ဆိုေတာ့ outputgenerate ျဖစ္လာရန္အတြက္ အသုံးျပဳတဲ့ input ေပၚမွာ depends ျဖစ္ေနေသာေၾကာင့္ ျဖစ္ပါသည္။
Step(4)- အနတရာယ္ရွိသည္ဟုယူဆ၍ရေသာHTML tags မ်ားႏွင့္ attributes မ်ားကို Review လုပ္ရန္။
လုံၿခဳံမႈမရွိဟု ယူဆ၍ ရေသာ HTML tags မ်ားႏွင့္ construct tag attributes မ်ားကို create လုပ္မည္ဆိုလွ်င္၊ HTML-encode tags Attributes ကိုအရင္ ေရးသားထားသင့္ပါသည္။ .asp page တြင္<asp:Literal> control ကိုအသုံးျပဳ၍ HTML မွ direct return page သို႔သြားရန္ ေဖာ္ျပထားပါသည္။ inserted te×t သည္ safe ျဖစ္ရန္အတြက္ the page တြင္ HTMLEncode ကိုအသုံးျပဳ ထားပါသည္။
<%@ Page Language="C#" AutoEventWireup="true"%> <html> <form id="form1" runat="server"> <div> Color: <asp:TextBox ID="TextBox1" runat="server"></asp:TextBox><br /> <asp:Button ID="Button1" runat="server" Text="Show color" OnClick="Button1_Click" /><br /> <asp:Literal ID="Literal1" runat="server"></asp:Literal> </div> </form> </html> <script runat="server"> private void Page_Load(Object Src, EventArgs e) { protected void Button1_Click(object sender, EventArgs e) { Literal1.Text = @"<span style=""color:" + Server.HtmlEncode(TextBox1.Text) + @""">Color example</span>"; } } </Script>
အနတရာယ္ရွိသည္ ဟု ယူဆ၍ ရနိုင္ေသာ HTML Tags မ်ားမွာ-
ေအာက္တြင္ေဖာ္ျပထားေသာ List မ်ားမွာ အသုံးမ်ားေသာ HTML tags မ်ားျဖစ္ၿပီး malicious user ကို allow ျဖစ္ေသာ inject script မ်ားမွာ-
• <applet> • <body> • <embed> • <frame> • <script> • <frameset> • <html> • <iframe> • <img> • <style> • <layer> • <link> • <ilayer> • <meta> • <object>
Attacker ၁ ေယာက္က src, lowsrc, style ႏွင့္ href တို႔လို HTML attributes ေတြကို cross-site scripting ျဖစ္ေစရန္ လုပ္ေဆာင္ျခင္း ျဖစ္သည္။
<img> ရဲ႕ Src attributes ကို source of injection အျဖစ္ ေအာက္ပါ ဥပမာျဖင့္ေဖာ္ျပထားပါသည္။
<img src="javascript:alert('hello');">
<img src="java
script:alert('hello');">
<img src="java
 script:alert('hello');">
<style>tag ျဖင့္လည္း ေဖာ္ျပထားပါသည္။
<style TYPE="text/javascript">
alert('hello');
</style>
Step(5)- ေျဖရွင္းရန္နည္းလမ္းမ်ား(countermeasures) ကို evaluate လုပ္ရန္။
HTML generates ျဖစ္ေစရန္ အခ်ိဳ႕ Input မ်ားကို အသုံးျပဳေသာ ASP.NET code ကို ရွာေတြ႕ၿပီဆိုလွ်င္ specific application အတြက္ appropriate countermeasures ကို evaluate လုပ္ရန္ လိုအပ္ပါသည္။Countermeasures တြင္-
♦ HTML output ကို Encode လုပ္ရန္။
♦ URL output ကို Encode လုပ္ရန္။
♦ User input ကို Filter လုပ္ရန္တို႔ျဖစ္ပါသည္။
HTML output ကို Encode လုပ္ရန္
Web page ၁ခုေပၚမွာ te×t output ကိုေရးေသာအခါ ထို te×t မွာမသိေသာ special characters မ်ား ( ဥပမာ-<, >,&) ပါဝင္ေနေသာ အခါ ေအာက္တြင္ေဖာ္ျပ ထားေသာ code e×ample ကဲ့သို႔ HttpUtillity.HtmlEncode method ကိုသုံး၍ te×t ကို pre-process လုပ္ရပါမည္။
Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));
Input က well-formed, correct ဆိုလွ်င္ encoding output ကို substitute လုပ္ရန္ မလိုအပ္ပါ။ ထိုကဲ့သို႔ျပဳလုပ္ထားျခင္း သည္ additional security precaution လုပ္ျခင္းပင္ ျဖစ္ပါသည္။
URL output ကို Encode လုပ္ရန္
Input ပါဝင္ေသာ URL String ကို Client ဆီသို႔return ျပန္မည္ ဆိုလွ်င္ HttpUtility.UrlEncode method ကို အသုံးျပဳ၍ ထို URL String ကို encode လုပ္ရန ္ေအာက္တြင္ e×ample code ကို ေဖာ္ျပထား ပါသည္။
Response.Write(HttpUtility.UrlEncode(urlString));
User input ကို Filter လုပ္ရန္
HTML elements range ကို accept လုပ္ရန္ လိုအပ္ေသာ pages ေတြရွိခဲ့မယ္ ဆိုလွ်င္ ဥပမာအားျဖင့္-ASP.NET request validation ကို disable လုပ္ရန္ လိုအပ္ပါသည္။ Common practice အေနျဖင့္ HTML element ကို safe formatting restrict ျဖစ္ရန္ bold(<b>), italic(<i>)ကို အသုံးျပဳ နိုင္ပါသည္။ Allow restricted HTML input ကို safety ျဖစ္ရန္
1. ValidateRequest="false" attribute ကို @ Page directive သို႔ Adding လုပ္ျခင္းျဖင့္ ASP.NET request validation ကို disable လုပ္ရန္။
2. HtmlEncode method ျဖင့္ string input ကို Encode လုပ္ရန္။
3. StringBuilder ႏွင့္ သူ႕ရဲ႕ Replace method ကိုအသုံးျပဳ၍ encoding HTML elements ရဲ႕ selectively remove လုပ္ျခင္းႏွင့္permit လုပ္နိုင္ပါသည္။
ေအာက္ပါ .asp× page code တြင္ this approach ကိုေဖာ္ျပ ထား ပါသည္။ ValidateRequest="false"ကိုသုံး၍ ASP.NETpage ကို disable လုပ္ျခင္းႏွင့္ HTML encode the input ႏွင့္ simple te×t format ကို support
လုပ္ရန္selectively allows လုပ္ထားေသာ<b>, <i>တို႔ကဲ့သို႔ HTML elements မ်ားကို ေဖာ္ျပ ထားပါသည္။
<%@ Page Language="C#" ValidateRequest="false"%> <script runat="server"> void submitBtn_Click(object sender, EventArgs e) { // Encode the string input StringBuilder sb = new StringBuilder( HttpUtility.HtmlEncode(htmlInputTxt.Text)); // Selectively allow <b> and <i> sb.Replace("<b>", "<b>"); sb.Replace("</b>", ""); sb.Replace("<i>", "<i>"); sb.Replace("</i>", ""); Response.Write(sb.ToString()); } </script> <html> <body> <form id="form1" runat="server"> <div> <asp:TextBox ID="htmlInputTxt" Runat="server" TextMode="MultiLine" Width="318px" Height="168px"></asp:TextBox> <asp:Button ID="submitBtn" Runat="server" Text="Submit" OnClick="submitBtn_Click" /> </div> </form> </body> </html>
ထပ္မံ၍စဥ္းစားဆင္ျခင္ျခင္းမ်ား
အထက္တြင္ ေဖာ္ျပ ထားေသာtechniques မ်ား အျပင္ ထပ္မံ၍ future တြင္ cross-site scripting ကို prevent လုပ္ရန္countermeasures မ်ားကိုေဖာ္ျပ ထားပါသည္။
♦ Correct character encoding ကို set လုပ္ျခင္း။
♦ Input sanitization ကို do not rely လုပ္ျခင္း။
♦ HttpOnly cookies option ကို Use လုပ္ျခင္း။
♦ <frame>security attribute ကို Use လုပ္ျခင္း။
♦ InnerHTML အစား innerTe×t property ကို Use လုပ္ျခင္း တို႔ျဖစ္ၾကပါသည္။
Correct character encoding ကို set လုပ္ျခင္း။
Web pages တြင္ restrict valid data ကို successfully ျဖစ္ေစရန္ အတြက္ represented လုပ္မဲ့ input data ေတြရဲ႕ Ways ကို limit လုပ္သင့္ ပါတယ္။ Malicious user မွ input validation routines ေတြကို trick
ျဖစ္နိုင္ ရန္အတြက္ canonicalization ႏွင့္ multi-byte escape ကိုအသုံးျပဳ၍ လုပ္ေဆာင္ျခင္းကို ကာကြယ္ရန္ ျဖစ္ပါသည္။Multi-byte escape sequence attack ဆိုသည္မွာ-character encodings ကိုအသုံးျပဳ၍ uniform translation format-* (UTF-*) သကဲ့သို႔ ႏွင့္ non-ASCII character မ်ားကို ေဖာ္ျပရန္အတြက္ muliti-bytes sequence မ်ားကို အသုံးျပဳ၍ လုပ္ေဆာင္ျခင္း ပင္
ဖစ္ပါသည္။အခ်ိဳ႕ byte sequence မ်ားကေတာ့ not legitimate UTF-*
မ်ားျဖစ္ေသာ္လည္း သူတို႔က အခ်ိဳ႕ UTF-* decoder မ်ားကိုေတာ့ accept လုပ္နိုင္ၿပီးေတာ့ e×ploitable security hole ကို providing လုပ္နိုင္မွာ ျဖစ္ပါတယ္။
ASP.NET တြင္ page level ေပၚတြင္ (သို႔) application level ေပၚရွိ Web.config file ထဲတြင္ element ကို အသုံးျပဳျခင္း ျဖင့္ character set ကို specify လုပ္ရန္ ခြင့္ျပဳထားပါတယ္။ ေအာက္တြင္ ေဖာ္ျပထားေသာ code e×ample တြင္ ISO-**59-1 ကို အသုံးျပဳ၍ both approaches ကိုေဖာ္ျပထားပါသည္။ Page level တြင္ character encoding ကို set လုပ္ရန္ အတြက္ element (သို႔) ResponseEncoding ကို page level attribute မ်ား တြင္ ေအာက္တြင္ေဖာ္ျပထားပါသည္။
<meta http-equiv="Content Type" content="text/html; charset=ISO-8859-1" /> OR <% @ Page ResponseEncoding="iso-8859-1" %>
Web.config file တြင္ character encoding ကို set လုပ္ရန္ အတြက္ ေအာက္တြင္ ေဖာ္ျပထားေသာ configuration ကို use ထားပါတယ္။
<configuration> <system.web> <globalization requestEncoding="iso-8859-1" responseEncoding="iso-8859-1"/> </system.web> </configuration>
ေအာက္တြင္ ေဖာ္ျပထားေသာ code ကို အသုံးျပဳ၍ page တြင္ Unicode character မ်ားကို validate ျပဳလုပ္နိုင္ပါသည္။
using System.Text.RegularExpressions; . . . public class WebForm1 : System.Web.UI.Page { private void Page_Load(object sender, System.EventArgs e) { // Name must contain between 1 and 40 alphanumeric characters // and (optionally) special characters such as apostrophes // for names such as O'Dell if (!Regex.IsMatch(Request.Form["name"], @"^[\p{L}\p{Zs}\p{Lu}\p{Ll}\']{1,40}$")) throw new ArgumentException("Invalid name parameter"); // Use individual regular expressions to validate other parameters . . . } }
အထက္တြင္ ေဖာ္ျပ ထားေသာ code တြင္ ပါဎင္ေသာ regular e×pression အေၾကာင္းကို ေအာက္တြင္ ရွင္းျပထားပါသည္။၄င္းတို႔မွာ-
♦ ^ ၏အဓိပပါယ္မွာ - this position ကို စ၍ looking လုပ္ျခင္းပင္ ျဖစ္ပါသည္။
♦ \p{ ..} ၏အဓိပပါယ္မွာ -{ } ျဖင့္ specified ျဖစ္ေနေသာ name character class ထဲတြင္ ရွိေသာ
any character ကိုမဆို matches လုပ္ျခင္း ပင္ျဖစ္ပါသည္။
♦ {L} ၏အဓိပပါယ္မွာ Left-to-right match ကို လုပ္ေဆာင္ေပးျခင္း ပင္ျဖစ္ပါသည္။
♦ {Lu} ၏အဓိပပါယ္မွာ upper case ၏ match ကို လုပ္ေဆာင္ေပးျခင္း ပင္ျဖစ္ပါသည္။
♦ {Ll} ၏အဓိပပါယ္မွာ lower case ၏ match ကို လုပ္ေဆာင္ေပးျခင္း ပင္ျဖစ္ပါသည္။
♦ {Zs} ၏အဓိပပါယ္မွာ separator ႏွင့္ space ကို matches လုပ္ေဆာင္ေပးျခင္း ပင္ျဖစ္ပါသည္။
♦ ' မွာ matches ၏ သေင္္ တ ျဖစ္ပါသည္၊
♦ {1,40} မွာ- character မ်ား၏ တိက်ေသာ number ပင္ျဖစ္ပါသည္။၄င္းတြင္ 1 ထက္ေလ်ာ့၍
မရပဲ ၊ 40 ထက္လည္း မပိုဟု အဓိပပါယ္ရပါသည္။
♦ $ ၏အဓိပပါယ္မွာ- this position ကို looking လုပ္ေနျခင္းမွ stop ျခင္းပင္ျဖစ္ပါသည္။
Input Sanitization ေပၚတြင္ မွီခိုအားထားမႈ႕မရွိျခင္း။
Unsafe character မ်ားကို filtering out လုပ္ျခင္းျဖင့္ code ထဲတြင္ input sanitize ျဖစ္ေစရန္ လက္ေတြ႕တြင္ လုပ္ေဆာင္ လာၾကပါသည္။ ထိုကဲ့သို႔ လုပ္ေဆာင္ျခင္းသည္ Rely မျဖစ္ေစပါ။အဘယ့္ေၾကာင့္ဆိုေသာ္ malicious user
မ်ားဟာ validation ျဖစ္ေစရန္ alternative ေတြကို ရွာေဖြ လာနိုင္ေသာေၾကာင့္ ျဖစ္ပါသည္။ထိုကဲ့သို႔ ျပဳလုပ္မည့္အစား သိရွိထားၿပီးေသာ secure, safe input ကိုသာ check လုပ္သင့္ပါသည္။Table 1 တြင္ အခ်ိဳ႕common character မ်ား၏ safe ျဖစ္ေစရန္ various way မ်ားကို ေဖာ္ျပထားပါသည္။
HttpOnly Cookies Option ကိုအသုံးျပဳျခင္း။
Internet E×plorer 6 Service Pack 1 ႏွင့္ HttpOnly cookies attributes ကို supports လုပ္ေပးနိုင္ေသာ later Virsion မ်ားမွာ-document.cookie property မွ cookie ကို accessing လုပ္ေသာ client-side script မ်ားကို prevent လုပ္ေပးနိုင္ပါတယ္။ထို script ဟာ empty string ကိုပဲ retun ျပန္မွာ ျဖစ္ပါတယ္။ထို cookies က server ဆီသို႔ ပို႔သည့္တိုင္ေအာင္ user ရဲ႕ Browse ကေတာ့ current domain Web Site မွာပဲ ရွိေနမွာ ျဖစ္ပါတယ္။
သတိျပဳရန္- Web browser မ်ားက HttpOnly cookies attribute ကို support မလုပ္နိုင္ပါဘူး။သူက cookies ေရာ၊ attribute ေရာ (၂) ခုစလုံးကို ignore လုပ္သြားမွာ ျဖစ္ပါတယ္။အဓိပပါယ္ကေတာ့-cross-site
scripting attacks ပဲ ျဖစ္ပါတယ္။
System.Net.Cookie class ရွိေသာ Microsoft.Net Framework version 2.0 က HttpOnly property ကို support လုပ္ေပး နိုင္ပါတယ္။.NET Framework ရဲ႕ Earlier version ေတြျဖစ္တဲ့ version 1.0 ႏွင့္ 1.1 တို႔တြင္ code
မ်ားထပ္ထည့္ရန္ လိုအပ္ပါသည္။ ေအာက္တြင္ေဖာ္ျပထားေသာ Application EndRequest event သည္ application Global.asa× file ၏ hadler ျဖစ္ၿပီး HttpOnly attribute တြင္ e×plicity set ရန္ျဖစ္ပါသည္။
protected void Application_EndRequest(Object sender, EventArgs e) { string authCookie = FormsAuthentication.FormsCookieName; foreach (string sCookie in Response.Cookies) { // Just set the HttpOnly attribute on the Forms // authentication cookie. Skip this check to set the attribute // on all cookies in the collection if (sCookie.Equals(authCookie)) { // Force HttpOnly to be added to the cookie header Response.Cookies[sCookie].Path += ";HttpOnly"; } } }
<frame> Security Attribute ကိုအသုံးျပဳျခင္း။
Internet E×plorer 6 ႏွင့္ later version မ်ားမွာ <frame> ႏွင့္ <iframe> တို႔အတြက္ new secrrity attribute မ်ားကို support ေပးနိုင္ပါတယ္။ frame ႏွင့္ iframe တို႔တြင္ user ၏ Restricted Sites
Internet E×plorer security zone setting မွ security attribute ကို အသုံးျပဳနိုင္ပါတယ္။ သို႔ေသာ္ Restricted Sites zone က script e×ecution ကိုေတာ့ support မလုပ္ေပးနိုင္ပါဘူး။
Security attribute ကိုအသုံးျပဳမည္ဆိုလွ်င္ ေအာက္တြင္ေဖာ္ျပထားေသာ "restricted " ကို set လုပ္ေပးရပါမည္။
<frame security="restricted" src="http://www.somesite.com/somepage.htm"> </frame>
innerHTML ကိုသုံးျခင္း အစား innerTe×t Property ကို အသုံးျပဳျခင္း။
Page (၁) ခုကို innerHTML property ကိုသုံးၿပီး built လုပ္မည္ဆိုလွ်င္ HTML က potentially untrusted input ေပၚတြင္ အေျခခံ ေသာေၾကာင့္ safe ျဖစ္ေစရန္ HtmlEncode ကိုအသုံးျပဳရမည္ ျဖစ္သည္။ innerTe×t ကိုအသုံးျပဳျခင္း အစား ထိုကဲ့သို႔ ျပဳလုပ္ျခင္းျဖင့္ လည္း ေရွာင္ရွားနိုင္ပါတယ္။ innerTe×t property က renders content safe ျဖစ္ေစၿပီး၊ ေသခ်ာတာကေတာ့ script မ်ားကို e×ecuted မလုပ္ျခင္းပင္ ျဖစ္ပါသည္။
ေအာက္တြင္ေဖာ္ျပထားေသာ e×ample တြင္ this approach အတြက္ two HTML control မ်ားကိုေဖာ္ျပထားပါသည္။ innerTe×t property ကို အသုံးျပဳထားေသာ Welcome1element
တြင္ Page Load method သည္ Te×t ကို ေဖာ္ျပရန္အသုံးျပဳထားပါေသာေသာေၾကာင့္ encoding သည္ မလိုအပ္ပါ။ innerTe×t property ကို အသုံးျပဳထားေသာ Welcome2element တြင္ safe ျဖစ္ေစရန္အတြက္ HtmlEncode ကို အသုံးျပဳရပါမည္ ျဖစ္ပါသည္။
<%@ Page Language="C#" AutoEventWireup="true"%> <html> <body> <span id="Welcome1" runat="server"> </span> <span id="Welcome2" runat="server"> </span> </body> </html> <script runat="server"> private void Page_Load(Object Src, EventArgs e) { // Using InnerText renders the content safe–no need to HtmlEncode Welcome1.InnerText = "Hello, " + User.Identity.Name; // Using InnerHtml requires the use of HtmlEncode to make it safe Welcome2.InnerHtml = "Hello, " + Server.HtmlEncode(User.Identity.Name); } </Script>
တို႔ျဖစ္ပါသည္။
