روش هایی که برای تامین امنیت وب سایت هایمان باید رعایت کنیم

[smm2006sh]

با سلام خدمت همه دوستان و برنامه نویسان حرفه ای

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

[smm2006sh]

با سلام
یه سری مطلب بسیار مفید در زمینه امنیت از آقای بهروز راد پیدا کردم مطمعنا به درد میخوره

اصول امنیتی ضروری برای ASP.net
در بالاترین سطح برنامه های وب، امنیت دو مقوله داره:
1) امنیتی که توسط برنامه نویس به وجود میاد.
2) امنیتی که توسط Host به وجود میاد.

مورد اول دست شما هست و می تونید اون رو کنترل کنید.
مورد دوم دست شما نیست و کنترلی بر اون ندارید. پس هاستی رو انتخاب کنید که تیم فنی خوبی داره و همیشه سیستمشون رو با Patch ها و برنامه های بروز شده حفظ می کنند.
روش های حفظ امنیت توسط برنامه نویس
سرچشمه ی امنیت از کد نشات میگیره.
یک کد خوب امنیت کافی رو به وجود میاره.
یک کد بد یا اصطلاحا Dirty Code، بلای جان برنامه نویس محسوب میشه.
پس زیبا کد بنویسید تا گام اول رو صحیح بردارید.
مدیریت اطلاعات مهم:
اطلاعات مهم مثل: نام کاربری، کلمه ی عبور، Connection String، اطلاعات لایسنس و ... هستند.
این مهمه که شما این اطلاعات رو در کجا نگهداری کنید.
مکان نگهداری این اطلاعات اصل ثابتی نیست و بیشتر جنبه ی پیشنهادی داره. معیارهای مختلفی در این انتخاب سهیم هستند.

1) برخی اطلاعات جنبه ی حیاتی دارند و حتی خود برنامه نویس هم بعد از انتشار برنامه نباید از اونها مطلع باشه. مثل کلمه ی عبور حساب بانکی یک فرد. در این حالت این کلمه ی عبور باید با یک الگوریتم Hash به رمز در بیاد و در دیتابیس ذخیره بشه.
الگوریتم های Hash برگشت پذیر نیستند مثل MD5.
بهتر هست که این دسته از اطلاعات با استفاده از یک بستر انتقال امن همانند SSL منتقل بشن.

2) برخی اطلاعات مهم هستند اما نیازی به رمزنگاری ندارند. مثل Connection String.
در این حالت برنامه نویس مطمئن هست که فقط خودش می تونه به این اطلاعات دسترسی داشته باشه نه شخص دیگری.
این اطلاعات بهتره در Web.Config ذخیره بشن.
سوال: در NET 2.0. امکان رمزنگاری (Encryption) محتویات فایل Web.Config وجود داره. آیا پیشنهاد میشه که از این امکان استفاده کنیم؟
پاسخ: نه برای هر نوع اطلاعاتی. به نظر من رمزنگاری Connection String کار بیهوده ای محسوب میشه. هیچ کس به جز شما و هاست به Web.Config دسترسی نداره.
نتیجه گیری اخلاقی: اگر فکر می کنید که احتمال ریختن سقف خونتون وجود داره، هیچ وقت در خونه نمونید! در غیر اینصورت به سقف خونتون اطمینان کنید.
یکی از مزایای مهم قرار دادن Connection String شما در Web.Config، استفاده از قابلیت Connection Pooling هست.
نتیجه گیری: Connection String رو همیشه بدون رمزنگاری در Web.Config قرار بدید.

3) برخی اطلاعات با دیگران به اشتراک گذاشته میشن اما اشتراک اونها شرط خاصی داره.
به عنوان مثال: لایسنس کامپوننتی که باید همراه با اون وجود داشته باشه.
این اطلاعات معمولا در فایلی با پسوند lic در کنار کامپوننت قرار دارند و مثلا می تونند حاوی Key تولید کننده ی سریال نامبر کامپوننت برای بررسی صحت سریال وارد شده توسط خریدار باشند.
این اطلاعات فقط باید توسط برنامه نویس قابل دسترسی باشند نه توسط فردی که اطلاعات با اون به اشتراک گذاشته شده.
این اطلاعات باید توسط یک الگوریتم، Code شوند. مثلا الگوریتم های کد کردن 64 یا 128 بیتی و یا از الگوریتم های متقارن همانند DES برای رمزنگاری اونها استفاده بشه.

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

1) الگوریتم Rijndael برای رمزنگاری متقارن خوب هست.
2) الگوریتم 3DES برای رمزنگاری داده هایی که مدت زیادی وجود دارند مناسب هست.
3) الگوریتم های RC2 و DES برای رمزنگاری داده هایی که عمر و ماندگاری کوتاه تری دارند مناسبند.
4) در رمزنگاری های متقارن و نامتقارن همیشه از کلیدهایی با اندازه ی طولانی استفاده کنید. طبق تحقیقاتی که چند وقت پیش شرکت مک آفی منتشر کرد، مشخص شد که شکستن کلیدهای طولانی اما ساده، بیشتر از کلیدهای پیچیده اما کوتاه زمان بر هست!
5) برای Hashing، الگوریتم های MD5 و SHA1 مناسب و کافی هستند.
6) اگر در رمزنگاری نیاز به تولید یک عدد تصادفی داشتید، از کلاس RNGCryptoServiceProvider استفاده کنید. این کلاس کاملا با الگوریتم ها رمزنگاری دات نت منطبق هست و اعداد کاملا تصادفی تولید می کنه. به کلاس Random نمیشه زیاد اعتماد کرد.

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

