فروش ویژه : ثبت دامنه آی آر IR فقط 99 هزار تومان سفارش آنلاین/ تحویل آنی
فروش ویژه : ثبت دامنه دات کام COM فقط 990 هزار تومان سفارش آنلاین/ تحویل آنی (بهترین پیشنهاد)
فروش ویژه : 1500 مگابایت هاست ابری به همراه SSL رایگان ماهیانه فقط 99 هزار تومان مشاهده مشخصات و پلن ها
نقاط آسیب پذیری و ضعف های امنیتی در فایل Web.config (قسمت اول)
امروزه بزرگترین تهدید برای امنیت شبکه های سازمانی، از سمت وب سایت ها و اپلیکیشن های مبتنی بر وب می باشد. با توجه به گسترش و توسعه تکنولوژی های امنیتی روی شبکه ها و حداقل شدن امکان نفوذ هکر ها به سرور ها و شبکه های اصلی، حفره های امنیتی و نقاط ضعف ناشی از برنامه های کاربردی تحت وب (Web applications) بسیار مورد توجه هکر ها قرار گرفته است. لذا کوچکترین اشتباه و یا نقاط ضعیف امنیتی موجود در برنامه های تحت وب از جمله فایل web.config راه های نفوذ هکر ها را به وب سایت و اطلاعات موجود در آن فراهم می کند.
برخلاف سرویس های داخلی نظیر دیتابیس ها که تنها امکان توسط فایروال ها، به دسترسی یک یا چند نفر داده می شود، وب سایت ها مورد استفاده عموم بوده و همگان به آن دسترسی دارند. در نتیجه امکان آسیب پذیری برنامه های تحت وب به مراتب بیشتر می باشد.
با توجه به این مقدمه و اهمیت ایمن نمودن برنامه های تحت وب در این مقاله برآن شدیم تا اشتباهات امنیتی احتمالی را روی فایل web.config بررسی نماییم.
در مقاله ساختار فایل Web.Config در ASP.NET، راجع به ساختار و قابلیت های مختلف فایل Web.config، توضحات لازم ارائه شد. در ادامه فایل پیکربندی web.config را از نقطه نظر آسیب پذیری و مشکلات امنیتی بررسی نماییم. در این مقاله متداول ترین اشتباهات و نحوه سوء استفاده و نفوذ هکر ها با استفاده از نقاط آسیب پذیری سایت ها و همچنین نحوه ایمن نمودن فایل پیکربندی Web.config توضیح داده خواهد شد.
-
غیر فعال کردن نمایش خطاهای سفارشی :
هنگامی که خطاهای سفارشی (Custom Errors) را نظیر کدهای زیر غیر فعال می کنید، ASP.NET بصورت پیش فرض خطاهای از پیش تعریف شده را به کاربران نمایش می دهد.
کد اشتباه :
<configuration> <system.web> <customErrors mode="Off">
کد صحیح :
<configuration> <system.web> <customErrors mode="RemoteOnly">
نمایش منبع خطا ممکن است ظاهرا خطرناک به نظر نرسد. اما در نظر داشته باشید از نظر یک هکر با نمایش منبع خطا، امکان جمع آوری اطلاعات مفیدی در رابطه با وب سایت و در نتیجه نفوذ به آن می باشد.
در واقع منبع های اصلی خطاها، اطلاعات طلایی برای هکر ها بشمار می آیند. بطور مثال در ساختار خطاهای پیش فرض ASP.NET، هنگام دریافت exception های مربوط به خطا، اطلاعاتی نظیر ورژن ویندوز مربوطه، نسخه مورد استفاده IIS و یا حتی امکان تشخیص فایل های مربوط به برنامه های تحت وب را برای هکر ها فراهم می کند. بطور مثال در صورت دریافت خطای مربوط به SqlException، هکر متوجه ورژن مورد استفاده sql می شود.
لذا همواره جهت ایمن نمودن سایت خود، صفت mode را در <customErrors> روی On ویا RemoteOnly قرار دهید ویا راه دیگر ریدارکت کردن کاربر به صفحه جدید با استفاده از صفت defaultRedirect موجود در بخش <customErrors> می باشد. لذا تنها زمانی که نیاز به بررسی خطای احتمالی و دیدن جزئیات بیشتر می باشد، آن را Off نمایید.
-
فعال بودن قابلیت Tracing :
خصوصیت Trace در ASP.NET یکی از پرکاربردترین ابزارهای آن می باشد که امکان debug نمودن اپلیکشن ها را فراهم می کند.
با این وجود این ابزار یکی از منابع اصلی هکر ها برای نقوذ می باشد.
کد اشتباه:
<configuration> <system.web> <trace enabled="true" localOnly="false">
کد صحیح:
<configuration> <system.web> <trace enabled="false" localOnly="true">
هنگامی که قابلیت trace برای کاربران remote فعال باشد (localOnly=”false”)، امکان دیدن لیستی از جزئیات درخواست های اخیر به اپلیکیشن با مراجعه به صفحه trace.axd توسط همه کاربران فراهم می شود.
لاگ مربوط به trace، اطلاعات ارزشمندی نظیر ورژن .NET و ASP.NET مربوطه، لاگ کاملی از متدهای به کار رفته در آن و زمان اجرای آن ها، درخواست و پاسخ کوکی های (cookies) بکار رفته، هدر درخواست های ارسالی و مجموعه کاملی از متغیر های سرور (server variables) را در اختیار هکرها قرار خواهد داد.
بطور مثال هکر ها به راحتی با تفحص در لاگ های مربوطه، می توانند اطلاعات ایمیل های اصلی را استخراج کنند و از آن ها به عنوان ارسال اسپم استفاده کنند، یا پسورد های مرتبط به کاربری های اصلی را دریافت کنند، ویا اطلاعات بانکی افراد شرکت ها و .... را شنود کنند.
لذا همواره مقدار پارامتر localOnly را true قرار داده تا فقط کاربران مجاز امکان دسترسی به آن را داشته باشند.
-
فعال بودن debug :
توسعه برنامه های تحت وب در حالت debug یکی از اشتباهات رایج می باشد. همچنین همانطور که می دانید در Visual Studio 2005 هنگام دیباگ نمودن برنامه، تغییرات مربوطه روی فایل Web.config بصورت اتوماتیک اعمال می شوند.
کد اشتباه:
<configuration> <system.web> <compilation debug="true">
کد صحیح:
<configuration> <system.web> <compilation debug="false">
همانند دو اشتباه رایج که پیشتر توضیح دادیم، فعال بودن حالت دیباگ می تواند ساختار درونی و اطلاعات مفیدی را در اختیار کاربران نهایی که مجوز دسترسی آن را ندارند و از جمله هکر ها قرار دهد.
به عنوان مثال با فعال بود مد debug و نیز خاموش بودن وضعیت خطاهای سفارشی در برنامه، هکر ها نه تنها اطلاعات مفیدی در رابطه با اطلاعات سرور، پیغام های استثناها (exception) و trace خواهند داشت بلکه به کدهای منبع اصلی صفحه مربوطه (در جایی که خطا رخ داده است)، دسترسی خواهند داشت.
متاسفانه تنظیمات پیکربندی، تنها راه دسترسی به منابع اصلی کدها در وب سایت نیست. بطور مثال در نسخه های قبلی ASP.NET AJAX، هنگام بروز خطا، حتی با وجود فعال بودن خطاهای سفارشی در فایل Web.config، باعث نمایش کدهای اصلی سایت، در مرورگر کاربران می شد.
لذا همواره مقدار عنصر <compilation> را در صفت debug، روی مقدار پیش فرض false و یا مقادیر دیگر قرار دهید. همواره در نظر داشته باشید که بهتر است از مقادیر پیش فرض استفاده نکنید.
-
دسترسی به کوکی ها توسط اسکریپت های سمت کاربر :
در ورژن Internet Explorer 6.0، مایکروسافت قابلیت جدید برای کوکی ها (Cookies)، با عنوان HttpOnly در نظر گرفته است که می توانید در فایل Web.config نیز آن را مدیریت نمایید.
کد اشتباه:
<configuration> <system.web> <httpCookies httpOnlyCookies="false">
کد صحیح:
<configuration> <system.web> <httpCookies httpOnlyCookies="true">
قراردادن مقدار ویژگی HttpOnly ، روی True، باعث می شود که کوکی ها تنها از طریق کدهای سمت سرور قابل دسترسی باشند و اجازه اجرای کدهای سمت مشتری نظیر JavaScript ویا VBScript را نمی دهد. این تنظیم در برنامه های تحت وب، باعث جلوگیری از حملات اسکریپتی تحت عنوان Cross-Site خواهد شد.
در حملات Cross-Site (که به اختصار CSS یا XSS نیز نامیده می شود)، هکرها تلاش می کنند که کدهای اسکریپت آلوده خود را در صفحات وب وارد نمایند. هر صفحه ای از وب که اجازه دریافت و اجرای کدها را از سمت کاربر فعال نموده باشد و یا داده های ورودی ها را به کاربران برگرداند، به راحتی در معرض آلودگی قرار می گیرند.
به عنوان مثال اگر در صفحه ورود سایت که از کاربران نام کاربری و پسورد را دریافت می کند و پیغام هایی نظیر "کاربر گرامی، <username> خوش آمدید،" را ارسال می کنند، ممکن است در معرض حملات XSS قرار گیرند.
همچنین در بلاگ ها، فروم ها (Forums) و سایت های ویکی پدیا (Wikis) و ...، در قسمتی که کاربران نظرسنجی می شوند و یا امکان قرار دادن نظر و یا پیشنهاد خود را دارند، در صورتی که پست های مربوطه بلافاصله در سایت نمایش داده شوند، به شدت در معرض حملات هکر ها هستند.
زیرا به راحتی، هکر ها می توانند با وارد کردن کدهای اجرایی بجای پست، نظیر کد “<script>alert(document.cookie);</script>”، اسکریپت های مخرب را بارگذاری نمایند. لذا دیگر کاربران، که به این سایت مراجعه می کنند، ناخواسته کد مخرب در مرورگر آنها اجرا می شود.همچنین هکر ها می توانند با گذاشتن اسکریپت های مشابه، به اطلاعات ورود کاربران شامل نام کاربری و پسورد ها دسترسی پیدا کنند.
اما در صورتی که در فایل Web.config مقدار ویژگی HttpOnly، روی True باشد، این مقادیر از کاربران مخفی خواهد ماند و در نتیجه نتیجه تلاش هکر ها بی ثمر خواهد شد.
از آنجا که امکان فعال سازی HttpOnly روی کوکی های مختلف توسط برنامه نویسی می باشد؛ اما بهتر آن است مقدار ویژگی HttpOnly برای تمامی کوکی ها صورت اتوماتیک فعال نمایید. جهت اینکار به سادگی می توانید مقدار صفت httpOnlyCookies را روی True تنظیم کنید.
-
فعال بودن قابلیت Cookieless Session :
اگر شما برنامه نویس وب باشید، حتما با مفهوم Session و Cookie آشنایی دارید. همانطور که می دانید در ورژن قدیمی تر ASP.NET، امکان انتقال session token ها بین درخواست ها نبود و در نتیجه تا اتمام جلسه/نشست (session)، session token در کوکی ذخیره می شد. اما در ورژن های جدیدتر، امکان تنظیم session token، توسط قابلیت cookieless ارائه شده است.
کد اشتباه:
<configuration> <system.web> <sessionState cookieless="UseUri">
کد صحیح:
<configuration> <system.web> <sessionState cookieless="UseCookies">
برنامه های کاربردی تحت وبی که از قابلیت cookieless session استفاده می کنند، بجای استفاده از کوکی ها، session token ها را در انتهای URLها ذخیره نمایند.
بطور مثال هنگامی که کاربر به سایتی وارد می شود و نام کاربری و پسورد خود را وارد می نماید، آدرس URL کاربر از http://tajanweb.com/default.aspx به آدرس http://tajanweb.com/(123456789ABCDEFG)/default.aspx تغییر می یابد. عبارت داخل پرانتز یعنی (123456789ABCDEFG)، معرف همان session token می باشد که برای هرکاربر یکتا و منحصر به فرد می باشد و تا مدت زمان مشخصی در URL باقی می ماند.
افزودن این قابلیت جدید به ASP.NET، باعث شکل گرفتن نوعی دیگر از حملات هکر ها موسوم به session hijacking شده است. Session hijacking در واقع نوعی سرقت اطلاعات محسوب می شود؛ به این صورت که هکر با دزدیدن session token مربوط به کاربران اصلی، اقدام به جعل هویت نموده و خود را به جای کاربر اصلی جا می زند.
در واقع هنگامی که session token ها، به عنوان بخشی از URL ها در نظر گرفته شوند، هکر ها به راحتی می توانند با به کار گیری ابزار های مانیتورینگ نظیر sniffer ها، اطلاعات را شنود (sniff) کنند و یا با دسترسی به آخرین لاگ درخواست های ارسال شده، session token را در انتهای URL ها تشخیص داده و اقدام به جعل هویت (hijacking) کاربران نمایند.
لذا با توجه به اینکه نرم افزار های تحت وب این قابلیت را ندارند که تشخیص دهند که درخواست جدید با session token سرقت شده، از منبع اصلی درخواست ارسال نشده است، به راحتی درخواست های جدید که از سمت هکر ارسال می شود، را اجرا خواهد کرد.
اما هنگامی که session token ها در کوکی ها قرار داشته باشند و کانال های ارتباطی نیز توسط پروتکل امنیتی SSL ایمن شده باشند، مشکل امنیتی فوق وجود نخواهد داشت.
بهترین و موثرترین روش برای جلوگیری از حملات Session hijacking، استفاده از کوکی ها جهت ذخیره سازی session token ها می باشد. جهت این کار می بایست در نرم افزار های تحت وب، صفت cookieless را برابر مقدار UseCookies و یا false قرار داد.
اما در این صورت سوالی که مطرح می شود این است که تکلیف کاربرانی که در مرورگر های خود کوکی ها را غیر فعال نموده باشند، چگونه می شود؟ خوشبختانه در ASP.NET 2.0، راه حلی جهت آن دسته از کاربران نیز ارائه شده است؛ بدین صورت که با تنظیم مقدار صفت cookieless روی مقدار AutoDetect، در صورت فعال بودن کوکی، session token در کوکی ذخیره خواهد شد و در غیر این صورت در URL ها قرار خواهد گرفت.
و نکته جالب توجه این است که کاربرانی که کوکی ها غیر فعال می نمایند، تصور می کنند که بهترین راه را جهت بالا بردن امنیت سایت/سیستم به کار برده اند.
جهت اطلاعات بیشتر می توانید به مقالات مرتبط زیر رجوع نمایید:
