در این مقاله به بررسی 5 اشتباه امنیتی متداول که در فایل پیکربندی برنامه های تحت وب (web.config) صورت می گیرد، می پردازیم.

1 . غیر فعال نمودن خطاهای سفارشی:

پیکربندی آسیب پذیر:

پیکربندی امن:

در صورتی که خاصیت mode در قسمت خطاهای سفارشی (CustomErrors) برابر Off باشد، هنگام بروز خطا در برنامه اطلاعات ارزشمندی جهت دیباگ بر روی صفحه وب چاپ می شود. این اطلاعات حتی می توانند قطعه ای از سورس کد برنامه نیز باشند. این اطلاعات می توانند برای هکر ها و افراد بدخواه بسیار ارزشمند باشند. نوع نسخه سیستم عامل، نسخه ی وب سرور، نسخه ی پایگاه داده و نسخه سفارشی شده از برنامه (در صورتی که از برنامه های متن باز استفاده شده باشد) از جمله اطلاعاتی می باشند که می توانند مورد سوء استفاده قرار گیرند.

برای رفع این مشکل باید مقدار ویژگی mode را در قسمت خطاهای سفارشی برابر On یا RemoteOnly قرار دهیم. در این صورت هنگامی که خطایی در برنامه به وجود می آید، یک خطاهای عمومی بر روی صفحه وب چاپ می شود که دارای اطلاعات حساسی نیست. و ضمنا بهتر است که با استفاده از خاصیت defaultRedirect کاربر را به صفحه ای که قبلا آماده نموده ایم و شامل پیام سفارشی ما می باشد (مثلا  پیغامی جهت پوزش از مشکل به وجود آمده از کاربر) بفرستیم.

با اینکه این خطای امنیتی یکی از پیش پا افتاده ترین مطالب دنیای امنیت در برنامه های تحت وب می باشد ولی متاسفانه به وفور وب سایت هایی یافت می شوند که در حال حاضر نیز دارای این مشکل می باشند.

2 . فعال نمودن قابلیت trace در فایل پیکربندی:

قابلیت trace یکی از مفیدترین ویژگی های زبان ASP.NET می باشد که جهت دیباگ نمودن و بررسی وقایع اتفاق افتاده در صفحات وب سایت استفاده می شود. این ویژگی هم از طریق صفحه وب و هم از طریق فایل web.config قابل فعال شدن می باشد.

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

مثال:

با فعال بودن قابلیت trace اطلاعات بسیار ارزشمند و حساسی از جمله کلید منحصر به فرد استفاده شده در Session state و Application state، تمامی متغییر های سرویس دهنده (Server Variables) ، مجموعه کامل هدر های موجود در درخواست، متغیر های فرم و..... به نمایش در می آید. این اطلاعات می تواند ارزش فراوانی برای یک هکر داشته باشد. به طور مثال بررسی متغیر APPL_PHYSICAL_PATH که نمایشگر محل فیزیکی صفحه وب می باشد می تواند نقطه آغازی برای حملاتی از نوع پیمایش دایرکتوری (Directory Traversal) باشد.

تذکر:

نکته ی خطرناک قابلیت trace این است که این ویژگی فقط زمانی خود را نشان می دهد که عبارت trace.axd در انتهای آدرس صفحه نوشته شود و بنابراین اگر شما فراموش کنید که این ویژگی در فایل web.config فعال شده است، هیچ نشانه ی خاصی باعث یادآوری این مسئله نخواهد شد!

برای رفع این مشکل پیشنهاد می شود که خاصیت enabled این ویژگی را در فایل پیکربندی برابر false قرار دهید و یا اگر قصد دیباگ برنامه را دارید خاصیت localOnly آن را برابر true قرار دهید. در این صورت فقط شما در سرور وب سایت می توانید اطلاعات مربوط به trace را مشاهده کنید و نه مخاطبین عادی برنامه.

پیکربندی آسیب پذیر:

پیکربندی امن:

3 . فعال بودن ویژگی دیباگ در فایل پیکربندی:

هنگامی که برای اولین بار برنامه ویژوال استودیو را در حالت دیباگ اجرا می کنیم، این برنامه در فایل web.config قابلیت دیباگ را فعال می کند و همواره فعال خواهد ماند. این ویژگی پس از Deploy شدن برنامه نیز فعال خواهد بود و در نتیجه در سرور اینترنتی سایت نیز فعال خواهد بود.

با فعال بودن این ویژگی و در صورتی که قابلیت خطاهای سفارشی (CustomErros) که قبلا به بحث در مورد آن پرداختیم، نیز برابر Off باشد، هنگام بروز خطا در برنامه، نه تنها اطلاعات stack trace، بلکه حتی قسمتی از سورس کد که باعث به وجود آمدن خطا گردیده است نیز در صفحه نمایش داده می شود!

برای حل این مشکل توصیه می شود که حتما این ویژگی را در فایل پیکربندی غیر فعال کنیم.

پیکربندی آسیب پذیر:

پیکربندی امن:

4 .  دسترسی به کوکی ها از طریق اسکریپت های سمت کلاینت:

یکی از ویژگی هایی که از زمان معرفی Internet Explorer 6.0 به کوکی ها (Cookie) ها اضافه شد، ویژگی HttpOnly می باشد. در صورتی که مقدار این ویژگی برابر false باشد، کوکی ها توسط زبان های جاوا اسکریپت و VB Script قابل دسترسی و تغییر می باشند.

کوکی ها با استفاده از عبارت document.cookies در زبان جاوا اسکریپت قابل دسترسی می باشند و در نتیجه یک هکر با استفاده از تزریق نمودن یک اسکریپ به صفحه (بخصوص در تالار های گفتمان یا شبکه های اجتماعی) می تواند حملاتی از نوع XSS را پایه گذاری نماید.

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

ویژگی HttpOnly را می توان هم در هنگام برنامه نویسی و ایجاد کوکی و هم در فایل web.config فعال نمود.

پیکربندی آسیب پذیر:

پیکربندی امن:

5. مدیریت حالت برنامه برای مرورگر هایی که کوکی ها را حمایت نمی کنند:

قبلا اینکه به معرفی این مشکل بپردازیم، به نکات زیر دقت کنید.

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

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

پیکربندی آسیب پذیر:

پیکربندی امن:

در تکنولوژی ASP.NET راه حلی برای حمایت از مرورگر هایی که از کوکی ها حمایت نمی کنند وجود دارد که در اینگونه موارد، شناسه ی منحصر به فرد Session کاربر از طریق آدرس صفحه منتقل می گردد.

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

در صورتی که مقدار ویژگی cookieless برابر UseUri باشد، آدرس بالا به شکل مشابه زیر تغییر می کند.

مقدار (S(dejudy45dwgi4f452rp4zj45))به ازای هر کاربر منحصر به فرد می باشد و با استفاده از این مقدار، سرور سایت کاربر را شناسایی می کند. این مقدار به طور معمول در کوکی ها ذخیره می شود ولی در صورتی که مقدار ویژگی cookieless برابر UseUri باشد، این ویژگی از طریق Url منتقل می گردد.

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

البته ویژگی cookieless می تواند برابر مقدار AutoDetect نیز باشد که دراین صورت شناسه ی منحصر به فرد Session کاربر تنها زمانی از طریق آدرس Url منتقل می شود که مرورگر او کوکی ها را پشتیبانی نکند. البته این ویژگی نیز مشکلاتی را همراه دارد و پیشنهاد می شود در مورد آن تحقیق کافی را به عمل آورید.