[sara_aryanfar]

با سلام اونچه که شما در این تاپیک به اون اشاره کردین خوبه اما خب اینا cms های آماده هستند و بیشتر دوستان وبلاگ نویس و کسانی که تنها می خوان مطلب ارسال کنن ازش استفاده می کنن حال آنکه دوستانی که اینجا جمع شدند کسانی هستند که می خواهند خودشون از پایه یک سایت رو بنویسن حالا اگر مطلب در مورد بالا بردن امنیت سایت های asp بود فکر می کنم بیشتر به درد دوستان می خورد موفق باشید

[fakhravari]

با سلام
من sara_aryanfar موافقم.
در کل من با کار smm2006sh موافقم .
اگه دوستان کمک کنند و مدیر این سایت هم کمک کنه یه بخش اضافه بشه به سایت چون من ندیدم چنین بخشی در باره امنیت سایت و کد های احتمالی آن.
اگر دوستان کمک کنند در همین پست ادامه بدیم

[smm2006sh]

ادامه مطالب بالا . . .

استفاده از تصاویر امنیتی در هنگام ورود اطلاعات:

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

محافظت از برنامه در برابر SQL Injection:

در مورد SQL Injection زیاد شنیدید.
به طور خلاصه، به تزریق کدهای SQL از طریق برنامه، SQL Injection گفته میشه.
شاید بشه گفت که خطرناکترین نوع حمله ای که می تونه به یک برنامه صورت بگیره SQL Injection هست که متاسفانه بسیاری از افراد اون رو نادیده میگیرن و نسبت به اون بی توجه هستن.
عدم توجه به توانایی تزریق SQL به برنامه، عملا دیتابیس رو در اختیار فرد مهاجم قرار میده و می تونه تمام هست و نیستی شما رو بر باد بده!
راه جلوگیری از SQL Injection، استفاده از پارامترها برای ارسال مقادیر به دیتابیس هست.
پارامترها می تونن همراه با Stored Procedure استفاده بشن و در صورت عدم استفاده از Stored Procedure ها، با نوشتن مستقیم دستورات SQL در کد برنامه نیز قابل استفاده هستند.
اون چیزی که مهم هست اینه که در هر شرایطی از پارامترها برای پاس دادن مقادیر ورودی به Command استفاده کنید.

برخی افراد برای مقابله با SQL Injection، برخی کلمات کلیدی SQL، نظیر DELETE، UPDATE، DROP و ... رو در رشته ی ورودی فیلتر می کنند.
این عمل ساده لوحانه، صرف نظر از ایجاد محدودیت برای برخی کلمات در ورودی و Poor Coding، نکته ای رو از دید این افراد دور نگه داشته و اون این هست که:
هر کاراکتر یک کد hexadecimal داره که می تونه به جای کاراکتر اصلی در ورودی قرار بگیره و بدین طریق میشه به راحتی کلمه ی محدود شده رو دور زد!
به عنوان مثال، معادل کلمه ی DROP، عبارت 0x440x520x4F0x50 هست!

از مطلب اخیر سوء استفاده نکنید ;)

مدیریت صحیح خطاها:

1) از روش های مدیریت خطای ساخت یافته (Try Catch Finally) برای هندل خطاهای برنامه استفاده کنید.

2) پس از تشخیص خطا بلافاصله در جهت رفع اون اقدام کنید و این کار رو به تاخیر نیندازید.

3) جزئیات خطا رو در جایی ذخیره کنید. این مکان تنها باید توسط شما قابل دسترسی باشد.

4) هیچگاه جزئیات خطا رو به کاربر نشان ندید. در عوض، پیغام های کلی رو که بیانگر بروز خطاست نمایش بدید.

5) قبل از انتشار برنامه، مقدار خاصیت mode تگ customErrors رو در Web.Config همیشه بر روی On یا RemoteOnly تنظیم کنید تا جزئیات خطاهای هندل نشده به کاربر نشان داده نشن.

6) در بند قبل، حتما صفحه ای رو برای برنامتون ایجاد کنید تا در صورت وقوع یک خطای هندل نشده، کاربر به این صفحه هدایت بشه. این صفحه رو با تنظیم مقدار خاصیت defaultRedirect تگ customErrors به نام این صفحه به برنامه معرفی کنید.

7) نام صفحه ای که موجب وقوع خطا شده در یک Query String با نام aspxerrorpath قرار می گیره و به صفحه ای که در بند قبل اشاره شد پاس داده میشه. از طریق بازیابی مقدار این Query String می تونید متوجه بشید که کدام صفحه موجب بروز خطا شده.

8) برخی خطاها ارتباطی با کدهای برنامه ندارند و یک عامل خارجی باعث رخ دادن اونها میشه. مثل تایپ نام صفحه ای که وجود نداره در Address bar توسط کاربر که باعث نمایش پیغام Page Not Found (کد 404) در مرورگر میشه. این نوع خطاها رو میشه به دو طریق هندل کرد.
یا از طریق زیر تگ error که یکی از زیر تگ های customErrors در Web.Config هست و یا از طریق هندل کردن روال Application_Error در فایل Global.asax.
به عنوان مثال، برای هندل کردن این مورد که صفحه ی مورد نظر وجود نداره، میشه به شکل ذیل در Web.Config عمل کرد:





