فروش ویژه : ثبت دامنه آی آر IR فقط 99 هزار تومان سفارش آنلاین/ تحویل آنی
فروش ویژه : ثبت دامنه دات کام COM فقط 990 هزار تومان سفارش آنلاین/ تحویل آنی (بهترین پیشنهاد)
فروش ویژه : 1500 مگابایت هاست ابری به همراه SSL رایگان ماهیانه فقط 99 هزار تومان مشاهده مشخصات و پلن ها
نقاط آسیب پذیری و ضعف های امنیتی در فایل Web.config (قسمت دوم)
بسیاری از مشکلات متداول و خطرناک امنیتی و نقاط آسیب پذیری سایت ها در برنامه ها و اپلیکیشن های تحت وب ASP.NET، مربوط به کدهای XML می باشد که در فایل پیکربندی Web.config مورد استفاده قرار می گیرند. این در حالیست که میزان آسیب پذیری سایت ها از کدهای C# ویا VB.NET بسیار کمتر و تقریبا ناچیز می باشد.
تنظیمات اشتباه در فایل های پیکربندی، دریچه های وب سایت را بر روی حفره های امنیتی و حملاتی نظیر session hijacking، Cross-Site Scripting attacks باز خواهد کرد و حتی هکر ها امکان دستیابی به اطلاعات طلایی و خصوصی را خواهند داشت.
مشکل دیگری که وجود دارد، این است که هر زمان که نیاز باشد، می توان تنظیمات مربوط به فایل Web.config را تغییر داد. با توجه به این که فایل های پیکربندی .NET، به صورت سلسله مراتبی عمل می کنند و کوچک ترین تغییرات روی فایل اصلی Machine.config، روی تک تک وب سایت های موجود در شبکه تاثیرگذار خواهد بود.
در قسمت اول مقاله، در مورد مهمترین اشتباهات رایج در فایل Web.config و نحوه پیشگیری از حملات هکرها توضیح داده شد. در قسمت دوم این مقاله بر روی مشکلات امنیتی مجوزهای دسترسی (authorization) و احراز هویت (authentication) تمرکز نموده و نیز پیرامون قابلیت ارث بری فایل Web.config و نحوه تاثیر گذاری آن در امنیت فایل، به طور کامل توضیح خواهیم داد.
-
فعال بودن احراز هویت روی کوکی ها :
با توجه به توضیحات کامل ارائه شده در قسمت فعال بودن قابلیت Cookieless Session ها که در مقاله قبل توضیح داده شد، فعال بودن احراز هویت روی کوکی ها نیز باعث حمله hijacking و مشکلات امنیتی خواهد شد.
کد اشتباه :
<configuration> <system.web> <authentication mode="Forms"> <forms cookieless="UseUri">
کد صحیح :
<configuration> <system.web> <authentication mode="Forms"> <forms cookieless="UseCookies">
هنگامی که token مربوط به جلسه (session) و یا احراز هویت (authentication)، به جای کوکی ها (cookie) در انتهای URLها قرار بگیرد، هکرها با استفاده از ابزار های مانیتورینگ شبکه، امکان دسترسی به session مربوطه را داشته و اقدام به جعل هویت خواهند نمود.
با این وجود حمله session hijacking زمانی بسیار آسیب رسان و خطرناک می شود که پس از این که کاربر اصلی با وارد کردن نام کاربری و پسورد، وارد سایت شده باشد، هکر نسبت به دریافت session token مربوطه نموده باشد. در این صورت هکر به اطلاعات ارزشمندی دسترسی پیدا خواهد نمود.
به عنوان مثال فرض نمایید در سایت های فروشگاه آنلاین، کاربران قادرند بدون نیاز به وارد کردن نام کاربری و پسورد خود، از قسمت های مختلف سایت بازدید کنند. اما پس از اینکه سفارشی را ثبت نمایند و یا بخواهند به اطلاعات شخصی تر نظیر جزئیات سفارش، اطلاعات کاربر، آدرس شرکت و.... دسترسی پیدا کنند، نیاز به لاگین به سایت می باشد. حال اگر هکر قبل از لاگین کاربر اقدام به جعل هویت ویا hijacking کنند، مسلما اطلاعات زیادی نصیبشان نمی شود؛ اما در صورتی که پس از لاگین کاربر بتوانند session token را شنود کنند، به اطلاعات بیشتری دسترسی پیدا خواهند نمود.
لذا بهترین کار آن است که همواره مقادیر cookieless را در عنصر <forms> به UseCookies تغییر دهید.
-
عدم استفاده از SSL در کوکی ها:
برنامه های تحت وب از پروتکل SSL (مختصر شده Secure Sockets Layer)، جهت رمزنگاری داده ها و اطلاعات تبادلی بین کاربران و وب سرورها استفاده می کنند. استفاده از پروتکل SSL، باعث می شود که دستیابی به اطلاعات اصلی و تفسیر آن، با استفاده از روش های شنود (Sniff) اطلاعات، توسط هکرها به حداقل برسد و برخلاف درخواست های plaintext، در صورت شنود تنها با انبوهی از داده های رمز شده، بی معنی و غیر قابل حدس مواجه می شوند.
شما می توانید برای استفاده از SSL، مقدار صفت requireSSL را در عنصر <forms>، برابر true قرار دهید.
کد اشتباه :
<configuration> <system.web> <authentication mode="Forms"> <forms requireSSL="false">
کد صحیح :
<configuration> <system.web> <authentication mode="Forms"> <forms requireSSL="true">
شاید جالب باشد که بدانید با توجه به لزوم ذخیره سازی authentication token در کوکی ها، این اقدام تنها قدم اول جهت جلوگیری از حملات جعل هویت (hijacking) می باشد. بدین معنا که به جز در مواردی که درخواست ها رمزگذاری شده باشند، هکر ها هنوز امکان دسترسی به authentication token را خواهند داشت.
دلیل این امر این است که اکثر مرورگرها، URL کامل درخواست را در کش (History Cache) خود نگه می دارند. لذا در صورت آلوده شدن کش مرورگر، اطلاعات حیاتی کاربران، به راحتی در اختیار هکر ها قرار خواهند گرفت.
لذا می بایست علاوه بر ذخیره نمودن authentication token در کوکی ها، حتما درخواست ها را توسط پروتکل SSL، رمزنگاری نمایید که در صورت دسترسی هکرها به کوکی مرورگر، امکان تشخیص token ها در کوکی ها نباشد.
همچنین جهت استفاده از پروتکل SSL علاوه بر اعمال تنظیمات فوق، می بایست تغییرات لازم سمت IIS را نیز اعمال نمایید.
-
فعال بودن slidingExpiration :
همانطور که می دانید برای تمامی نشست های احراز هویت در ASP.NET، مهلت زمانی خاصی (timeout interval) جهت بالا بردن امنیت در نظر گرفته می شود و مقدار پیش فرض آن 30 دقیقه می باشد. در نتیجه پس از اولین لاگین کاربران به سایت، به صورت اتوماتیک پس از 30 دقیقه از سیستم خارج شده و نیاز به ورود مجدد اطلاعات لاگین می باشد.
کد اشتباه :
<configuration> <system.web> <authentication mode="Forms"> <forms slidingExpiration="true">
کد صحیح :
<configuration> <system.web> <authentication mode="Forms"> <forms slidingExpiration="false">
تنظیمات slidingExpiration، ابزاری جهت ایمن نمودن برنامه کاربردی می باشد و هنگامی که authentication token توسط هکر ها به سرقت رفته باشد، باعث به حداقل رساندن ریسک امنیتی اپلیکیشن ها می شود.
هنگامی که مقدار slidingExpiration روی false تعریف گردد، بازه زمانی لاگین کاربران، به جای آن که از زمان توقف فعالیت کاربر در سایت در نظر گرفته شود، از اولین ورود آن ها به سایت در نظر گرفته خواهد شد.
همواره بهتر است مقدار slidingExpiration روی false قرار گیرد. دلیل این امر این است که در صورتی که هکر ها به هر طریقی دسترسی به authentication token پیدا کرده باشند، تنها قادرند در بازه زمانی مشخص شده به فعالیت های مخرب خود در سایت ادامه دهند. زیرا هکر ها تنها از طریق token به اطلاعات کاربری دسترسی پیدا نموده اند و لذا پس از خروج از سایت، امکان لاگین مجدد آن ها، به دلیل نداشتن نام کاربری و پسورد میسر نمی باشد. (به طور مثال ممکن است جهت تغییر پسورد فعلی، نیاز به دانستن پسورد قبلی باشد، که در این صورت هکر نتواند پسورد را بازنشانی نماید.)
هنگامی که slidingExpiration فعال باشد، بازه زمانی لاگین کاربران، از زمان توقف فعالیت کاربر در سایت در نظر گرفته شود. در نتیجه هکر می تواند تا هر زمانی که می خواهد در کاربری مربوطه لاگین بماند، مشروط بر این که هر چند دقیقه یکبار (معمولا در نصف بازه زمانی لاگین، مثلا هر 15 دقیقه یکبار) درخواست جدیدی به سمت سرور ارسال کند.
در نتیجه مقدار صفت slidingExpiration را در عنصر <forms>، همواره روی false قرار دهید تا از بروز آسیب های جدی تر پس از دسترسی هکر و حمله به سایت جلوگیری نمایید.
-
استفاده از نام های کوکی غیر یکتا
تاکنون در رابطه با به کار بردن اقدامات امنیتی و پیشگیرانه و نیز ضرورت ذخیره سازی توکن ها در کوکی ها صحبت نمودیم. اما توجه داشته باشید که کوکی ها فراتر از تنها مقدار (value) بودن، می باشند. در واقع کوکی ها ترکیبی از جفت نام ها و مقادیر می باشند.
لذا با توجه به این نکته، انتخاب نام نادرست برای کوکی ها نیز به همان میزان انتخاب محل (location) نامناسب، باعث آسیب پذیری سایت و به وجود آمدن حفره های امنیتی خواهد شد.
کد اشتباه :
<configuration> <system.web> <authentication mode="Forms"> <forms name=".ASPXAUTH">
کد صحیح :
<configuration> <system.web> <authentication mode="Forms"> <forms name="{abcd1234…}">
مقدار پیش فرض برای نام کوکی احراز هویت، .ASPXAUTH می باشد. در صورتی که تنها یک اپلیکیشن کاربردی روی سرور باشد، مقدار پیش فرض آن بسیار مناسب و ایمن می باشد. اما در صورتی که در سرور اپلیکیشن های تحت وب متعدد ASP.NET قرار داشته باشد، ضروری است که جهت هر اپلیکیشن نام کوکی یکتا و منحصر به فردی در نظر گرفته شود. در صورتی که نام کوکی یکتا نباشد، هرکاربری که به هر کدام از اپلیکیشن های وب لاگین نماید، قادر هواهد بود به تمامی آن ها دسترسی داشته باشد.
بطور مثال، در صورتی که کاربری به سایت فروشگاه آنلاین جهت مشاهده جزئیات سفارش خود لاگین نماید، قادر خواهد بود که برنامه های ادمین روی سایت مربوطه دسترسی داشته باشد و بطور نمونه قیمت برخی اقلام را در سبد خرید تغییر دهد.
لذا جهت اطمینان از این که هر برنامه تحت وب تنها کاربران مختص خود را داشته و نیز کاربران تنها دسترسی های محدودی به آن برنامه تحت وب خاص دارند، می بایست برای کوکی های احراز هویت، نام های منحصر به فردی در نظر گرفت.
برای این کار شما می توانید از Globally Unique Identifiers (GUIDs) استفاده نمایید و در نتیجه منحصر به فرد بودن نام کوکی ها تضمین خواهد شد. جهت استفاده از GUIDs، به منوی Tools وارد شده و نتیجه دستور Create GUID، را در صفت name عنصر <forms> کپی نمایید.
-
استفاده از نام های کوکی غیر یکتا
جهت تست برنامه های تحت وب ایجاد شده و انتقال اطلاعات و دیتابیس ها به سرور ها واقعی وب، جهت جلوگیری از اتلاف وقت طراحان سایت، مایرویافت بخش زیر را در فایل Web.config، اضافه نموده است که شما می توانید به راحتی کاربری تستی با نام کاربری و پسورد مربوطه را جهت تست نمودن قسمت های برنامه تحت وب، در آن قرار دهید.
<authentication mode="Forms"> <forms> <credentials> <user name="bob" password="bob"/> <user name="jane" password="Elvis"/> </credentials> </forms> </authentication>
اشتباه رایج آن است که نام کاربری و پسورد به صورت متنی plaintext، در فایل Web.config قرار گیرد. در این صورت هرکس که دسترسی خواندن (read) به فایل Web.config داشته باشد، به راحتی می تواند با پسورد مربوطه لاگین نماید. لذا در صورت نیاز به کاربر تست، حتما از الگوریتم های رمزنگاری اطلاعات نظیرSHA-1 ویا MD5 جهت وارد کردن پسورد ها استفاده نمایید.
کد اشتباه :
<configuration> <system.web> <authentication mode="Forms"> <forms> <credentials> … </credentials> </forms>
کد صحیح :
<configuration> <system.web> <authentication mode="Forms"> <forms> </forms>
بهترین و ایمن ترین روش این است که اطلاعات لاگین مربوطه را در فایل پیکربندی وارد نکنید و عنصر <credentials> را از فایل Web.config حذف نمایید.
-
اقدامات تکمیلی :
در صورت بکار بردن اقدامات امنیتی گفته شده، بسیاری از حملات مربوطه کاسته خواهد شد و فایل پیکر بندی شما، مصون از آسیب های جدی خواهد بود ولی آیا این تمام آن چیزی است که ما نیاز داریم انجام دهیم؟مسلما پاسخ این سوال جواب منفی می باشد.
از آنجایی که فایل های پیکربندی از مراتب ارث بری سلسله بندی شده، استفاده می کنند، لذا تمامی فایل های پیکربندی ویژگی ها را از فایل Web.config اصلی/والد به ارث خواهند برد و در انتها تمامی فایل های پیکربندی، از تنظیمات سراسری (global) فایل اصلی به نام Machine.config که در پوشه NET Framework به ارث خواهند برد.
با توجه به این که تغییر در فایل های اصلی/والد پیکربندی، روی تنظیمات پیکربندی سایر فایل ها نیز تاثیر گذار خواهد بود، این امر ممکن است عواقب ناخواسته ای به دنبال داشته باشد. ممکن است ادمین سایت، جهت برطرف نمودن مشکل خاصی، روی یکی از فایل های پیکربندی تغییری به ظاهر عادی ایجاد نماید، اما این تغییر ممکن است توسط فایل های پیکربندی درونی تر به ارث برده شده و باعث ایجاد حفره های امنیتی روی آن گردد. بطور مثال، ممکن است کاربر خاصی ادعا کند، دسترسی به برنامه خاصی بدون نیاز به فعال کردن کوکی امکان پذیر نمی باشد و در نتیجه ادمین سایت، cookieless authentication را در فایل پیکربندی اصلی تغییر دهد.
بهترین راه حل جهت حفاظت از فایل های پیکربندی در مقابل تغییرات سهوی و ناخواسته، این است که هیچ گاه بر تنظیمات پیش فرض روی فایل های پیکربندی اعتماد نکنید.
بطور مثال، قابلیت debugging بطور پیش فرض غیر فعال می باشد. ممکن است در فایل پیکربندی خاصی این مقدار تعریف نشده (blank) باشد و در نتیجه شما تصور نمایید که به طور پیش فرض این مقدار غیر فعال است. حال آن که ممکن است در فایل پیکربندی والد سهوا این مقدار را فعال نموده باشید ویا بعدا جهت برطرف سازی مشکل خاصی آن را فعال نموده باشید، در نتیجه به دلیل ارث بری این مقدار روی فایل جاری نیز فعال خواهد بود.
نتیجه گیری :
در این مقالات راه های نفوذ و حفره های امنیتی موجود در فایل های پیکربندی Web.config را به طور کامل بررسی نموده و نحوه سوء استفاده هکر ها از نقاط ضعف روی تنظیمات به کار رفته درفایل های پیکربندی و نیز راه های پیش گیری از مشکلات امنیتی و بستن راه نفوذ هکر ها را بیان نمودیم.
در نهایت اکید پیشنهاد می شود از ابتدای شروع کد نویسی برنامه تا زمان توسعه نهایی و تحویل آن همواره با به کار بردن نکات امنیتی گفته شده در این مقالات، نسبت به ایمن نمون سایت خود از ابتدا اقدام نموده تا وب سایت شما در دنیای پرفراز و نشیب اینترنت، بیش از پیش از حمله هکر ها در امان باشد.
جهت اطلاعات بیشتر می توانید به مقالات مرتبط زیر رجوع نمایید:
