PDA

View Full Version : گفتگو: معایب استفاده از session



mohsen_zelzela00
یک شنبه 23 اسفند 1388, 20:50 عصر
با سلام
می خواستم معایب استفاده از Session در صفحات وب رو بهم بگید(معایب استفاده پیش از اندازه)
ممنون می شم دوستان لطف کنند و موارد رو بگند

Milad Mohseny
یک شنبه 23 اسفند 1388, 21:09 عصر
اطلاعات مهم رو در Session نگه ندار و همچنين اطلاعات حجيم رو چون براي هر كلاينت كه از سايتت بازديد ميكنه يه Session باز ميشه و اگه اطلاعات حجيم رو توش نگه داري و كاربرات زياد بشن سرور دچار فقدان حافظه شده و در نتيجه...
روزي 30 بار از روي محتويات لينك هاي زير به خودت ديكته بگو :بامزه: (شوخي كردم)
Session Hijacking (http://www.barnamenevis.org/forum/showpost.php?p=452114&postcount=18)
جهت انتقال اطلاعات بهتره از کدوم روش استفاده بشه (http://barnamenevis.org/forum/showthread.php?p=520129)
و ...
و ...

mohsen_zelzela00
یک شنبه 23 اسفند 1388, 21:32 عصر
من خودم از Session استفاده نمی کنم ولی شرکت یکی رو اورده که همون روز اولی می خوات رئیس شرکت بشه میگه باید Role کاربرها رو در Session ذخیره کنیم هر چی بهش گفتم بابا خطرناکه نکن این کارو می گه حرف فقط حرف خودمه

Peyman.Gh
یک شنبه 23 اسفند 1388, 21:46 عصر
پس از چی میخواهید استفاده کنید ؟! Session نسبت به کوکی ها امنیت بالاتری دارند و فقط استفاده زیاد ار آن برای سرور سنگین است و بس !

Milad Mohseny
یک شنبه 23 اسفند 1388, 21:56 عصر
اگه براي اينكار اسرار داريد دستورات لينك زير رو رعايت كنيد. من اطلاعات مهم رو تو session نگه نميدارم. شما خود دانيد. :لبخندساده:

Session Hijacking (http://www.barnamenevis.org/forum/showpost.php?p=452114&postcount=18)

Mostafa_Dindar
یک شنبه 23 اسفند 1388, 22:08 عصر
Use session when you are storing short-lived information that is specific to an individual session and security is an issue. Do not store large quantities of information in session state. Be aware that a session-state object will be created and maintained for the lifetime of every session in your application. In applications hosting many users, this can occupy significant server resources and affect scalabilityجواب كامل را در اين آدرس (http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx) ببينيد ولي به طور خلاصه :


Client-Side State Management Options ---------------------------------------------

View state

Use when you need to store small amounts of information for a page that will post back to itself. Using the ViewState (http://msdn.microsoft.com/en-us/library/system.web.ui.control.viewstate.aspx) property provides functionality with basic security.

Control state

Use when you need to store small amounts of state information for a control between round trips to the server.

Hidden fields

Use when you need to store small amounts of information for a page that will post back to itself or to another page, and when security is not an issue.

file:///C:/DOCUME%7E1/admin/LOCALS%7E1/Temp/msohtmlclip1/01/clip_image001.gifNote:

You can use a hidden field only on pages that are submitted to the server.

Cookies

Use when you need to store small amounts of information on the client and security is not an issue.

Query string

Use when you are transferring small amounts of information from one page to another and security is not an issue.

file:///C:/DOCUME%7E1/admin/LOCALS%7E1/Temp/msohtmlclip1/01/clip_image001.gifNote:

You can use query strings only if you are requesting the same page, or another page via a link.





Server-Side State Management Options----------------------------------------------------------------------------------
Application state
Use when you are storing infrequently changed, global information that is used by many users, and security is not an issue. Do not store large quantities of information in application state.
Session state
Use when you are storing short-lived information that is specific to an individual session and security is an issue. Do not store large quantities of information in session state. Be aware that a session-state object will be created and maintained for the lifetime of every session in your application. In applications hosting many users, this can occupy significant server resources and affect scalability.
Profile properties
Use when you are storing user-specific information that needs to be persisted after the user session is expired and needs to be retrieved again on subsequent visits to your application.
Database support
Use when you are storing large amounts of information, managing transactions, or the information must survive application and session restarts. Data mining is a concern, and security is an issue.

mohsen_zelzela00
یک شنبه 23 اسفند 1388, 22:12 عصر
اگه براي اينكار اسرار داريد دستورات لينك زير رو رعايت كنيد. من اطلاعات مهم رو تو session نگه نميدارم. شما خود دانيد. :لبخندساده:

Session Hijacking (http://www.barnamenevis.org/forum/showpost.php?p=452114&postcount=18)

من هم نگه نمی دارم چون به نظر من خیلی میتونه خطرناک باشه

Mostafa_Dindar
یک شنبه 23 اسفند 1388, 22:14 عصر
ترجمه هم میکردی :لبخند:

هر كجاش رو كه متوجه نشدي بگو ترجمه كنم

Milad Mohseny
دوشنبه 24 اسفند 1388, 00:03 صبح
Session state
Use when you are storing short-lived information that is specific to an individual session and security is an issue. Do not store large quantities of information in session state. Be aware that a session-state object will be created and maintained for the lifetime of every session in your application. In applications hosting many users, this can occupy significant server resources and affect scalability.
بازم ميگم اگه نكات امنيتي رو در خصوص Session رعايت نكنيد دچار Session Hijacking (http://www.barnamenevis.org/forum/showpost.php?p=452114&postcount=18) ميشيد. اگه اشتباه ميكنم بگيد.

Milad Mohseny
دوشنبه 24 اسفند 1388, 22:16 عصر
http://www.barnamenevis.org/forum/showthread.php?t=29768
پست 2 لينك فوق مطالعه شود.

اوبالیت به بو
دوشنبه 24 اسفند 1388, 22:44 عصر
من بعد از لاگین UserType رو داخل Session میریزم. که منظور از UserType همون Admin و Customer یا User یا ... بنا به تحلیل سیستم هستش.
حالا اگر من این رو داخل Session بریزم چه مشکل امنیتی به وجود میاد؟ شخص حمله کننده چه استفاده ای می تونه ببره؟



Admin = 1
User = 2
if (Session["UserTypes"].Equals("1")) //Admin
{
Redirect From Admin
}
else //Register User
{
Redirect From Normal User Part
}

Behrouz_Rad
دوشنبه 24 اسفند 1388, 23:25 عصر
من بعد از لاگین UserType رو داخل Session میریزم. که منظور از UserType همون Admin و Customer یا User یا ... بنا به تحلیل سیستم هستش.
حالا اگر من این رو داخل Session بریزم چه مشکل امنیتی به وجود میاد؟ شخص حمله کننده چه استفاده ای می تونه ببره؟



Admin = 1
User = 2
if (Session["UserTypes"].Equals("1")) //Admin
{
Redirect From Admin
}
else //Register User
{
Redirect From Normal User Part
}


برادر حمله کننده اگر Session رو به سرقت ببره، با سطح دسترسی مدیر یا کاربر (بسته به Session فرد) از سایت استفاده می کنه.

موفق باشید.

Mostafa_Dindar
دوشنبه 24 اسفند 1388, 23:59 عصر
برادر حمله کننده اگر Session رو به سرقت ببره، با سطح دسترسی مدیر یا کاربر (بسته به Session فرد) از سایت استفاده می کنه.

موفق باشید.

چطور ميتونه سرقت كنه ؟

Milad Mohseny
سه شنبه 25 اسفند 1388, 00:16 صبح
چطور ميتونه سرقت كنه ؟


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 نیز می تونه برای بررسی صحت این مشخصه استفاده بشه.



تا الان 30 بار لينك زير رو Copy/Paste كردم.
http://www.barnamenevis.org/forum/showpost.php?p=452114&postcount=18

Peyman.Gh
سه شنبه 25 اسفند 1388, 00:20 صبح
در هر صورت امنیتش آنچنان هم پایین نیست چون خواندن کوکی تا جایی که من میدونم با XSS بدست میاد.

Milad Mohseny
سه شنبه 25 اسفند 1388, 00:28 صبح
در هر صورت امنیتش آنچنان هم پایین نیست چون خواندن کوکی تا جایی که من میدونم با XSS بدست میاد.
تو پست هاي قبلي هم ذكر شد اگه ميخواهيد استفاده كنيد اصول امنيتي (http://www.barnamenevis.org/forum/showpost.php?p=452114&postcount=18) رو رعايت كنيد. و البته كسي هم نگفت كلاً session رو بزاريد كنار اخه، جيزه.
البته خود دانيد براي ما كه مشكلي پيش نمياد مياد؟

Peyman.Gh
سه شنبه 25 اسفند 1388, 00:32 صبح
XSS را رعایت کنید بعید بدونم راهی دیگه ای مونده باشه !

h.alizadeh
سه شنبه 25 اسفند 1388, 21:28 عصر
سلام،

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

بعد این سیستم authenticationخود asp.netچطوره؟ امنیت لازم و کافی رو داره؟ استفاده از پروفایل چی خطرناکه؟ توی دیتابیس مقدارش ریخته میشه که...
به امنیت این پست2 هستش؟

(http://www.barnamenevis.org/forum/showthread.php?t=29768)http://www.barnamenevis.org/forum/sh...ad.php?t=29768 (http://www.barnamenevis.org/forum/showthread.php?t=29768)
پست 2 لينك فوق مطالعه شود. (http://www.barnamenevis.org/forum/showthread.php?t=29768)

راستی من از سشن معمولا اینجوری استفاده میکنم
Session(HttpContext.Current.Request.UserHostAddres s & "drug") =value
این: HttpContext.Current.Request.UserHostAddress که من قبل از نام سشن ام میزارم خوبه؟ امنیت رو بیشتر میکنه؟(من اینو همینجوری گذاشتم چون وقتی بدون این بزارم وقتی مثلا چندتا کاربر همزمان باهم به سایت وصل میشند سایت اررور میده! (;)

Behrouz_Rad
سه شنبه 25 اسفند 1388, 23:12 عصر
h.alizadeh@
تعارف نکن! چند تا سوال دیگه هم میپرسیدی ;)



این کوکی رو از کجا پیداکنم؟ روی سیستم خودم میخوام ببینمش، مسیرش کجاست؟

در فایرفاکس مسیر ذیل رو طی کن:


Tools>Options>Privacy>use custom settings for history>Show Cookies


اگه در سشن فقط نام کاربر باشه چیزی عایده کسی که کوکی رو دزدیده نمیشه.یعنی چی؟ یعنی اگه این کوکی روکه فقط حاوی نام کاربری هست رو بدزدند نمیتونند بعنوان این کاربر وارد سایت بشند؟!

در لینک پست 14 که برادرمون از من نقل قول کرده، نوشتم که:


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



من از سشن معمولا اینجوری استفاده میکنم
Session(HttpContext.Current.Request.UserHostAddres s & "drug") =value
این:HttpContext.Current.Request.UserHostAddress که من قبل از نام سشن ام میزارم خوبه؟ امنیت رو بیشتر میکنه؟(من اینو همینجوری گذاشتم چون وقتی بدون این بزارم وقتی مثلا چندتا کاربر همزمان باهم به سایت وصل میشند سایت اررور میده!

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


Session["googooli"] = "magooli";


موفق باشید.

m.hamidreza
سه شنبه 25 اسفند 1388, 23:19 عصر
برادر حمله کننده اگر Session رو به سرقت ببره، با سطح دسترسی مدیر یا کاربر (بسته به Session فرد) از سایت استفاده می کنه.

موفق باشید.

آقا مساَلتُن!
من فکر میکنم روش برادر "جون" اینه که بعد از اینکه کاربر Authenticate شد Roleشو از db میخونه و میریزه تو اون Session. در این حالت کسی که این کوکی رو داره بسته به شیوه ی کدنویسی فقط Authorize میشه ولی Authenticate که نمیشه تا اون یکی کوکی رو نداشته باشه. در این صورت سرقت این کوکی فقط بدرد دلخوشی فرد سارق میخوره. البته اینجا در حاشیه موضوع یه بحث مهمی مطرح میشه و اون اینه که کسی تونسته اون یکی کوکی رو پیدا کنه خوب حتما این یکی کوکی رو هم میتونه پیدا کنه که دیگه اینش به ما ربطی نداره!:چشمک:
پ.ن: بسیار ارادت خالصانه بنده رو پذیرا باشین.مهندس اینا رو وِل کن عیدی چی میدی؟

@obalitjoOon:
برادر شما بجای این روش میتونی با استفاده از roleManager یه Provider بنویسی و مدیریت role هاتو با بصورت سفارشی انجام بدی. در واقع Role Management خود NET. رو دستی پیاده سازی کنی. برادر کرامتی این روش رو در یه پستی توضیح داده بگرد می یابیش.
موفق باشید.

Behrouz_Rad
سه شنبه 25 اسفند 1388, 23:30 عصر
من فکر میکنم روش برادر "جون" اینه که بعد از اینکه کاربر Authenticate شد Roleشو از db میخونه و میریزه تو اون Session. در این حالت کسی که این کوکی رو داره فقط Authorize میشه ولی Authenticate که نمیشه تا اون یکی کوکی رو نداشته باشه.

برادر تو بگو اصلاً چجوری تصدیق هویت رو پیاده سازی می کنی تا من بگم امنیتت چقدره.

m.hamidreza
چهارشنبه 26 اسفند 1388, 00:06 صبح
برادر تو بگو اصلاً چجوری تصدیق هویت رو پیاده سازی می کنی تا من بگم امنیتت چقدره.

میخوای عیدی ندی ببین چه سوالا می پرسی نصفه شبی :لبخندساده:
من با Forms Authentication تصدیق هویت میکنم. جدول Role هم در db دارم که نقش یوزرها رو توش دارم. برای هر Role یه پوشه دارم که مجوز دسترسی هاشو تو وب کانفیگ تعریف میکنم.
بازیابی Roleهای کاربران رو هم با همون کلاس Role Provider انجام میدم از db میخونم تو متد GetRolesForUser(string username) و در سطح برنامه Role رو دارم.

<roleManager enabled="true" defaultProvider="MyRoleProvider">
<providers>
<clear/>
<add name="MyRoleProvider" type="HM.RolesProvider.MyRoleProvider"/>
</providers>
</roleManager>

h.alizadeh
چهارشنبه 26 اسفند 1388, 00:27 صبح
تشکر از جناب راد،

من از ie7استفاده میکنم رفتم اینجا برای مشاهده کوکی ه:
C:\Documents and Settings\motakhasesan\Local Settings\Temporary Internet Files

نمیدونم چیزی ندیدم!
مثلاً این سایته منه:http://localhost:4860/sessions/Default2.aspx
و یک سشن الان هستش که فعال شده اینجوریه:
Session("fname") = "homa"

خب من الان این فایل کوکی رو چطوری پیدا کنمش؟ اسمش دقیقا چیه؟ همه رو چک کردم چیزی پیدا نکردم!



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

خب الان میشه مثالی بزنید خب ! روی مثلا اون حالتی که من گفتم...


نیازی به IP کاربر نیست. چه خطایی می گیری؟
یادم نیست ولی خب اولین باری که سایتمو رو نت گذاشتم با یک نفر دیگه می رفتیم باهم وصل میشدیم از دوتاکامپیوتر مختلف همزمان بعد گاهی پیش می اومد خطا میداد...بعد یکی از همین برنامه نویس خبره های سایت گفت همیشه سشن رواینجوری استفاده کن بخاطر همزمانی هست خطاهه!

Behrouz_Rad
چهارشنبه 26 اسفند 1388, 11:01 صبح
من با Forms Authentication تصدیق هویت میکنم. جدول Role هم در db دارم که نقش یوزرها رو توش دارم. برای هر Role یه پوشه دارم که مجوز دسترسی هاشو تو وب کانفیگ تعریف میکنم.
بازیابی Roleهای کاربران رو هم با همون کلاس Role Provider انجام میدم از db میخونم تو متد GetRolesForUser(string username) و در سطح برنامه Role رو دارم.

وقتی که کوکی تصدیق هویت که به شکل معمول ایجاد شده دزدیده بشه، ASP.NET نمی تونه تشخیص بده که این کوکی مثلاً از سیستم اصلی اومده یا از سیستم فرد مهاجم. در هر دو حالت درخواست رو می پذیره.


من از ie7استفاده میکنم رفتم اینجا برای مشاهده کوکی ه:
C:\Documents and Settings\motakhasesan\Local Settings\Temporary Internet Files

نمیدونم چیزی ندیدم!
مثلاً این سایته منه:http://localhost:4860/sessions/Default2.aspx
و یک سشن الان هستش که فعال شده اینجوریه:
Session("fname") = "homa"

خب من الان این فایل کوکی رو چطوری پیدا کنمش؟ اسمش دقیقا چیه؟ همه رو چک کردم چیزی پیدا نکردم!

لجبازی نکن. از Firefox استفاده کن.


الان میشه مثالی بزنید خب ! روی مثلا اون حالتی که من گفتم...

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


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

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

موفق باشید.

h.alizadeh
پنج شنبه 27 اسفند 1388, 10:23 صبح
سلام،
خیلی ممنونم آقای راد
موفق به مشاهده این کوکی شدم (;
البته بازش که نمیکنه ولی در قسمتcontextمحتواشو که فقط sessionIDهستش رو نمایش میده فقط همینه محتواش نه؟
ولی جالبیش می دونی چیه؟
اینه که من هر سایتی که خودم میسازم روی کامپیوترم و تویffاجرا میکنم همین یه دونه سشن رو داره ولی اگه توی ieاجراشون کنم توی ffمییام از همون طریق کوکی هامو ببینم ،می بینم نه این سشن نمایش داده نمیشه!


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

وقتی که کوکی تصدیق هویت که به شکل معمول ایجاد شده دزدیده بشه، ASP.NET نمی تونه تشخیص بده که این کوکی مثلاً از سیستم اصلی اومده یا از سیستم فرد مهاجم. در هر دو حالت درخواست رو می پذیره.

پس سیستم membershipویژوال استادیو هم امن نیست دراین زمینه، آره؟

من خودم از Session استفاده نمی کنم ولی شرکت یکی رو اورده که همون روز اولی می خوات رئیس شرکت بشه میگه باید Role کاربرها رو در Session ذخیره کنیم هر چی بهش گفتم بابا خطرناکه نکن این کارو می گه حرف فقط حرف خودمه
پس با این حساب شما میگی roleهات چطوری باشه؟! میخوای بگی همش لوگین کنه جاهای حساسو ؟

میگم دزدیده شدن sessionبه سرور ربط داره فقط؟ یه برنامه نویس چکار میتونه بکنه؟
(منظورم دزدیده شدن کوکی سشن هست نه حدس زدن sessionId)


خیلی ممنون
(پ.ن : مهندس عیدی ما محفوظه؟:p)

Peyman.Gh
شنبه 29 اسفند 1388, 02:52 صبح
در زمان ایجاد یک Session و اجرای آن شما آن را کجا مشاهده کردید ؟! بگید ما هم بریم ببینیمش D:
نکته دیگر اینکه که ID سشن همون Name در هنگام اضافه کردنه ؟! خوب پس مقدارش چی میشه ؟!
(Session.Add(String name,Object Value

بازم من درک نمیکنم چطور سشن را میشه دزدید اگر XSS ای وجود نداشته باشد کسی به کوکی ها هم دسترسی ندارد :متفکر:

h.alizadeh
شنبه 29 اسفند 1388, 03:12 صبح
در زمان ایجاد یک Session و اجرای آن شما آن را کجا مشاهده کردید ؟! بگید ما هم بریم ببینیمش D:
نکته دیگر اینکه که ID سشن همون Name در هنگام اضافه کردنه ؟! خوب پس مقدارش چی میشه ؟!

1.همونطور که آقای راد گفتند:در فایرفاکس مسیر ذیل
Tools>Options>Privacy>Show Cookies
2.نچ، اینجوری که من چک کردم در لوکال هاست کلا یک کوکی سشن ایجاد میشه برای کل همه ی سشن های پروژتون ومقدار سشن آیدیش هم یک رشته ی بزرگه یونیکده و هربار که سیستمتو ریستارت کنی یه مقداره...

Peyman.Gh
شنبه 29 اسفند 1388, 03:19 صبح
خوب بعد اینکه چیزی معلوم نیست که محتوای سشن چی بوده :متفکر:

Behrouz_Rad
شنبه 29 اسفند 1388, 03:39 صبح
خوب بعد اینکه چیزی معلوم نیست که محتوای سشن چی بوده :متفکر:

واسه تو معلوم نیست! واسه ASP.NET معلومه!

Peyman.Gh
شنبه 29 اسفند 1388, 03:42 صبح
زمانی که ما Session را اضافه میکنیم به آن مقدار میدهیم آیا امکان دسترسی به این مقدار هست ؟!

تا اینجا من نتیجه گرفتم که Session دارای امنیت بالایی میباشد.

h.alizadeh
یک شنبه 01 فروردین 1389, 00:28 صبح
زمانی که ما Session را اضافه میکنیم به آن مقدار میدهیم آیا امکان دسترسی به این مقدار هست ؟!

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



تا اینجا من نتیجه گرفتم که Session دارای امنیت بالایی میباشد.
اتفاقاً من نتیجه گرفتم در استفاده از سشن باید بیشتر دقت عمل کرد، چون مستعد دزدیده شدن هست...

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



راستی کسی در مورد این :

میگم دزدیده شدن sessionبه سرور ربط داره فقط؟ یه برنامه نویس چکار میتونه بکنه؟
(منظورم دزدیده شدن کوکی سشن هست نه حدس زدن sessionId)
اطلاعی ندره؟!

Peyman.Gh
یک شنبه 01 فروردین 1389, 00:41 صبح
کوکی ها به غیر از XSS به چه نحوی دزدیده میشند ؟!

mohsen_zelzela00
یک شنبه 01 فروردین 1389, 01:06 صبح
اتفاقاً من نتیجه گرفتم در استفاده از سشن باید بیشتر دقت عمل کرد، چون مستعد دزدیده شدن هست...




!
درسته دوست عزیز من در پروژه های که دارم تا اونجایی که می تونم اصلاً از session استفاده نمی کنم چون در یک پروژه استفاده کردم و خیلی برام بازی دراورد و خیلی ازیتم کرد

چرا به جای session از چیزهای دیگه مثل cookie استفاده نمی کنید؟؟؟
مگه چی می خواهید در session ذخیره کنید ؟؟؟ با توجه به نکاتی که استاد راد فرمودند که نباید Role کاربر را در session ذخیره کنیم .

h.alizadeh
یک شنبه 01 فروردین 1389, 14:34 عصر
سلام، ممنون آقا محسن،


الان چیزه خاصی مدنظرم نیست ولی قبلاً پیش اومده بود از سشن برای کارای باامنیت استفاده کنم...




درضمن فکر نمیکنم کوکی امنیت بالاتری نسبت به سشن داشته باشه.


خیلی برام بازی دراورد و خیلی ازیتم کرد
میشه بگی چکار کردی؟

Peyman.Gh
یک شنبه 01 فروردین 1389, 14:36 عصر
بابا اونجوری هم که فکر میکنید نیست هر دو دارای امنیت هستند !

mohsen_zelzela00
یک شنبه 01 فروردین 1389, 15:31 عصر
سلام، ممنون آقا محسن،


الان چیزه خاصی مدنظرم نیست ولی قبلاً پیش اومده بود از سشن برای کارای باامنیت استفاده کنم...




درضمن فکر نمیکنم کوکی امنیت بالاتری نسبت به سشن داشته باشه.


میشه بگی چکار کردی؟

دوست عزیز شما باید با توجه به سایتی که دارید طراحی می کنید یک روش انتقال مقادیر بین صفحات را انتخاب کنید ولی الان خیلی رسم شده که هر کاری بخوان بکنن مستقیم میرن سمت session.
یک مثال می زنم
یک جدول در database برنامه که داریم روش کار می کنیم حاوی 29 فیلد است و مسئول شرکتی که داریم این سایت رو براش طراحی می کنیم می خوات کاربر همان لحظه که کاربر عمل Insert یا Update و... رو انجام داد اطلاعات رو در grid که پایین صفحه هست مشاهده کنه و نمایش این همه فیلد در یک grid واقعاً مشکله(از نظر فضا) من پیشنهاد دادم که ما 5 یا 6 فیلد اساسی رو به کاربر نشون بدیم و یک دکمه به grid اضافه کنیم به عنوان جزئیات که کاربر وقتی بر روی آن دکمه کلیک کرد یک پنجره برای آن باز بشه و جزئیات بشتر اون رکورد رو به کاربر نشون بده . یکی از برنامه نویسان گروه تا من این حرف رو زدم رفت اینو با Session پیاده کرد در حالی که بهترین گزینه برای این کار استفاده از QueryString است (مثلاً مثل همین سایت ).چون ما فقط داریم Id اون رکورد رو به صفحه نمایش می فرستیم و اون مقداری که داخل QueryString هست رو قبل از فرستادن به دستور sql به int تبدیل می کنیم. ولی خوب کو گوش شنوا.....

h.alizadeh
یک شنبه 01 فروردین 1389, 16:09 عصر
آهان،
خب ایراد خاصی که بهش زیاد وارد نشده حالا!

من اگه توی همین حالت شما باشم ونوع فیلدآیدیم از نوع uniqueidentifier باشه یا مایل نباشم که در نوار ادرس مقدار ایدی دیده بشه از سشن استفاده میکنم ، کار اشتباهی ه؟

mohsen_zelzela00
یک شنبه 01 فروردین 1389, 16:26 عصر
آهان،
خب ایراد خاصی که بهش زیاد وارد نشده حالا!

من اگه توی همین حالت شما باشم ونوع فیلدآیدیم از نوع uniqueidentifier باشه یا مایل نباشم که در نوار ادرس مقدار ایدی دیده بشه از سشن استفاده میکنم ، کار اشتباهی ه؟

آخه مقدار session در server ذخیره میشه و اگه سایتی که طراحی می کنید دارای بازدید کننده زیاد باشه و فقط در این page به ازای هر بازدید کننده یک مقدار در server ذخیره بشه خب به نظر من کار درستی نیست

حالا شما چرا نمی خواهید که در Addressbar نشون داده بشه مگه مشکلی به وجود می یات ؟؟؟؟ در ضمن شما فقط می خواهید یه سری اطلاعات رو نمایش بدید و هیچ حمله شما رو تهدید نمی کند شاید کاربر یک مقداری وارد کنه که در جدول شما موجود نباشه و شما خیلی راحت می تونید یه پیغام بهش نشون بدید که این id ذخیره نشده است.

اینو در نظر بگیر که خود سایت برنامه نویس به جای استفاده از QueryString از Session استفاده می کرد تصورش خیلی .....

h.alizadeh
یک شنبه 01 فروردین 1389, 16:37 عصر
حالا شاید موردی باشه که تمایلی به ظاهر شدنش در نوار ادرس نداشته باشم ، آیا بازم استفاده از سشن توصیه میشه یا خیر؟

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