در دستورات فوق، در صورتی که کاربر نام صفحه ای رو تایپ کنه که وجود نداره، به صفحه ای با نام myPageNotFound.htm هدایت میشه.
برای هندل کردن خطا در روال Application_Error نیز متد GetLastError کلاس Server رو فراخوانی کنید.
نکته ی مهم: در این حالت، در آخرین خط این روال، متد ClearError کلاس Server رو حتما فراخوانی کنید تا Stack از خطا خالی بشه و خطا مجددا رخ نده.

9) قبل از انتشار برنامه، trace رو با تنظیم خاصیت enabled تگ trace در Web.Config به false غیر فعال کنید.
امنیت ViewState

ViewState مفهومی در برنامه های ASP.NET برای حفظ وضعیت کنترل های صفحه در هنگام PostBack هست.
ViewState می تونه توسط فرد مهاجم دستکاری بشه و داده های ارسال شده رو مثلا مستعد حملات XSS کنه. (در مورد XSS به زودی می نویسم)
ASP.NET قابلیتی رو با نام Message Authentication Check که به اختصار MAC نامیده میشه فراهم می کنه تا صحت ViewState برای عدم دستکاری شدن اون بررسی بشه. (MAC گاهی اوقات مخفف Machine Authentication Check نیز در نظر گرفته میشه)
EnableViewStateMac به طور پیش فرض فعال هست.
وضعیت کنترل های صفحه به صورت یک مقدار رشته ای که با یک الگوریتم رمزنگاری 64 بیتی کد شده همراه با صفحه به کلاینت ارسال میشه. این مقدار در یک فیلد مخفی با نام VIEWSTATE__ قرار می گیره که در صورتی که Source صفحه رو در مرورگر ببینید، این مقدار مشهود هست.
در صورتی که EnableViewStateMac فعال باشه، بر روی ViewState الگوریتم SHA1 اعمال میشه (کلید این الگوریتم Hash در تگ فایل machine.config تعریف شده و توسط LSA به طور خودکار تولید میشه) و یک مقدار Hash شده به دست میاد که این کد قبل از ارسال ViewState به کلاینت به انتهای اون اضافه میشه.
این کد پس از PostBack صفحه مجددا بررسی میشه و اگر ViewState توسط فرد مهاجم دستکاری بشه، مسلما مقدار متفاوتی از مقدار اولیه به دست میاد. در این هنگام خطایی رخ میده و ViewState رو Invalid اعلام می کنه.

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

ادامه دارد . . .

[mehran_sh_t]

اکثر مواردی که smm... گفتن، برای شروع این بحث (نه فقط برای cms و ...) خوب بود. اکثرش جامع بود.

یکی از موارد امنیتی که باید در نوشتن دستورات لحاظ بشه، جلوگیری از حمله SQL Injection هستش.

فرض کنید کدی مانند زیر داریم:

SELECT * FROM sampleTable WHERE ID = txtID.Text

حالا اگر حمله کننده بیاد در textbox بنویسه:

''; DROP TABLE users

به سادگی یک جدول رو می تونه از بین ببره! یا به اطلاعات جدول دست پیدا کنه

جایی خونده بودم که stored procedure و یا استفاده از LINQ از این حملات جلوگیری می کنه

[mehran_sh_t]

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

فرض کنیم یک وبلاگ داریم، برای ادمین می تونیم یک یوزر تعریف کنیم که امکان نوشتن و ویرایش و ... رو داشته باشه (همه جا!) برای کاربرای عادی، یک یوزر که امکان مشاهده و فقط نوشتن در بخش نظر ها.

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

[mehran_sh_t]

در بعضی موارد پیش میاد که وبسایت در شرایطی دچار خطا میشه و خطا رو نشون میده، این می تونه به حمله کننده کمک کنه.
سعی کنید خطا های وبسایت رو خودتون مدیریت کنید. می تونید از فایل Global.aspx و رویداد Application_OnError (اگر درست نوشت باشم) استفاده کنید، و در صورت بروز خطا، کاربر رو به یک صفحه خاص هدایت کنید (نزارید خطا رو ببینه)
البته این مورد جزء موارد زیبایی و کارایی وبسایت هم به حساب میاد

[mehran_sh_t]

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

برای نمونه، موردی که برای دانشگاه ما پیش اومده بود و سرور یک روز تعطیل بود، فک کنم یک ربات طراحی شده بود که الکی لاگین می کرد (به تعداد زیاد) بار روی سرور زیاد شد، و نتیجه ای که گفتم پیش اومد!

[smm2006sh]

ادامه مطالب بالا . . .

محافظت از فایل ها از دسترسی غیر مجاز:

