Cross Site Scripting - XSS - Part6

با سلام خدمت دوستان عزیز.

در این پست میخام راهکارهای تکمیلی در مبارزه با XSS را توضیح بدم. در مهندسی و اصول Security به این راهکارها Defense in Depth  یا دفاع در عمق یا دفاع چند لایه و ... گفته میشه.

اصولا این راهکارها راهکارهای اصلی نیستند و نمیتونید صرفا به این راهکارها برای مبارزه با XSS تکیه کنید و هدف از بیان کردن آنها سخت تر کردن کار هکرها برای  انجام موفق حملات XSS میباشد.

راهکارهای تکمیلی (Defense in Depth) :

  • تنظیم Character Set  در صفحات وب

در صورتیکه Character Set مشخص نشده باشد ممکن است Browser با توجه به کاراکترهای موجود Character Set متفاوت از آنچه که میبایست انتخاب کند برگزیند و این باعث میشود که مرورگر بعضی از کاراکترها را به شکل خاصی تفسیر کند و راه نفوذ به برنامه را هموار سازد. برای مثال ورودی به شکل  <script>alert(document.cookie)</script>  در UTF-7 به شکل

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-  

میباشد که میتواند از بسیاری از سیستمهای تشخیص کاراکتر مخرب در اعتبارسنجی ورودی عبور کرده و راه نفوذ به برنامه را مهیا سازد.

در ASP.NET بصورت Global میتوان CodePage را در Web.config  تنظیم نمود:

globalization requestEncoding="iso-8859-1" responseEncoding="iso-8859-1"/> 1>
و یا برای یک صفحه وب مشخص : <% Page RequestEncoding="utf-8" ResponseEncoding=utf-8 @ %>

بدین ترتیب مهاجم دیگر قادر به تغییر Character set در Header ها نخواهد بود و Browser نیز اطلاعات را مطابق با Character set تنظیم شده تفسیر و نمایش خواهد داد.

  • استفاده از ASP.NET ValidateRequest:

