PDA

View Full Version : سوال: امنیت سشن و لاگین؟



iroogle
چهارشنبه 30 مرداد 1387, 18:01 عصر
با سلام خدمت تمامی عزیزان
میخواستم بدونم امنیت سشن در ای اس پی دانت چقدره؟
آیا امکان داره هکر بتونه اون مقدار رو تغییر بده؟
بهترین و امن ترین راه برای اینکه اطلاعات یک یوزر رو نگه داریم چیه استفاده از سشن تنها امنیت رو به صورت کامل برای ما بوجود میاره یا ادقام اون با کوکی و یا روش های دیگه؟

Behrouz_Rad
چهارشنبه 30 مرداد 1387, 18:49 عصر
امنیت سشن در ای اس پی دانت چقدره؟

امنیت Session معمولاً ارتباطی با زبان برنامه نویسی نداره. مگر الگوریتمی که برای تولید SID استفاده میشه که ASP.NET برای Session از 128 بیت برای تولید SID استفاده می کنه.


آیا امکان داره هکر بتونه اون مقدار رو تغییر بده؟

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


بهترین و امن ترین راه برای اینکه اطلاعات یک یوزر رو نگه داریم چی

این کاملاً بستگی به سناریوی شما داره. در حالتی که اطلاعات مهمی از کاربر نگهداری نمیشه کوکی خوب هست اما اگر نیاز به نگهداری اطلاعات مهمی وجود داره - که البته به ندرت این حالت به وجود میاد - Session و Cache خوب هستند.

برای اطلاعات بیشتر در مورد امنیت در ASP.NET، مقاله ی امنیت در ASP.NET نوشته ی بنده که به عنوان اعلان در همین بخش هست رو مطالعه بفرمایید.

موفق باشید.

mohsen_zelzela00
چهارشنبه 30 مرداد 1387, 18:56 عصر
امنیت Session معمولاً ارتباطی با زبان برنامه نویسی نداره. مگر الگوریتمی که برای تولید SID استفاده میشه که ASP.NET برای Session از 128 بیت برای تولید SID استفاده می کنه.

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



ببخشید آقای راد میشه بگید که چطوری میشه از Session Hijacking جلوگیری کنیم واقعاً خیلی وقته دارم رو امنیت Session کار میکنم ولی متاسفانه به هیچ نتیجه ای نرسیدم ممنون میشم کمکم کنید

mehdi.mousavi
چهارشنبه 30 مرداد 1387, 19:08 عصر
امنیت Session معمولاً ارتباطی با زبان برنامه نویسی نداره. مگر الگوریتمی که برای تولید SID استفاده میشه که ASP.NET برای Session از 128 بیت برای تولید SID استفاده می کنه.



سلام.
SID ای که توسط ASP.NET تولید میشه، 120 بیت هست، نه 128 بیت.

mehdi.mousavi
چهارشنبه 30 مرداد 1387, 19:10 عصر
ببخشید آقای راد میشه بگید که چطوری میشه از Session Hijacking جلوگیری کنیم واقعاً خیلی وقته دارم رو امنیت Session کار میکنم ولی متاسفانه به هیچ نتیجه ای نرسیدم ممنون میشم کمکم کنید