DNN ماژولی برای مدیریت خطاها داره که خطاها رو در یک فایل XML ذخیره می کنه.
در بررسی کدهای DNN مورد جالبی رو دیدم که می تونه ایده ی خوبی برای محافظت از فایل ها از دسترسی غیر مجاز باشه.
وقتی درخواستی به IIS ارسال میشه، اون درخواست تنها در صورتی توسط IIS هندل میشه که جزء پسوندهایی باشه که برای IIS شناخته شده است.
برای دیدن لیست این پسوندها در IIS بر روی Default Web Site راست کلیک و گزینه ی Properties رو انتخاب کنید. در سربرگ Home Directory بر روی دکمه ی Configuration کلیک کنید.
فرض کنید نیاز دارید تا فایل های ZIP رو از دسترسی کاربر غیر مجاز دور نگاه دارید.
دو راه دارید:
1) پوشه ی محتوی فایل های ZIP رو به عنوان پوشه ی Protected از طریق Control Panel معرفی کنید.
2) این کار رو به IIS واگذار کنید.

اگر به روش اول عمل کنید، با محدودیت هایی مواجه میشید. مثلا فرض کنید پرتالی ایجاد کردید و این پرتال رو به مشتری میدید. اگر هاستی که مشتری از اون استفاده می کنه امکان Protected Folders رو فراهم نکنه، با مشکل مواجه میشید. و یا فرضا فایل مورد نظر شما به هر دلیلی باید در ریشه ی اصلی سایت وجود داشته باشه. در این حالت اگر یک Site Map داشته باشید، موتور جستجوگر نمی تونه به Site Map شما دسترسی داشته باشه.

و اما روش دوم:
واگذار کردن وظیفه ی حفاظت از فایل ها به IIS روش خوبی هست اما پسوند فایل باید به IIS معرفی بشه. فایل ZIP جزء پسوندهای شناخته شده توسط IIS نیست و طبیعتا باید این پسوند رو به اون معرفی کرد.
کمتر هاستی این کار رو برای شما انجام میده و اگر هم انجام بده در قبال اون هزینه ای رو دریافت می کنه.
ترفندی که میشه در اینجا استفاده کرد، تغییر پسوند فایل ZIP به یکی از پسوندهایی است که توسط IIS شناخته شده است. DNN پسوند resourcers. رو بدین منظور استفاده کرده تا اگر فردی آدرس مستقیم فایل رو در Address bar وارد کرد، چون پسوند resources. جزء پسوندهایی هست که IIS اون رو هندل می کنه، پس به راحتی میشه دسترسی به این فایل رو کنترل کرد.
اگر خواستید به کاربر اجازه ی دانلود فایل رو بدید، به راحتی با Stream کردن فایل می تونید این کار رو انجام بدید.
همون طور که احتمالا می دونید، یکی از خطوط دانلود فایل به طریق Stream، تعیین هدر "Content-Disposition" هست که در اون می تونید "نام و پسوند واقعی" فایل رو قرار بدید:
Response.AddHeader("Content-Disposition", "attachment; filename=myFile.zip")

محافظت از برنامه در برابر حملات XSS

حملات XSS یکی از خطرناکترین حملاتی هستند که بسیاری از سایت ها، پرتال ها و فروم های معروف نیز مستعد این نوع حملات هستند.
مستعد بودن برنامه به تزریق کدهای Client Side از طریق ورودی برنامه و عدم تعیین اعتبار ورودی باعث ایجاد حملات XSS میشه.
البته XSS گاهی اوقات با نام CSS نیز شناخته میشه اما به این دلیل که با Cascade Style Sheet اشتباه گرفته نشه، با عنوان XSS شناخته و استفاده میشه.
بیشترین و متداولترین خسارتی که XSS به برنامه وارد می کنه، دزدیدن Cookie کاربر و استفاده از اون به نفع فرد مهاجم هست.
حالتی رو در نظر بگیرید که کاربر فرمی رو پر می کنه و اون رو ارسال می کنه. اگر در فیلدهای این فرم به جای اطلاعات مرسوم، کدهای Client Side وارد شده باشند، کاربر به راحتی در معرض آسیب پذیری خطرناکی قرار می گیره.
فرض کنید من به عنوان فرد مهاجم، عبارت رو وارد کنم.
این عبارت به عنوان یک مقدار ذخیره میشه. همچنین یک کوکی تصدیق هویت یا یک کوکی که حاوی اطلاعات مهمی (مثلا شماره حساب بانکی) از کاربر هست بر روی سیستم کاربر ذخیره کردیم.
در ادامه فرض کنید که قسمتی رو برای نمایش اطلاعات وارد شده به کاربر در نظر گرفتید. کاربر در زمان لود صفحه، شماره حساب خودش رو می بینه!
من می تونم ورودی رو کمی تغییر بدم تا این اطلاعات برای من ارسال بشه. چون در اینجا قصد بر آموزش هک نیست وارد جزئیات نمیشم.

توجه داشته باشید که مقصود از ورودی هر جایی در برنامه ی شماست که اطلاعات از اون طریق به سرور ارسال میشه. این مکان می تونه Query String و هدرهای HTTP نیز باشه.

راه های مختلفی برای مقابله با حملات XSS وجود داره.

اولین و مهم ترین گام، تعیین اعتبار مقادیر ورودی هست.
بهترین راه برای تعیین اعتبار، استفاده از Reqular Expressions یا همان عبارات باقاعده هست.
دومین گام، کد کردن مقادیر ورودی هست.
برای کد کردن مقادیر ورودی میشه از متد HtmlEncode کلاس HttpUtility استفاده کرد.
برای کد کردن URL از متد UrlEncode کلاس HttpUtility استفاده کنید.