در ASP.NET امکانی به نام ValidateRequest وجود دارد که برنامه به Request هایی که حاوی HTML یا XML باشند پاسخ نمیدهد (به طور دقیقتر ترکیب کاراکتر > که بعد از آن حروف الفبا یا کاراکتر ! یا ؟ بیاید و همچنین ترکیب #& در فیلدهای فرم یا Query String یا کوکی را کاراکترهای مخرب تشخیص داده ) و یک پیغام خطا مبنی بر وجود کاراکترهای مخرب در درخواست اسالی را به کاربر نمایش میدهد.

ValidateRequest در موارد ساده میتواند جلوی حملات XSS را بگیرد اما بهیچ وجه برای مقابله با XSS نباید به آن اکتفا نمود.

این امکان به طور پیش فرض برای Requestهای ارسالی به تمامی Resource ها در ASP.NET  از جمله صفحات aspx و وب سرویسها فعال است اما در صورتیکه در برنامه مجبور به پذیرش ورودیهای HTML  و یا XML از کاربر هستید باید این گزینه را غیر فعال نمایید. برای اینکار در web.config:

 <system.web>

  <httpRuntime requestValidationMode="2.0" />

        <pages validateRequest="false" />

  </system.web >

یا برای یک صفحه وب مشخص:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs"        Inherits="_Default" ValidateRequest="false" %>

همچنین در ASP.NET MVC نیز View ها و Controller ها توسط ValidateRequest محافظت میشوند.

  • استفاده از HttpOnly Cookies

HttpOnly یک Flag افزوده شده به Set-Cookie HTTP response header  میباشد. استفاده از HttpOnly در زمان ایجاد کوکی به  Browser اعلام میکند که دسترسی به آن کوکی فقط توسط سرورامکانپذیر است و اسکریپتهای Client-Side به آن کوکی دسترسی ندارند و نمیتوانند کوکی را بخوانند.

دات نت 2 به طور پیش فرض HttpOnly را برای کوکیهای Session ID ,Form Authentication cookie تنظیم میکند. برای تنظیم HttpOnly  در کوکیهای Custom در web.config:

<system.web>

   <httpCookies httpOnlyCookies="true"/>

و یا در برنامه:

 HttpCookie myCookie = new HttpCookie("myCookie");

myCookie.HttpOnly = true;

Response.AppendCookie(myCookie);

مشکلاتی در رابطه با اینکه در AJAX XMLHttpRequest  اجازه خواندن کوکیهای HttpOnly را میدهد در نسخه های قدیمی بعضی مرورگرها (بیشتر Firefox , Opera) وجود داشت که در نسخه های جدید برطرف گردید. (برای مطالعه بیشتر به اینجا مراجعه نمایید)

توجه نمایید که هر چند همه مرورگرها از HttpOnly پشتیبانی نمیکنند ( برای مشاهده لیست مرورگرهایی که از HttpOnly پشتیبانی میکنند به اینجا مراجعه نمایید.) اما اکثر مرورگرهای مدرن جدید از این ویژگی پشتیبانی میکنند و توصیه میشود به عنوان راهکار تکمیلی در مبارزه با XSS از آن استفاده نمایید.

 

  • استفاده از innerText بجای innerHTML:

در کنترلهای HTML در زمانی که قرار است ورودی کاربر در خروجی نمایش داده شود بجای استفاده از innerHTML از innerText استفاده نمایید. برای مثال:

document.getElementById("label").innerText = UntrustedData;

در innerText  ورودیهایی که حاوی اطلاعات به فرمت HTML باشند مرورگر با آن بصورت Literal برخورد کرده و کدهای HTML یا اسکریپتها اجرا نمیشوند اما در innerHTML
آن ورودی اجرا میشود.

تذکر: استفاده از innerText بجای innerHTML همیشه جوابگو نیست و به HTML Elementکه innerText در آن استفاده شده بستگی دارد. به مثال زیر توجه نمایید:

<script>

var tag = document.createElement("script");

tag.innerText = "<%=untrustedData%>";  //executes code

</script>

  • استفاده ازAntiXSS Sanitizer

Microsoft AntiXSS Library از نسخه 3.1 به بعد امکانی برای ذخیره و یا نمایش ورودی که به صورت HTML میباشد را فراهم آورده است. توسط کلاس Sanitizer  و با استفاده از متدهای GetSafeHTML  و GetSafeHtmlFragments  ورودی نامطمئن Sanitize میشود بدین معنی که  با استفاده از White List متشکل از Element های امن در  HTML که بصورت پیش فرض در AntiXSS تعریف شده اند قسمتهایی که مخرب تشخیص داده شوند حذف میگردند. برای مثال :

using Microsoft.Security.Application;

...

...

string wysiwygData = "before <script>alert('bip ')</script> after ";

string cleanData = Sanitizer.GetSafeHtmlFragment(wysiwygData);

 

در نتیجه مقدار cleanData برابر "before after " خواهد بود و تگهای اسکریپت از ورودی حذف میشوند.

استفاده از این کلاس برخلاف HTML Encode در AntiXSS بدین معنی میباشد که فرمت متن ورودی و تگهایی که در White-List باشند به صورت کامل حفظ میشوند.

 

  • استفاده ازWAF

زمانیکه سورس برنامه قابل دسترس نیست از فایروال برنامه های وب  (WAF)استفاده کنید.

  • Code Review و استفاده از ابزارهای موسوم به Static Source Code Analyzer

از برنامه CAT.NET برای برنامه های ASP.NET در جهت کشف آسیب پذیریهای XSS میتوانید استفاده نمایید. اما استفاده از این نوع برنامه­ها بتنهایی کفایت نمیکند و فقط به عنوان راهکار مکمل پیشنهاد میشود. CodeReview  بصورت Manual همزمان با  کارگیری ابزارهای اتوماتیک آنالیز سورس برنامه میتواند درصد بالایی از مشکلات XSS را پیدا کند.

 

به انتهای این قسمت رسیدیم. در قسمت بعد که آخرین بخش از  مجموعه پستهای XSS میباشد در رابطه با برخی تصورات اشتباه که در بین برنامه نویسان رایج میباشد صحبت خواهم کرد.

موفق و سربلند باشید.

/ 0 نظر / 26 بازدید