سلام.
میتونید از روشی که در این مقاله (http://msdn.microsoft.com/en-us/magazine/cc300500.aspx) عنوان شده، استفاده کنید.

merlin_vista
چهارشنبه 30 مرداد 1387, 22:10 عصر
به نظر شما Membership بهتره يا روش اعتبار سنجي دات نت 1 . يا Session ها را چك كنيم (مانند كاري كه تو asp كلاسيك ميكرديم . )

Behrouz_Rad
چهارشنبه 30 مرداد 1387, 22:18 عصر
SID ای که توسط ASP.NET تولید میشه، 120 بیت هست، نه 128 بیت.

بله درسته.
در پست ذیل اشاره کرده بودم. فراموش کردم.
http://www.barnamenevis.org/forum/showpost.php?p=452114&postcount=18


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

اون روش 100 درصد نیست و میشه اون رو دور زد.
دلیلیش رو در پست ذیل بخون:
http://www.barnamenevis.org/forum/showpost.php?p=452324&postcount=21



ببخشید آقای راد میشه بگید که چطوری میشه از Session Hijacking جلوگیری کنیم واقعاً خیلی وقته دارم رو امنیت Session کار میکنم ولی متاسفانه به هیچ نتیجه ای نرسیدم ممنون میشم کمکم کنید

حقیقتش اینه که روش 100 درصدی وجود نداره. HttpOnly کردن کوکی تاثیر زیادی در افزایش ضریب امنیت Session داره.
البته روشی در ذهن من هست که مدتی روی اون کار کردم اما نصفه کاره موند. اگر وقت بشه تکمیلش کنم فکر کنم روش مطمئنی باشه.

موفق باشید.

Behrouz_Rad
چهارشنبه 30 مرداد 1387, 22:30 عصر
Membership بهتره يا روش اعتبار سنجي دات نت 1 . يا Session ها را چك كنيم (مانند كاري كه تو asp كلاسيك ميكرديم . )

شاید قضاوت در این باره کمی سخت باشه.
من نظر خودم رو میگم.
من از Membership Provider ای که در دات نت 2.0 عرضه شد استفاده نمی کنم.
به نظر من دسترسی به جزئیات و اطلاع از پشت صحنه ی تصدیق هویت در سیستمی که در دات نت 1.0 عرضه شد بهتره.
در دات نت 2.0 این موارد همگی کپسوله شدن. من از برنامه نویسی Component-based صرف خوشم نمیاد. بیشتر سعی می کنم کنترل کدهام دست خودم باشه. کلاس هایی که برای سیستم تصدیق هویت بر اساس دات نت 1.0 نوشتم هنوز به خوبی و با قدرت جواب میدن. اگر Reflector بزنی متوجه میشی که تمامی اجزای Membership در دات نت 2.0 از همون کلاس ها استفاده می کنن. پس چه لزومی داره که من به این سیستم جدید با تمامی دردسرهایی که برای مهاجرت داره از جمله اسکریپت های T-SQL ضعیفی که برای اون نوشته شده و ... سویچ کنم؟!
خیلی از امکانات دات نت 2.0 افتضاح هستند. یا استفاده از اونها مستلزم درگیر شدن با مواردی هست که آدم رو دلزده می کنن. نمونش سیستم Profile در دات نت 2.0 که اسکریپت های ضعیف و Select های سنگینش داد همه رو در آورده!

موفق باشید.

پ.ن: لطفاً بحث رو منحرف نکنید.

mehdi.mousavi
پنج شنبه 31 مرداد 1387, 11:51 صبح
اون روش 100 درصد نیست و میشه اون رو دور زد.

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


Caveats
Before deploying SecureSessionModule on a production Web server, you should consider several potential issues.
First, SecureSessionModule is not 100 percent effective in detecting illicit session ID cookies. If the attacker has the same network address as the victim (if both, for example, use the same proxy server) or can spoof the victim's network address, then User-Agent headers are the last line of defense. And User-Agent headers are easily spoofed by someone aware that User-Agent headers are being used to validate session IDs.
Second, if for some reason a user's network address or User-Agent headers vary from request to request, that user will lose access to her session state. Third, SecureSessionModule doesn't work with cookieless session state. It assumes session IDs are passed in cookies, not URLs.
Finally, SecureSessionModule hasn't been tested in a production environment. If you use it, I'd love to hear from you—especially about any glitches that arise. Note that Microsoft has considered building similar protections into ASP.NET, but has always shied away from it for backward compatibility concerns.


گذشته از همه این مسائل، باید خدمت iroogle عرض کنم که شما باید Tolerance ای برای حملات در نظر بگیرید. اولین سوال در مباحث امنیتی همواره اینه که "آیا چیزی که میخوام ازش محافظت کنم، اصلا ارزش محافظت شدن رو داره، یا خیر". در صورتیکه پاسخ به سوال اول مثبت بود، سوال دوم باید مطرح بشه: "تا چه سطحی میخوام از دارایی هام محافظت کنم!؟" در بسیاری از مواقع، پاسخ صریحی به این دو سوال، میتونه گره از کار طراح باز کنه.

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

موفق باشید.

merlin_vista
پنج شنبه 31 مرداد 1387, 15:40 عصر
من از Membership Provider ای که در دات نت 2.0 عرضه شد استفاده نمی کنم.

آيا دليل شما اينكه كه كد ها در دست خودتان نيست و تمام كارها به صورت روتين تنجام ميشه ، و شما به شخصه دوست داريد كد بنويسيد .


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

ميشه اين كلاس ها را به ما هم بدين ؟

و آيا اين روشي كه شما استفاده ميكنيد . هميني هست كه مقالش اينجاست (http://www.codeproject.com/KB/web-security/formsroleauth.aspx) يا چيز ديگه اي هست . (اگه روش ديگه اي هست و مقاله يا كتابي داره ميشه اينجا بگزاريد :لبخندساده:)

خواهش ميكنم كه در اين مورد خواص كه امنيت برنامه هاي وب را در بر ميگيره مانند هميشه نهايت تلاش خود را بكنيد .. :قلب:

ارادتمند شما مهرداد :چشمک:

Behrouz_Rad
پنج شنبه 31 مرداد 1387, 16:29 عصر
سرچشمه بسیاری از مشکلات امنیتی این نظریه هستش که یک سیستم 100% امن و غیر قابل نفوذه.

ما در این تاپیک در مورد تمامی مشکلات امنیتی یک سیستم بحث نمی کنیم. همون طور که از عنوان تاپیک هم مشخصه، در مورد امنیت Session صحبت می کنیم.
در این مورد خاص روشی 100 درصد وجود نداره اما مثلاً برای SQL Injection با پارامتریک کردن Command و استفاده از SP و به کار گیری صحیح sp_executesql این اطمینان رو به طور 100% داریم که خطری از بابت تزریق SQL به برنامه وجود نخواهد داشت. پس ما یک روش 100 درصد برای پوشاندن این نقیصه ی امنیتی داریم!


آيا دليل شما اينكه كه كد ها در دست خودتان نيست و تمام كارها به صورت روتين تنجام ميشه ، و شما به شخصه دوست داريد كد بنويسيد .

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


ميشه اين كلاس ها را به ما هم بدين ؟

خیر.


اين روشي كه شما استفاده ميكنيد . هميني هست كه مقالش اينجاست يا چيز ديگه اي هست .

بله.


خواهش ميكنم كه در اين مورد خواص كه امنيت برنامه هاي وب را در بر ميگيره مانند هميشه نهايت تلاش خود را بكنيد ..

هستیم در خدمتتون :)

merlin_vista
پنج شنبه 31 مرداد 1387, 19:18 عصر
هستیم در خدمتتون :)اختيار داريد . سايه تون ، كم نشه از سر ما !