نکته ی بسیار مهمی که باید به اون توجه داشته باشید این هست که فقط به کد کردن داده ها در ورودی اکتفا نکنید. اگر به هر دلیلی داده های کد نشده در دیتابیس ذخیره بشن (مثلا در حالتی که یک دیتابیس توسط دو برنامه استفاده میشه و یکی از برنامه ها مستعد XSS هست) برنامه ی دیگه نیز می تونه آسیب پذیر باشه. در این حالت حتی هنگام Bind کردن منبع داده به کنترل و مثلا استفاده از توابع Eval یا Bind، قبل از آن متد HtmlEncode رو به شکل ذیل فراخوانی کنید:
<%# HttpUtility.HtmlEncode(Eval("myFieldName")) %>

نکته 1:
در IE 6.0 SP1 خصوصیتی با نام HttpOnly برای کوکی ها در نظر گرفته شد که در صورتی که یک کوکی این خصوصیت رو داشته باشه، اجازه ی دسترسی به اون به کدهای Client Side داده نمیشه.
این خاصیت رو می تونید از طریق تنظیم خاصیت HttpOnly کلاس HttpCookie تنظیم کنید.
خوشبختانه پشتیبانی از این خصوصیت از نسخه ی 2.0.0.5 در Firefox نیز لحاظ شده اما باگی در Firefox وجود داره که با استفاده از هسته ی اصلی AJAX که همون XMLHTTPRequest هست میشه به کوکی دسترسی داشت.
این باگ در IE 7.0 برطرف شده.
جزئیات بیشتر در مورد این باگ رو در لینک ذیل بخونید:
http://ha.ckers.org/blog/20070719/fi...mlhttprequest/

نکته 2: ابزارهایی همچون Anti-Cross Site Scripting Library توسط مایکروسافت به منظور مقابله با XSS در ASP.NET برای برنامه نویسان عرضه شده.

نتیجه گیری پایانی: وجود خصوصیت HttpOnly که البته خوب هست دلیلی بر این نیست که نسبت به حملات XSS بی توجه باشید.

[fakhravari]

https://barnamenevis.org/showthread.p...x-%D9%87%D8%A7
کسی اطلاعات این پست بدردش خورد

[moferferi]

سلام.
اگه از روش ado.net entity data model استفاده بشه ایا باز هم احتمال حملات sql injection هست ؟

[crazy_1892]

اینم نگاه کنبد بد نسیت
http://www.aspcode.ir/Articles.aspx?cat=security

[nunegandom]

با درود بی پایان، یه مقاله تویه چنته داشتم گفتم بذارم براتون. منبع itsecteam.com
شاید جدیدش هم اومده باشه البته!
http://www.mediafire.com/?rdhdaxex6t5rbne
در ضمن میتوانید از نرم افزار acunetix استفاده کنید، کرک شدش رو تویه ashiyane.org دیدم!

[smm2006sh]

با سلام دوباره
امیدوارم اینم به دردتون بخوره

تامین امنیت کامل وب سایت توسط Acunetix Web Vulnerability Scanner 7.0

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

نرم افزار Acunetix Web Vulnerability Scanner یک نرم افزار مافوق حرفه ای و قوی با کاربری بسیار آسان است که به شما کمک میکند تا وب سایت خود را به صورت کامل آنالیز کرده و کلیه مشکلات امنیتی آن از قبیل XSS, SQL Injection, مشکلات وب سرور، مشکلات مربوط به مسئله کوکی ها و ... را شناسایی کنید و نسبت به رفع آنها اقدام نمایید.
از جمله ویژگی های منحصر به فردی که میتوان برای این نرم افزار ذکر کرد عبارتند از : امکان لیست کردن کلیه پوشه ها و فایلهای موجود بر روی سرور، امکان گزارش گیری از خطاهای مجمود، سیستم ویژه ی آنالیز کدهای آژاکس، ابزار ویژه ی شبیه سازی هک ها و تست سایت در شرایط مختلف و ...

ویژگی های کلیدی نرم افزار Acunetix Web Vulnerability Scanner 7.0 :

- امکان اسکن کامل وب سایت و یافتن مشکلات امینتی وب سایت
- سیستم ویژه ی آنالیز وب سرور ها و یافتن حفره های امنیتی سرور
- یافتن مشکلات امنیتی از جمله XSS, SQL Injection و ...
- امکان گزارش گیری کامل از مشکلات لیست شده
- دارای محیط کاربری بسیار ساده و در عین حال قدرت مال فوق حرفه ای
- ابزار ویژه ی جستجو در دایرکتوی وب سایت و لیست کردن فایلها و پوشه های موجود
- ابزار ویژه ی تست هک از جمله HTTP, HTTP Sniffer, HTTP Fuzer Editor
- بررسی دیتابیس ها از لحاظ امنیت اطلاعات آنها و امکان نفوذ به آنها
- و...

موفق باشید

[smm2006sh]

ادامه مطالب بالا. . .

محافظت از برنامه در برابر Session Hijacking

