سوال: آیا این روش برای چک کردن پر بودن سسشن ها امنیت داره؟ [بایگانی]

idocsidocs

جمعه 17 تیر 1390, 18:38 عصر

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

با توجه به این مطلب، لطفا بگید که این روش برای چک کردن سسشن ها امنیت داره یا نه؟

require_once('./includes/ses.php');
$session=new MySessionHandler($host,$user,$pass,$db);
session_start();
if(!empty($_SESSION[userid]))
{

Mr.Moghadam

جمعه 17 تیر 1390, 20:34 عصر

برای لاگین فکر میکنم بهتره که هر یوزر یه نقش داشته باشه
مثلا یوزر a نقش ادمین رو داره که هم یوزر و هم نقش توی سشن قرار میگیره و موقع لاگین به منوی ادمین باید چک بشه که آیا یوزر وارد شده نقشش ادمین هست یانه

if(isset($_SESSION['userid']) && $_SESSION['userid'] ['role'] == 'admin')
{
//do somthing
}

idocsidocs

جمعه 17 تیر 1390, 20:55 عصر

برای لاگین فکر میکنم بهتره که هر یوزر یه نقش داشته باشه
مثلا یوزر a نقش ادمین رو داره که هم یوزر و هم نقش توی سشن قرار میگیره و موقع لاگین به منوی ادمین باید چک بشه که آیا یوزر وارد شده نقشش ادمین هست یانه

if(isset($_SESSION['userid']) && $_SESSION['userid'] ['role'] == 'admin')
{
//do somthing
}

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

MMSHFE

شنبه 18 تیر 1390, 07:33 صبح

با سلام، يك سؤال داشتم. از كلاس SSSH كه من معرفي كردم استفاده ميكنيد؟ به نظرم اين روش مناسب باشه:

if(isset($_SESSION['userid'] && $_SESSION['userid'] != '')
}
//...
}

idocsidocs

شنبه 18 تیر 1390, 11:27 صبح

با سلام، يك سؤال داشتم. از كلاس SSSH كه من معرفي كردم استفاده ميكنيد؟ به نظرم اين روش مناسب باشه:

if(isset($_SESSION['userid'] && $_SESSION['userid'] != '')
}
//...
}

توی فروم سرچ کردم و کلاس شما رو پیدا کردم. البته چندتا تغییر توش دادم. عمده تغییری که توش ایجاد کردم استفاده از mysqli:: بجای mysql هست.

لطفا بگید استفاده از