اين روشي كه شما استفاده ميكنيد . هميني هست كه مقالش اينجاست يا چيز ديگه اي هست .
بله.در يه تاپيك از شما خونده بودم كه اين روش قديمي شده . آيا روش جديد تر از اين هم هست . اگه هست بگزاريد


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

Behrouz_Rad
پنج شنبه 31 مرداد 1387, 22:07 عصر
در يه تاپيك از شما خونده بودم كه اين روش قديمي شده . آيا روش جديد تر از اين هم هست . اگه هست بگزاريد

امکان نداره من همچین حرفی زده باشم! اتفاقاً همیشه افراد رو تشویق به استفاده از این روش می کنم!

merlin_vista
جمعه 01 شهریور 1387, 01:32 صبح
امکان نداره من همچین حرفی زده باشم! اتفاقاً همیشه افراد رو تشویق به استفاده از این روش می کنم!

درسته ؛ ميدونم كه شما به اين كار تشويق ميكنيد .
ولي من شيوه كد نويسي را ميگم .


ايني كه گفته بوديد همينه :

اون شیوه ی کد نویسی مال VS 2003 هست که به نظرم قبلا در یک chm دیدمش که البته اشتباه است!
http://barnamenevis.org/forum/showpost.php?p=542963&postcount=5

Behrouz_Rad
جمعه 01 شهریور 1387, 09:07 صبح
منظورم این قسمتش بود:


string redirectURL = "~/user/Default.aspx";
if (Request.QueryString["ReturnUrl"]!=null)
{
redirectURL = Request.QueryString["ReturnUrl"].ToString();
}

برای همین، گفتم به جای اون بنویس:


Response.Redirect(FormsAuthentication.GetRedirectU rl(txtUsername.Text, True), True)


پ.ن: merlin_vista@ برای تغییر دادن بحث تاپیک احتمالاً باید اخطاری بهت تعلق بگیره ;) لطفاً دقت کن.

negahe asman
شنبه 02 شهریور 1387, 11:59 صبح
سلام دوست عزیز
فکر می کنم علاوه بر استقاده از سشن شما اگر با استفاده ار الگوریتم md5 روی رمز عبور کاربرهات روزنگاری انجام بدی امنیت سایتت بالا می ره
امیدوارم مفید باشه

mehdi.mousavi
شنبه 02 شهریور 1387, 12:36 عصر
سلام دوست عزیز فکر می کنم علاوه بر استقاده از سشن شما اگر با استفاده ار الگوریتم md5 روی رمز عبور کاربرهات روزنگاری انجام بدی امنیت سایتت بالا می ره امیدوارم مفید باشه

سلام.
MD5 عموما دیگه مورد استفاده قرار نمیگیره، بجای اون از SHA و Tiger استفاده میکنن. البته، نظر شما کاملا درسته. اگر PWD ها پس از ترکیب با Salt Value، به Hash تبدیل بشن امنیت بالاتر خواهد رفت.