یکی از قدیمی ترین حملاتی که به برنامه های وب صورت می گیره، Session Hijacking (سرقت Session) هست.
برای آشنایی با این نوع حمله بهتره که کمی در مورد نحوه ی هندل کردن Session ها در ASP.NET صحبت کنیم.
Session برای نگهداری داده هایی به کار میره که برای هر کاربر منحصر به فرد هستند. مثلا نمایش نام کاربر پس از لوگین، در تمامی صفحات سایت.
Session در حافظه ی سرور نگهداری میشه. ASP.NET برای اینکه بتونه تشخیص بده که هر Session متعلق به کدام کاربر هست، مشخصه ای یکتا برای هر Session ایجاد می کنه و این مشخصه رو در یک کوکی با نام ASP.NET_SessionID قرار میده. با ایجاد هر درخواست به سرور، ASP.NET مشخصه ی موجود در این کوکی رو بررسی می کنه و از این طریق متوجه میشه که کدام Session در حافظه ی سرور متعلق به کاربر هست.
به این مشخصه ی یکتا Session ID گفته میشه.
پر واضح هست که اگر کوکی ها در مرورگر کاربر غیر فعال باشند، استفاده از Session عملا کاربردی نداره.

به طور خلاصه اگر فردی بتونه این کوکی رو به سرقت ببره، به راحتی می تونه خودش رو صاحب Session شما معرفی کنه.
میزان خطری که Session Hijacking در پی داره به نوع اطلاعاتی که در اون هست و نحوه ی استفاده ی برنامه نویس از Session بستگی داره.
به عنوان مثال، در حالتی که از Session تنها برای نگهداری نام کاربری استفاده میشه، سرقت Session سودی برای فرد مهاجم نداره چون تنها چیزی که ممکنه نصیب اون بشه (که البته باز هم بستگی به نحوه ی برخورد برنامه نویس با Session داره) نام کاربری هست!
اما اگر مثلا شماره ی حساب بانکی یا سطح دسترسی کاربر در Session ذخیره میشه با خطری جدی مواجه هستید.

Session Hijacking معمولا به دو طریق انجام می گیره:
1) حدس زدن Session ID
2) سرقت کوکی حاوی Session ID

حدس زدن Session ID
این مورد به ندرت اتفاق می افته چون ASP.NET به طور خودکار این ID رو تولید می کنه و اعدادی که تولید میشن 120 بیتی و کاملا راندوم هستند. البته میشه تولید این ID ها رو خودتون با استفاده از کلاس SessionIDManager بر عهده بگیرید اما این کار اصلا پیشنهاد نمیشه. فرضا اگر روال شما برای اختصاص SessionID یک عدد تصاعدی مثل فیلدهای از نوع AutoNumber در SQL Sever باشه، فرد مهاجم می تونه با بررسی چند باره ی محتویات کوکی ذکر شده، از این روش مطلع بشه.

سرقت کوکی حاوی Session ID
در مورد سرقت کوکی در مقاله ی قبلی توضیح دادم. XSS می تونه یکی از روش هایی باشه که منجر به سرقت کوکی ها میشه.

راهکار مقابله به Session Hijacking
راهکاری که میشه استفاده کرد، "منحصر به فرد تَر کردن" Session ID هست.
بدین شکل که برخی مشخصه های کاربر همانند IP و User Agent رو همراه با یک کلید رمز و خود SessionID به یک الگوریتم Hash همانند HMACSHA1 که یک کلید رو برای رمزنگاری می پذیره داد و رشته ی رمزنگاری شده رو به انتهای SessionID اضافه کرد.
فرایند فوق رو به راحتی میشه از طریق یک HttpModule پیاده سازی کرد.
روال EndRequest مکان خوبی برای الصاق مشخصه ی به دست آمده به انتهای SessionID هست.
روال BeginRequest نیز می تونه برای بررسی صحت این مشخصه استفاده بشه.

کدنویسی بر عهده ی خودتون ;)

نتیجه گیری پایانی: هر چند که هیچ روشی همواره امنیت رو به طور صد در صد تضمین نمی کنه، اما امنیت رو باید یک وضعیت نسبی در نظر گرفت. مجموعه تلاش هایی که انجام میدیم تا راه نفوذ به برنامه رو برای فرد مهاجم سخت تر کنیم.

[smm2006sh]

در اين مقاله به بررسي Forms Authentication خواهيم پرداخت .

همانگونه که در بخش اول اين مقاله اشاره گرديد ، برنامه هاي وب ASP.NET از سه روش عمده به منظور تائيد کاربران استفاده مي نمايند :


Windows Authentication


Forms Authentication


Passport Authentication


در Forms Authentication ، برنامه IIS مسئوليتي را در ارتباط با تائيد کاربران برعهده نگرفته و تنظيمات امنيتي IIS در رابطه با برنامه وب ، دستيابي Anonymous مي باشد . فرآيند تائيد کاربران در روش فوق، بصورت زير است :


زمانيکه سرويس گيرنده درخواست يک صفحه ايمن را مي نمايد ، IIS کاربر را به عنوان Anonymous، تائيد و در ادامه درخواست وي را براي ASP.NET ارسال مي نمايد .


ASP.NET ، بررسي لازم در خصوص وجود يک کوکي خاص بر روي کامپيوتر سرويس گيرنده را انجام خواهد داد .