if(isset($_SESSION['userid'] && $_SESSION['userid'] != '')
چه مزیتی نسبت به استفاده از

if(!empty($_SESSION[userid]))
داره؟
در کل ذخیره کردن سسشن ها توی دیتابیس به همراه چک کردن پر یا خالی بودن سسشن امنیت سسشن ها رو تضمین می کنه؟

MMSHFE

شنبه 18 تیر 1390, 11:43 صبح

با سلام، سؤال اول:
درمورد استفاده از empty بايد به اين نكته دقت كنيد كه موارد زير، خالي درنظر گرفته ميشن:
"" يك رشته خالي
0 عدد صحيح صفر
0.0 عدد اعشاري صفر
"0" رشته حاوي عدد صفر
NULL
FALSE
array() يك آرايه خالي
;var $var متغير تعريف شده بدون مقدار
درمورد سؤال دوم هم بايد بگم كه ذخيره كردن توي DB خودبخود جلوي يكسري حملات ازقبيل Session Hijack (سرقت فايل سشن در سرورهاي اشتراكي) رو ميگيره. درنتيجه درصورت تنظيمات ضعيف سرور درمورد امنيت فايلهاي پوشه tmp ميتونيد لااقل از اين نوع حملات در امان باشيد. چك كردن پر يا خالي بودن سشن هم بستگي به نيازتون داره. بعضي جاها علاوه بر اينكه چك ميكنن تنظيم شده باشه، مشخص ميكنن بايد حتماً مقدار خاصي هم داشته باشه. مثلاً اگه سشن user مقدار داشت ولي مقدارش برابر با manager نبود، صفحه مديريت باز نشه. در اين حالت اگه كاربر معمولي وارد بشه و سشن user براش با مقدار normal ايجاد بشه، ميتونه به بخشهاي كاربري خودش دسترسي داشته باشه ولي به صفحه مديريت نه! در اين حالت اگه فقط چك كنيم كه سشن user وجود داره و خالي نيست، اونوقت كاربران معمولي هم به بخش مديريت دسترسي خواهند داشت.
پاورقي: راستي، اگه امكان داره، كلاس SSSH كه تغيير دادين و با mysqli نوشتين رو بگذارين تا استفاده كنيم.
موفق باشيد.

idocsidocs

شنبه 18 تیر 1390, 13:53 عصر

با سلام، سؤال اول:
درمورد استفاده از empty بايد به اين نكته دقت كنيد كه موارد زير، خالي درنظر گرفته ميشن:
"" يك رشته خالي
0 عدد صحيح صفر
0.0 عدد اعشاري صفر
"0" رشته حاوي عدد صفر
NULL
FALSE
array() يك آرايه خالي
;var $var متغير تعريف شده بدون مقدار
درمورد سؤال دوم هم بايد بگم كه ذخيره كردن توي DB خودبخود جلوي يكسري حملات ازقبيل Session Hijack (سرقت فايل سشن در سرورهاي اشتراكي) رو ميگيره. درنتيجه درصورت تنظيمات ضعيف سرور درمورد امنيت فايلهاي پوشه tmp ميتونيد لااقل از اين نوع حملات در امان باشيد. چك كردن پر يا خالي بودن سشن هم بستگي به نيازتون داره. بعضي جاها علاوه بر اينكه چك ميكنن تنظيم شده باشه، مشخص ميكنن بايد حتماً مقدار خاصي هم داشته باشه. مثلاً اگه سشن user مقدار داشت ولي مقدارش برابر با manager نبود، صفحه مديريت باز نشه. در اين حالت اگه كاربر معمولي وارد بشه و سشن user براش با مقدار normal ايجاد بشه، ميتونه به بخشهاي كاربري خودش دسترسي داشته باشه ولي به صفحه مديريت نه! در اين حالت اگه فقط چك كنيم كه سشن user وجود داره و خالي نيست، اونوقت كاربران معمولي هم به بخش مديريت دسترسي خواهند داشت.
پاورقي: راستي، اگه امكان داره، كلاس SSSH كه تغيير دادين و با mysqli نوشتين رو بگذارين تا استفاده كنيم.
موفق باشيد.
من کاربرهای عادی و مدیران رو از طریق دو فرم جدا گانه لاگین می کنم و از ایندکسهای متفاوتی برای سسشن هاشون استفاده می کنم. به این دلیل دیگه قاطی نمی شن و چک کردن پریا خالی بودن سسشن ها کافی هست.

در مورد تابع empty هم درست می گید، آیا تابع isset چنین مشکلاتی نداره و اگر از روش شما استفاده کنم، با چنین مشکلاتی مواجه نمی شم؟

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

Keramatifar

شنبه 18 تیر 1390, 15:40 عصر

درمورد سؤال دوم هم بايد بگم كه ذخيره كردن توي DB خودبخود جلوي يكسري حملات ازقبيل Session Hijack (سرقت فايل سشن در سرورهاي اشتراكي) رو ميگيره. درنتيجه درصورت تنظيمات ضعيف سرور درمورد امنيت فايلهاي پوشه tmp ميتونيد لااقل از اين نوع حملات در امان باشيد. چك كردن پر يا خالي بودن سشن هم بستگي به نيازتون داره.
موفق باشيد.
دوست عزیز
به نظر من برنامه های وب باید از کانکش زدن به دیتابیس تا حد امکان کمتر استفاده کنند تا بازدهی بیشتری داشته باشند.
این از نظر من اصلا منطقی نیست که برای هر Session به دیتابیس وصل بشیم (بنویسیم و بخونیم)، این کار بار قابل ملاحظه ای رو به I/O سایت تحمیل می کنه ...
اگر برای امنیت Session قرار سخت گیری انجام بشه، بهتره اطلاعات موجود در اون رو کد کنیم

idocsidocs

شنبه 18 تیر 1390, 15:55 عصر

دوست عزیز
به نظر من برنامه های وب باید از کانکش زدن به دیتابیس تا حد امکان کمتر استفاده کنند تا بازدهی بیشتری داشته باشند.
این از نظر من اصلا منطقی نیست که برای هر Session به دیتابیس وصل بشیم (بنویسیم و بخونیم)، این کار بار قابل ملاحظه ای رو به I/O سایت تحمیل می کنه ...
اگر برای امنیت Session قرار سخت گیری انجام بشه، بهتره اطلاعات موجود در اون رو کد کنیم
توی کنترل پنل تقریبا برای هرکاری باید کوئری گیری کرد و به همین دلیل ریختن سسشن ها توی دیتابیس بار اضافه ایجاد نمی کنه.

البته اگه بخوایم سسشن ها رو کد کنیم، بلافاصله بحث دیکدرها پیش می یاد که باعث در معرض خطر قرار گرفتن سسشن های کد شده می شه. در این مورد چه نظری دارید؟

Keramatifar

یک شنبه 19 تیر 1390, 01:37 صبح

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

البته اگه بخوایم سسشن ها رو کد کنیم، بلافاصله بحث دیکدرها پیش می یاد که باعث در معرض خطر قرار گرفتن سسشن های کد شده می شه. در این مورد چه نظری دارید؟
اگر شما از کدرها و کریپتورهای آماده استفاده کنید، قطعا دیکدرش پیدا خواهد شد، من همیشه برای هر Web Application ای خودم یک کدر می نویسم و با استفاده از اون داده ها رو کد می کنم، وقتی مکانیزم کدر مختص خودتون باشه و درست طراحی شده باشه، دیکد کردنش به این راحتی ها نیست و احتمالش تقریبا نزدیک به صفر است

MMSHFE

یک شنبه 19 تیر 1390, 08:34 صبح

با سلام، من با اين قسمت از صحبتهاي جناب كرامتي موافقم كه اتصال زياد به DB به سرور فشار مياره ولي در سايتهاي ايراني كه اكثراً (نه همه) روزانه زير 10 هزار بازديدكننده دارن، اين بار اضافه اونقدر نخواهد بود كه بخصوص در سرورهاي اشتراكي، امنيت رو فداي اون كنيم. بعلاوه اين كلاس صرفاً يكي از راههاي تغيير كار Session هست. ميشه براي مثال، طوري اون رو تنظيم كنيم كه توي يك پوشه درون سايت خودمون ذخيره كنه و اون پوشه رو با رمز محافظت كنيم. اينطوري ديگه توي پوشه tmp كه مشترك هست، ذخيره نخواهد شد.
موفق باشيد.

MMSHFE

یک شنبه 19 تیر 1390, 08:37 صبح

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

در مورد تابع empty هم درست می گید، آیا تابع isset چنین مشکلاتی نداره و اگر از روش شما استفاده کنم، با چنین مشکلاتی مواجه نمی شم؟

برای کلاس سسشن هم باشه، توی یه پست جداگانه قرار می دم. البته می شه بگید چرا از blob برای نوع جدولتون استفاده کردید؟
تابع isset چنين مشكلي نداره چون فقط چك ميكنه ببينه بهش مقدار داديم يا نه و به مقدارش كاري نداره.
علت استفاده از blob اينه كه بعضيها (كه من با عرض شرمندگي ميگم حالشون خوب نيست) ميان و يكسري اطلاعات حجيم رو توي Session ميريزن. مثلاً به جاي اينكه توي سبد خريد، كد كالاهاي خريداري شده رو توي سشن بگذارن و موقع نياز، با Query اون كدها رو خونده و نمايش بدن، كلاً ركوردهاي مربوط به كالاهاي انتخاب شده رو از جدول ميخونن و توي سشن ميگذارن. بعضيها از اين هم بدتر عمل ميكنن و براي مثال، محتويات باينري مثل عكس و... رو توي سشن ميگذارن. درسته كه اين كار استاندارد نيست ولي بايد اجازه اون رو به اين افراد بديم. نبايد اين كلاس، محدودتر از سيستم مديريت سشن خود PHP عمل كنه.
موفق باشيد.

Keramatifar

یک شنبه 19 تیر 1390, 15:15 عصر

با سلام، من با اين قسمت از صحبتهاي جناب كرامتي موافقم كه اتصال زياد به DB به سرور فشار مياره ولي در سايتهاي ايراني كه اكثراً (نه همه) روزانه زير 10 هزار بازديدكننده دارن، اين بار اضافه اونقدر نخواهد بود كه بخصوص در سرورهاي اشتراكي، امنيت رو فداي اون كنيم. بعلاوه اين كلاس صرفاً يكي از راههاي تغيير كار Session هست. ميشه براي مثال، طوري اون رو تنظيم كنيم كه توي يك پوشه درون سايت خودمون ذخيره كنه و اون پوشه رو با رمز محافظت كنيم. اينطوري ديگه توي پوشه tmp كه مشترك هست، ذخيره نخواهد شد.
موفق باشيد.
همچنان با ذخیره Session در دیتابیس مخالفم، تعداد بازدید کننده ها مهم است، اما سرعت دسترسی کاربر به داده ها است که اهمیت بیشتری دارد
استفاده از فایل قابل تحمل تره، اما بازهم بهترین حالت نوشتن یک کدینگ برای کد کردن محتوای Session است

MMSHFE

دوشنبه 20 تیر 1390, 07:51 صبح

خوب سرعت دسترسي با استفاده از DB كه بيشتر از فايل هست. مشكل ذخيره سشن در ديتابيس، صرفاً بار بيشتر روي سرور هست كه توي سايتهاي ايراني آنچنان زياد نخواهد بود (بعلت تعداد كم بازديدهاي همزمان) وگرنه ازنظر سرعت، اين روش نسبت به ذخيره سشن توي فايل سرعت بيشتري داره.

Keramatifar

دوشنبه 20 تیر 1390, 17:28 عصر

خوب سرعت دسترسي با استفاده از DB كه بيشتر از فايل هست. مشكل ذخيره سشن در ديتابيس، صرفاً بار بيشتر روي سرور هست كه توي سايتهاي ايراني آنچنان زياد نخواهد بود (بعلت تعداد كم بازديدهاي همزمان) وگرنه ازنظر سرعت، اين روش نسبت به ذخيره سشن توي فايل سرعت بيشتري داره.
بنده عرض کردم کار با فایل صرفا "قابل تحمل تر است" نه اینکه بهترین راه است، اما از ذخیره در دیتابیس بهتر است.
برای روشن شدن مطلب چند سوال مطرح می کنم که فکر کنم با جواب دادن به این سوالات به نتیجه خوبی برسیم
1- تصور کنید Session در دیتابیس ذخیره می شود، زمانیکه درخواست ها به هر دلیلی زیاد شد کاربر با پیغام Too Many Connections مواجه می شود، آیا هنگام کار با فایل ها هم چنین است؟
2- سرعت Read/Write روی فایل هایی که بصورت فیزیکی روی سرور وجود دارد، با سرعت R/W روی دیتابیس قابل مقایسه است؟
3- ما می توانیم امنیت فایل ها را روی سرور با تنظیماتی بعضا جزئی کاملا به عهده سرورهای قدرتمند لینوکس بگذاریم، آیا امنیت دیتابیس (در حملاتی مانند Query String Attack, SQL Injection, ...) را نیز می توان به عهده وب سرور گذاشت؟
موارد بسیار دیگری هم هست، حتی برای ذخیره در فایل هم موارد بسیاری است، لطفا شما توضیح بدهید که چرا از مکانیزم های کدینگ استفاده نمی کنید؟ چرا یک متد کدینگ ساده برای کد کردن اطلاعات موجود در Session نمی نویسید؟ آیا از نظر منطقی از هر دو روش فایل و دیتابیس سریعتر و امن تر نیست؟

idocsidocs

دوشنبه 20 تیر 1390, 22:23 عصر

با سلام، من با اين قسمت از صحبتهاي جناب كرامتي موافقم كه اتصال زياد به DB به سرور فشار مياره ولي در سايتهاي ايراني كه اكثراً (نه همه) روزانه زير 10 هزار بازديدكننده دارن، اين بار اضافه اونقدر نخواهد بود كه بخصوص در سرورهاي اشتراكي، امنيت رو فداي اون كنيم. بعلاوه اين كلاس صرفاً يكي از راههاي تغيير كار Session هست. ميشه براي مثال، طوري اون رو تنظيم كنيم كه توي يك پوشه درون سايت خودمون ذخيره كنه و اون پوشه رو با رمز محافظت كنيم. اينطوري ديگه توي پوشه tmp كه مشترك هست، ذخيره نخواهد شد.
موفق باشيد.

طوري اون رو تنظيم كنيم كه توي يك پوشه درون سايت خودمون ذخيره كنه و اون پوشه رو با رمز محافظت كنيم. اينطوري ديگه توي پوشه tmp كه مشترك هست، ذخيره نخواهد شد.
منظورتون اینه که اگه مسیر پوشه tmp رو تغییر بدم، امنیت سسشن ها هم تضمین می شه و دیگه نیازی به دیتابیس نیست؟
سوالی که پیش می یاد اینه که این پوشه می تونه امنیت داشته باشه؟

MMSHFE

سه شنبه 21 تیر 1390, 17:10 عصر

همونطور که جناب کرامتی گفتن، کار با فایلها در زمانی که درخواستها زیاد باشه، بهینه تر از دیتابیس عمل میکنه. درنتیجه میشه با ترکیب روشی که من گفتم (تغییر روش ذخیره سازی سشن، حداقل ازنظر محل ذخیره سازی به نحوی که از پوشه مشترک استفاده نشه) و روش آقای کرامتی (نوشتن یک سیستم کدگذاری شخصی برای ذخیره کردن اطلاعات سشن و رمزگشایی در هنگام خواندن) میشه یک روش بهینه تولید کرد و نهایتاً پوشه مربوط به سشن رو توسط کنترلهای سطح دسترسی و... امن کنیم. درنتیجه، اگه پوشه مربوطه داخل سایت خودتون باشه، تنها راه سرقت سشن، بی انصافی خود هاست خواهد بود که فایلها رو در اختیار فرد دیگری قرار بده (که بعید میدونم هاستها بخوان اینطور با اعتبارشون بازی کنند) یا اینکه هاست بد تنظیم شده باشه (که در این صورت هم اعتبارش زیر سؤال میره). تازه با تمام این اوصاف، اگه اطلاعات رو بصورت کدشده توی سشن قرار بدین، به هر شکلی هم که دسترسی پیدا کنند، اطلاعات به دردشون نمیخوره چون فقط خودتون میدونید چطور اونها رو از حالت کدشده خارج کنید. تجربه هم بهم نشون داده که بهتره برای اسکریپتهایی که خودتون مینویسید ارزش قائل بشین و روی هاستهای رایگان اونها رو تست و یا نصب نکنید چون معمولاً اینجور هاستها مشکلات امنیتی و تنظیمات اشتباه زیاد دارن و کدتون راحتتر لو میره.
موفق باشید.

MMSHFE

سه شنبه 21 تیر 1390, 17:12 عصر

راستی جناب کرامتی، اگه سشن رو توی دیتابیس ذخیره کنیم و نوع موتور جداول رو Memory انتخاب کنیم، به نظرتون سرعت بیشتر نخواهد شد؟ در این مورد خوشحال میشم نظرتون رو بدونم.

Keramatifar

سه شنبه 21 تیر 1390, 22:14 عصر

راستی جناب کرامتی، اگه سشن رو توی دیتابیس ذخیره کنیم و نوع موتور جداول رو Memory انتخاب کنیم، به نظرتون سرعت بیشتر نخواهد شد؟ در این مورد خوشحال میشم نظرتون رو بدونم.
Memory Storage Engine برای مواردی می تونه کاربرد داشته باشه، اما اگر بخواهیم با این مکانیزم کار کنیم می توانیم بجای MSE از Mysql Cluster استفاده کنیم، Cluster علاوه بر نداشتن مشکلاتی از قبیل
NonStable بودن MSE
Overhead شدن هنگام پروسه Update
و ...
امکانات بیشتری ارائه می دهد که برخی از آنها عبارتند از:
Row-level locking و multiple-thread برای کانکشن های ضعیف به کلاینت
مقیاس پذیری برای دستورات ترکیبی حاوی write
عملیات disk-backed برای حفظ پایداری داده ها
پشتیبانی از variable-length data type ها (شامل BLOB و TEXT) که در Memory ساپورت نمی شود.