در این مقاله به شما آموزش می دهیم که چگونه از حمله Cross-Site Scripting و یا تزریق کد در ASP.Net جلوگیری کنیم.

آیا وب سایت شما داده ها و صفحات را به صورت استاتیک ارائه می کند که تغییر نمی کنند و هیچ داده ورودی چه به صورت ضمنی و چه مستقیم از کاربر دریافت نمی کند؟

اما این تقریبا غیرممکن است، چرا که اغلب وب سایت ها صفحات داینامیک ارائه می دهند و با کاربران در تعامل هستند. ممکن است مطلبی را در سایت شما جستجو کنند، از طریق Login و ثبت نام وارد سایت شما شوند، کامنت بگذارند و یا به آدرس خاصی از سایت هدایت شوند که شامل پارامتری باشد و هر فعالیت رایج دیگری که کاربر می تواند انجام دهد. اگر کاربر در سایت شما، امکان انجام فعالیت های گفته شده را دارد، پس در ادامه با ما همراه باشید.

در سال 2014، XSS به عنوان آسیب پذیرترین تهدید در web application ها شناخته شد. مسئله نگران کننده تر این است که، OWASP آن را به عنوان سومین حفره امنیتی در بین 10 حفره اصلی شناخت. هر چه امکان تعامل با کاربر در وب اپلیکیشن ها بیشتر می شود، به همان میزان نیز آسیب پذیری آنها بیشتر می شود. اما چطور می توانیم از این حمله ها از جمله XSS جلوگیری کنیم؟

Preventing XSS in ASP.NET Made Easy

If you have spent anytime attempting to wrap your head around XSS, like many, you might have come to the same conclusion of feeling overwhelmed and perplexed. We have made it that way by defining 5 terms for small variations of ways the vulnerability can be exploited and a plethora of information and ways to implement mitigations. Whereas in reality, it can be much simpler and straight forward.

The key to understanding XSS lies in the understanding there are only 2 key players involved.

دانش کمی درباره این دو و نقش آنها شما را قادر خواهد ساخت تا احتمال XSS را در web application خود شناسایی کنید. استفاده از این اطلاعات و ابزاری که ما در این مقاله برای شما فراهم کردیم، به شما کمک خواهد کرد تا وب سایت خود را در مقابل این حملات محافظت نمایید.

این دو بازیکن اصلی، مرورگر و منابع خارجی هستند. با بررسی نقش مرورگر شروع می کنیم:

Execute All the Things!

در شکل زیر می توانید، ارتباط مرورگر و سرور را زمان درخواست کلاینت مشاهده نمایید.

اطلاعاتی که مرورگر از وب سرور دریافت می کند، دو دسته داده ها و دستورات می باشند. از این رو، برای مثال زمانی که مرور یک اسکریپت جاوااسکریپت را اجرا می کند، می توانیم بگوییم در حال پردازش اطلاعات درون یک دستور است. برعکس، زمانی که مرورگر یک متن را نمایش می دهد، اطلاعات از نوع داده ها هستند. اگر چه، برنامه web aplication انتظار دارد اطلاعاتی که دریافت می کند، داده باشد و حاوی دستوراتی باشد که به عنوان داده وارد شده اند و مرورگر این دستورات را اجرا می کند. به طور کلی مرورگر هیچ شناختی نسبت به داده های مخرب و غیرمخرب ندارد.

درحال حاضر تنها کلید ما، اطلاعاتی است که مرورگر دریافت کرده است. این اطلاعات از کجا می آیند، توسط برنامه نویس هدایت می شوند؟یا حاوی اطلاعاتی است که توسط یک منبع خارجی فراهم شده است؟پاسخ این سوال ما را در پیدا کردن دومین کلید و بازیکن در شناسایی XSS راهنمایی می کند.

نکته: پیشتر گفتیم که مرورگر ها هیچ شناختی نسبت به داده های مخرب و غیرمخرب ندارند. اگرچه در مرورگرهای جدید، با اعمال محدودیت هایی به کاهش آسیب پذیری هایی که برخی از آنها به عنوان XSS شناخته می شوند، سایت کمک کرده اند. متاسفانه این محدودیت ها از مرورگری به مرورگر دیگر فرق می کند و آسیب پذیری سایت شما از مرورگری به مرورگر دیگر متفاوت است و به آن بستگی دارد.

منابع خارجی:

با اینکه اجرای دستورات توسط مرورگر سرعت را افزایش می دهد، دلیل XSS، استفاده از منابع خارجی است.

یکی از ملزومات داشتن یک سایت قدرتمند و کاربر پسند، ورودی ها و تعامل کاربران است. اخیرا تمامی حملات XSS به ورودی های کاربر برمی گردد. همانطور که در ابتدای مقاله گفتیم، ورودی های کاربر می تواند از طریق فرم، کامنت و یا مقادیر پارامتر یک query string باشد که کاربر را به صفحه خاصی هدایت می کند. در هر یک از این مثال ها، کاربر، یک منبع خارجی، اطلاعات را برای انجام کارها برای ما فراهم می کنند.

از این رو، حالا که نقش منبع خارجی را در XSS متوجه شدیم به راحتی می توانیم احتمال آسیب پذیری در سایت خود را که به کاربر اجازه وارد کردن داده را داده ایم و به درستی مدیریت نشده است، شناسایی کنیم. قبل از اینکه به بررسی چگونگی مدیریت این قسمت ها بپردازیم، به مثال ساده زیر توجه کنید.

این مثال نشان می دهد که چگونه یک اسکریپت مخرب می تواند به صفحه تزریق شود و یک کاربر دیگر روی کامپیوتر جدا و در مکان دیگری تحت تاثیر این حمله قرار بگیرد و این اسکریپت چه عملیات مخربی را می تواند اجرا کند.

Your company's strict licensing and security policy doesn't allow the use of third-party tools. So the new article comments feature they want to make available on the company's website must be developed in-house from the ground up. With the new comment feature available for users the following scenario is carried out.

در این مثال، کاربر مخرب در نهایت موفق می شود که تگ <script> را در کامنت خود جا دهد که این کامنت به طور خودکار توسط سرور روی حافظه ذخیره می شود. زمانی که هر کسی از این صفحه که شامل کامنت است بازدید می کند، سرور همه منابع مربوط به این صفحه مانند HTML، CSS، JavaScript و ... را به مرورگر قربانی ارائه می دهد. مرورگر کاربر نیز همه تگ های HTML و اسکریپت ها را اجرا خواهد کرد. بنابراین اسکریپت پنهان شده در کامنت نیز اجرا خواهد شد.

همانطور که می بینیم، یک اسکریپت حمله می تواند توسط داده های ورودی کاربر تزریق شده، در صفحه باقی بماند، به مرورگر کاربر دیگر ارائه شده و اجرا شود.