در صورتيکه کوکي ، موجود نبوده و يا غيرمعتبر باشد ، ASP.NET درخواست کاربر را ناديده گرفته و براي وي يک صفحه Logon را ارسال مي نمايد ( مثلا" Login.aspx ).


کاربر اطلاعات لازم ( نام و رمز عبور ) را در صفحه Logon.aspx ( به عنوان نمونه ) درج و در ادامه دکمه Submit موجود بر روي فرم را به منظور ارسال اطلاعات براي سرويس دهنده ، فعال مي نمايد.


IIS ، مجددا" کاربر را به عنوان Anonymous، تائيد و درخواست وي را براي ASP.NET ارسال مي نمايد .


ASP.NET ، تائيد کاربر را بر اساس اطلاعات ارسالي ( نام و رمز عبور ) انجام و يک کوکي را ايجاد مي نمايد .


در نهايت ، صفحه وب ايمن درخواست شده به همراه کوکي جديد براي سرويس گيرنده ارسال مي گردد. ماداميکه کوکي معتبر باشد ، کاربر قادر به درخواست و مشاهده ساير صفحات وب مي باشد.





فرآيند فوق را مي توان به دو حالت متفاوت تعميم و مورد توجه قرار داد :



حالت اول : درخواست يک صفحه ايمن از سرويس دهنده ، توسط يک کاربر غيرمجاز و تائيد نشده


مرحله اول : پس از درخواست يک سرويس گيرنده براي دستيابي به يک صفحه ايمن ، درخواست ارسالي وي در ابتدا توسط IIS بررسي و با توجه به اينکه تنظيمات IIS بصورت Anonymous پيکربندي شده تا امکان استفاده از Forms Authentication فراهم گردد ، درخواست کاربر ، مستقيما" براي ماژول ASP.NET Forms Authentication ارسال مي گردد .


مرحله دوم : ASP.NET ، بررسي لازم در خصوص وجود ( داشتن ) يک کوکي Authentication را انجام خواهد داد . با توجه به اينکه کاربر اولين مرتبه است که درخواست اطلاعاتي را نموده و داراي يک کوکي نمي باشد ، سرويس گيرنده به صفحه Logon ، هدايت مي گردد .


مرحله سوم : کاربراطلاعات ضروري ( نام و رمز عبور ) خود را در صفحه Logon درج و پس ازارسال آنان ،فرآيند بررسي اطلاعات ارسالي آغاز مي گردد. در يک برنامه بزرگ ، بررسي اطلاعات کاربر از طريق يک بانک اطلاعاتي شامل مشخصات کاربران انجام مي شود .


مرحله چهارم : در صورتيکه اطلاعات ارسالي کاربر ( نام و رمز عبور ) ، پس از بررسي توسط برنامه وب ، معتبر شناخته نگردند ، مجوز دستيابي براي کاربر صادر نشده و امکان دستيابي وي سلب مي گردد .


مرحله پنجم : در صورتيکه پس از بررسي اطلاعات ارسالي، اعتبار وصحت آنان تائيد گردد ، يک کوکي تائيد ايجاد و در ادامه به کاربر مجوز لازم به منظور دستيابي به صفحه ، اعطاء مي گردد .(هدايت کاربر به صفحه درخواست اوليه ) .



حالت دوم : درخواست يک صفحه ايمن از سرويس دهنده ، توسط يک کاربر مجاز و تائيد شده


مرحله اول : پس از درخواست يک صفحه ايمن توسط سرويس گيرنده ، کوکي Authentication بهمراه درخواست وي براي سرويس دهنده ، ارسال مي گردد.


مرحله دوم :درخواست ارسالي توسط سرويس گيرنده در ابتدا توسط IIS دريافت و با توجه به تنظيمات انجام شده ( دسيتابي Anonymous ) ، درخواست وي مستقيما" براي ASP.NET Forms Authentication ارسال مي گردد .


مرحله سوم : ماژول ASP.NET Forms Authentication ، بررسي لازم در خصوص کوکي را انجام و در صورتيکه کوکي معتبر باشد ، سرويس گيرنده تائيد و امکان دستيابي و مشاهده صفحه وب درخواستي براي وي ، فراهم مي گردد .



در روش Forms Authentication ، بصورت اتوماتيک يک فرم وب طراحي شده به منظور اخذ اطلاعات مربوط به نام و رمز عبور کاربران ، نمايش داده مي شود . کد مرتبط با فرم وب ، عمليات تائيد و معتبرسازي کاربر را بر اساس ليست ذخيره شده در فايل Web.Config برنامه و يا از طريق يک بانک اطلاعاتي جداگانه ، انجام مي دهد. مزيت مهم Forms Authentication ، عدم ضرورت عضويت کاربران در Domain شبکه به منظور دستيابي به برنامه وب ، مي باشد .



فعال نمودن Forms Authentication


به منظور استفاده از روش فوق ، مي بايست مراحل زير را دنبال نمود :



مقداردهي Authentication mode در فايل Web.config به Forms



ايجاد يک فرم وب به منظور اخذ اطلاعات کاربران ( Logon Page )



ايجاد يک فايل و يا بانک اطلاعاتي به منظور ذخيره نام و رمز عبور کاربران



نوشتن کد لازم به منظور افزودن کاربر جديد به فايل و يا بانک اطلاعاتي کاربران



نوشتن کد لازم به منظور تائيد کاربران با استناد به فايل و يا بانک اطلاعاتي کاربران



Forms Authentication ، از کلاس هاي موجود در namespace با نام System.Web.Security استفاده مي نمايد . به منظور استفاده از کلاس هاي فوق، مي بايست در ويژوال بيسک دات نت از عبارت Imports و در ويژوال سي شارپ از Using استفاده گردد ( در ابتداي هر ماژول که عمليات تائيد را انجام خواهد داد : Imports System.Web.Security ) .



مقداردهي Authentication mode


نوع تائيد کاربران در يک برنامه وب ، مي بايست با استفاده از عنصر <authentication> در فايل Web.config مشخص گردد. به منظور تنظيم برنامه مورد نظر خود براي استفاده از Forms Authentication ، تغييرات زير را در فايل Web.Config ، اعمال مي نمائيم :



Web.Config setting for Forms Authentication

<authentication mode="Forms">
<forms loginUrl = Login.aspx" >
<credentials passwordFormat = "Clear" >
<user name = "Ali" Password ="110" />
<user name = "Kaveh" Password ="111" />
</credentials>
</forms>
</authentication>




کد فوق، يک نوع ساده از تائيد کاربران به روش Forms را نشان مي دهد . در اين رابطه ، اغلب از تعاريف و تنظيمات پيش فرض و يک ليست کاربران مجاز، استفاده شده است. از عناصر متفاوتي در ارتباط با Forms Authentication در فايل Web.Config استفاده مي گردد.هر يک از عناصر داراي خصلت هاي خاص خود مي باشند :


عنصر <authentication>

خصلت Mode ، با استفاده از خصلت فوق ، روش تائيد و شناسائي کاربران مشخص مي گردد. با مقدار دهي خصلت فوق به Forms ، روش Forms Authentication انتخاب خواهد شد.


عنصر <forms>

خصلت name . از خصلت فوق به منظور مشخص نمودن نام کوکي که اطلاعات مربوط به نام و رمز عبور را ذخيره مي نمايد ، استفاده مي شود .
مقدار پيش فرض ، authaspx . مي باشد . در صورتيکه بيش از يک برنامه بر روي سرويس دهنده از روش Forms Authentication استفاده مي نمايند ، مي بايست براي هر يک از آنان نام منحصربفردي در نظر گرفته شود .

خصلت loginUrl .از خصلت فوق به منظور مشخص نمودن نام فرم وب Login براي کاربران تائيد نشده ، استفاده مي گردد . مقدار پيش فرض خصلت
فوق، Default.aspx است .

خصلت protection . با استفاده از خصلت فوق روش حفاظت کوکي Authentication که بر روي کامپيوتر سرويس گيرنده ذخيره مي گردد ، مشخص خواهد شد. مقدار پيش فرض خصلت فوق ، All بوده که عمليات رمزنگاري و بررسي اعتبار و صحت داده در رابطه با آن اعمال مي گردد. ساير گزينه هاي موجود در اين راستا ، Encryption,Validation و None مي باشد .

خصلت timeout . با استفاده از خصلت فوق ، مدت زمان نگهداري کوکي Authentication بر روي ماشين کاربر مشخص مي گردد . مقدار پيش فرض 30 دقيقه است . ASP.NET ، پس از دريافت يک درخواست جديد توسط کاربر و مشروط به گذشت بيش از نصف زمان تعريف شده ، کوکي را تجديد ( Renew ) خواهد کرد .

خصلت path . با استفاده از خصلت فوق ، مسير مورد نظر به منظور ذخيره سازي کوکي بر روي ماشين کاربر مشخص مي گردد . مقدار پيش فرض ، "\" است .


عنصر <credentials>

خصلت passwordFormat ، با استفاده از خصلت فوق ، الگوريتم لازم به منظور رمزنگاري رمز عبور کاربر ، مشخص مي گردد . مقدار پيش فرض ، SHA1 مي باشد . ساير گزينه هاي موجود در اين رابطه ، MD5 و Clear ( بدون رمزنگاري ) مي باشد .


عنصر <users>

خصلت name ، با استفاده از خصلت فوق ، نام کاربر مشخص مي گردد.

خصلت password ، با استفاده از خصلت فوق ، رمز عبور کاربر مشخص مي گردد.


عنصر <credentilas> ، امکان ذخيره سازي ليست کاربران را در Web.Config فراهم مي نمايد . رويکرد فوق ، روشي ساده به منظور تعريف کاربران مجاز يک برنامه وب مي باشد . در چنين مواردي ، مديريت سيستم مي تواند بسادگي و در صورت لزوم نام و رمز عبور کاربران ديگري را به ليست مجاز کاربران ، اضافه نمايد . مکانيزم فوق ، در مواردي که قصد داشته باشيم ، امکان تعريف نام و رمز عبور را در اختيار کاربران قرار دهيم ، گزينه مناسبي نبوده و مي بايست از يک فايل و يا بانک اطلاعاتي به منظور ذخيره سازي اطلاعات کاربران ، استفاده گردد.

[A.Yousefi]

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

[smm2006sh]

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

[A.Yousefi]

پس بی زحمت زیر هر کدوم از پستاتون لینک منبشو هم ذکر کنید.