PDA

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



redhat2
چهارشنبه 26 تیر 1392, 08:59 صبح
من 2 حالت برای login کردن در نظر گرفتم :

حالت اول :

بعد از این که login کامل انجام شد ، من 3 تا Session درست می کنم ، اولی username را در خودش نگه می داره ، دومی user_id و سومی یک hash هست که این هش توی ه دتابیس ذخیره میشه ، بعد وجود Session های کاربر چک میشه ، و Session سوم هم با دتیابیس تطبیق داده میشه. برای rememberme هم کوکی با همین حالت درست می کنیم یعنی یه کوکی به نام ایمیل درست می کنیم ، یه کوکی هش درتس می کنیم که در دیتابیس هم ذخیره میشه .

حالت دوم :
قسمت Session مثل بالا است ، ولی تو قسمت Cookie ، میام یه Cookie از user_agent یا ip درست می کنیم ، و کوکی Hash را هم در دیتابیس ذخیره نمی کنیم .

به نظر شما از لحاظ امنیت و سرعت کدوم بهتر هستش ؟ در ضمن من برای حالت زمان cookie از setcookie استفاده می کنم ، این روش مطمنی هست ؟

soltoon
چهارشنبه 26 تیر 1392, 10:07 صبح
سلام
من جواب سوالتون رو نمیدونم ولی یه سوال دارم ازتون
میشه این خط رو بیشتر توضیح بدید؟
"من 3 تا Session درست می کنم ، اولی username را در خودش نگه می داره ، دومی user_id و سومی یک hash هست که این هش توی ه دتابیس ذخیره میشه ، بعد وجود Session های کاربر چک میشه ، و Session سوم هم با دتیابیس تطبیق داده میشه. "
چرا سه تا سشن مگه با یکی نمیشه؟
و یه توضیح مختصر درباره این که این سه تا سشن چه کار میکنن بدین ممنون میشم
تشکر

مهرداد سیف زاده
پنج شنبه 27 تیر 1392, 00:31 صبح
بعضی اوقات نوشتن کدهای زیاد برای برقراری امنیت، خودش باعث ضعف امنیتی و کند شدن سایت هست.
در سشن شما بیشتر باید ترس دزدین سشن رو داشته باشید و نیازی به این همه ذخیره و بازیابی پشت سر هم نیست.
و اما cookie دیگه دم دست کاربر هست یعنی همه به راحتی به محتواش دسترسی دارن. برای برقراری امنیت در اون در زمانی که کاربر لاگین میکنه یک رشته هش ساخته میشه و همزمان در دیتابیس و کوکی کاربر ذخیره میشه. بعد از اون در تمام صفحات مقدار هش شده کوکی کاربر با دیتابیس مقایسه میشه. دقت کنید منظورم از هش md5 یا sha1 نیست بلکه توابع و ماژول‌های قوی تولید هش به کمک علم cryptography

redhat2
پنج شنبه 27 تیر 1392, 12:32 عصر
خوب اگه ما بیام 2 تا سشن داشته باشیم که یکیش Crypt هست و توی دیتابیس insert کنمیش و بعد از تابع session_set_cookie_params برای remember me و زمان اون استفاده کنیم ، بهتر نیست ؟

مهرداد سیف زاده
پنج شنبه 27 تیر 1392, 17:12 عصر
برای ذخیره و یادآوری سشن حالا هم که شما میخواید سطح امنیت رو باز هم بالاتر ببرید همون یدونه سشن کافی هست. چون در نهایت قراره برای کاربری که لاگین کرده یک crypt ساخته بشه و در سشن و دیتابیس ذخیره بشه. همچنین فقط بر سشن تکیه نکنید. البته برای قسمت مدیریت سایت بهره گیری از سشن بهتره ولی برای ورود و خروج کاربران بیشتر بر حسب کوکی کار کنید و در صورتی که کاربر از عمد کوکی خودش رو خاموش کرده بود از سشن استفاده بشه. در هر صورت در زمینه امنیت هم راهکار بهتر این هست داده‌های کمتری دست کاربر بدی وقتی قراره که ذخیره یدونه سشن و امکان مانور در آینده بهتر از ذخیره 2 تا سشن هست.

مثلا برای مقابله با دزدیدن سشن(session hijacking) در هربار که اطلاعات از سشن برداشته میشه با اصل اونها مقایسه میشه. مثلا شما ip کاربران رو برای هش کردن استفاده کردید در هربار خواندن اطلاعات سشن و مقایسه با دیتابیس، این سشن ابتدا تست میشه که آیا اطلا ip هست و آیا قبلا این کاربر قبل از هش شدن چنین ip داشته.

redhat2
پنج شنبه 27 تیر 1392, 19:00 عصر
یعنی چی که قبلا اصلا این ip را داشته یا نه ؟ در ضمن اگه که cookie را غیر فعال می کنند چطور بفهمم که غیر فعال شده و بعد بیام از Session اتفاده کنم ، درضمن من خیلی تحقیق کردم ، از لحاظ امنیت می گند که
session_set_Cookie_params خیلی بهتر از setcookie هست ، میشه یکم در این موارد بیشتر توضیح بدین .

مهرداد سیف زاده
پنج شنبه 27 تیر 1392, 22:20 عصر
مثلا کاربر در صفحه login.php که داشت وارد سایت میشد و اطلاعاتش در دیتابیس ذخیره میشد ip اون 192.168.200.5 بوده و حالا یک دقیقه گذشته قاعدتا نباید ip فوری عوض بشه چون با عوض شدن ip کلا سشن تغییر میکنه حالا دزدیدن سشن هکر محتوای سشن کاربر رو با محتوای مورد دلخواه خودش عوض میکنه. در این جا ما یک ناهماهنگی داریم هکر تونسته محتوای سشن رو به 200.100.50.10 تغییر بده در صورتی که ip‌کاربر هنوز 192.168.200.5 همون ip لاگین بوده. پس با هر با تست کردن میتونید محتوای ذخیره شده رو با اصل اونها بسنجیم.

در مورد session_set_cookie_oarams این تابع در هربار فراخوانی خودش میتونه رشته‌ای رو که بر روی کوکی کاربر ذخیره میشه تغییر بده و این کار سبب میشه که هکر تا دست به کار بشه و با داشتن یک رشته کوکی شروع به برداشت محتوا کنه دوباره رشته جدید تولید میشه.
حالا با یه مثال شاید بهتر متوجه بشید قطعه کد زیر رو یه نگاه بندازید:


<?php
session_set_cookie_params(10);
session_start();
$_SESSION['admin'] = 'mehrdad';
echo $_SESSION['admin'];
?>

با اجرای این کد بر روی صفحه نام کاربری ادمین نوشته میشه ولی به کوکی خودتون نگاهی بندازید امکان داره رشته ای که بوسیله سشن در کوکی ذخیره شده بصورت زیر باشه:

t10bs51nivffbgtf8rlfu6vrm3

اون مقدار 10 حدود 20ثانیه بعد اگر از مدت ذخیره این سشن بگذره محتوای قبلی رو همچنان حفظ میکنه ولی رشته جدیدی تولید میکنه که شاید بصورت زیر باشه

jjr6fpkfe599vuklr91i9atgo1

البته تغییر رشته قبلی با رشته جدید به این وابسته هست که اطلاعات جدیدی بخواد توسط همون کاربر بر روی سشن ذخیره بشه و گرنه بر روی همون رشته قبلی میمونه.
در کل زیاد خودتون رو با چگونگی امنیت در سشن درگیر نکنید چون چیزی هست که توسط سرور و مستقیما توسط php در کنترل هست و انقدر روش‌های متنوع هک سایت وجود داره که کمتر هکری وقت خودش رو بر روی هک سشن میزاره

redhat2
جمعه 28 تیر 1392, 21:33 عصر
چجوری طرف هنزو login نکرده ما id اون را برزیم تو سشن و بعد با دیتابیس مطابقت بدیم . ؟

parsboy
جمعه 28 تیر 1392, 21:48 عصر
چجوری طرف هنزو login نکرده ما id اون را برزیم تو سشن و بعد با دیتابیس مطابقت بدیم . ؟
باسلام دوست عزیز دقت کنید دوستمون گفت زمان ثبت نام نه لاگین!!
زمانی که ثبت نام روانجام میدید ID رو بریزید داخل Session .
موفق باشید.

redhat2
شنبه 29 تیر 1392, 13:36 عصر
منم دارم رو یه framework کار می کنم ، این یه کنترلر هم براش ساختم bmui.ir/admin/login اگه میتونی یه نگاهی بنداز ببین امنیتش چطوره ؟ ممنون .

redhat2
شنبه 29 تیر 1392, 14:10 عصر
خیلی هم عالی ولی یک چیزی از من بشنوید من کار شما رو به شدت تحسین میکنم اما اگر به یک فرد پی اچ پی کار بگیر سریع در مقابلتون گارد میگیره مثل خود من که هر کسی میاد میگه آشغاله بدرد نمی خوره و ... حتی اشخاصی که هنوز یک سایت هم آنلاین نکردن یک موردی منو خیلی اذیت میکنه و اینکه ما ایرانی ها همیشه طرفدار محصولات خارجی هستیم و هیچ وقت باور نداریم که بابا ایرانی ها خیلی بهتر هم میتونن کار کنن ولی توقع نکنند که یک فریم ورک از بدو تولد شاهکار کنه - طراحی یک فریم ورک تو فاز های متفاوت صورت میگیره و به مرور و با گذشت زمان امتحان پس میده و کامل میشه اما متاسفم برای کسای که سریع ادعا می کنند دوست عزیز من صد درصد با شما موافقم ادامه بدید لازم است و تخصص کافی دارید بیایید روی یک فریم ورک زوم کنیم و ارتقاعش بدیم

اگه بشه که خیلی خوب میشه . ممنون که وقت گذاشتین . راستش را بخواین ما تا همین 3 یا 4 روز پیش داشتیم امتحان پایان ترم میدادیم ، اگه وقت بشه و بذارن به شدت مایلیم :لبخند: که با باهاتون همکاری کنیم ، به امید روزی که خودمونو باور داشته باشیم ، بازم ممنون . :تشویق:

redhat2
شنبه 29 تیر 1392, 14:13 عصر
مثلا کاربر در صفحه login.php که داشت وارد سایت میشد و اطلاعاتش در دیتابیس ذخیره میشد ip اون 192.168.200.5 بوده و حالا یک دقیقه گذشته قاعدتا نباید ip فوری عوض بشه چون با عوض شدن ip کلا سشن تغییر میکنه حالا دزدیدن سشن هکر محتوای سشن کاربر رو با محتوای مورد دلخواه خودش عوض میکنه. در این جا ما یک ناهماهنگی داریم هکر تونسته محتوای سشن رو به 200.100.50.10 تغییر بده در صورتی که ip‌کاربر هنوز 192.168.200.5 همون ip لاگین بوده. پس با هر با تست کردن میتونید محتوای ذخیره شده رو با اصل اونها بسنجیم.

در مورد session_set_cookie_oarams این تابع در هربار فراخوانی خودش میتونه رشته‌ای رو که بر روی کوکی کاربر ذخیره میشه تغییر بده و این کار سبب میشه که هکر تا دست به کار بشه و با داشتن یک رشته کوکی شروع به برداشت محتوا کنه دوباره رشته جدید تولید میشه.
حالا با یه مثال شاید بهتر متوجه بشید قطعه کد زیر رو یه نگاه بندازید:


<?php
session_set_cookie_params(10);
session_start();
$_SESSION['admin'] = 'mehrdad';
echo $_SESSION['admin'];
?>

با اجرای این کد بر روی صفحه نام کاربری ادمین نوشته میشه ولی به کوکی خودتون نگاهی بندازید امکان داره رشته ای که بوسیله سشن در کوکی ذخیره شده بصورت زیر باشه:

t10bs51nivffbgtf8rlfu6vrm3

اون مقدار 10 حدود 20ثانیه بعد اگر از مدت ذخیره این سشن بگذره محتوای قبلی رو همچنان حفظ میکنه ولی رشته جدیدی تولید میکنه که شاید بصورت زیر باشه

jjr6fpkfe599vuklr91i9atgo1

البته تغییر رشته قبلی با رشته جدید به این وابسته هست که اطلاعات جدیدی بخواد توسط همون کاربر بر روی سشن ذخیره بشه و گرنه بر روی همون رشته قبلی میمونه.
در کل زیاد خودتون رو با چگونگی امنیت در سشن درگیر نکنید چون چیزی هست که توسط سرور و مستقیما توسط php در کنترل هست و انقدر روش‌های متنوع هک سایت وجود داره که کمتر هکری وقت خودش رو بر روی هک سشن میزاره

در مورد این ip که شما گفتین ، من تحقیق کردم میگن روش ip خیلی مطمئن نیست ، نظر شما چیه ؟

engmmrj
شنبه 29 تیر 1392, 16:08 عصر
خیلی هم عالی ولی یک چیزی از من بشنوید من کار شما رو به شدت تحسین میکنم اما اگر به یک فرد پی اچ پی کار بگیر سریع در مقابلتون گارد میگیره مثل خود من که هر کسی میاد میگه آشغاله بدرد نمی خوره و ... حتی اشخاصی که هنوز یک سایت هم آنلاین نکردن یک موردی منو خیلی اذیت میکنه و اینکه ما ایرانی ها همیشه طرفدار محصولات خارجی هستیم و هیچ وقت باور نداریم که بابا ایرانی ها خیلی بهتر هم میتونن کار کنن ولی توقع نکنند که یک فریم ورک از بدو تولد شاهکار کنه - طراحی یک فریم ورک تو فاز های متفاوت صورت میگیره و به مرور و با گذشت زمان امتحان پس میده و کامل میشه اما متاسفم برای کسای که سریع ادعا می کنند دوست عزیز من صد درصد با شما موافقم ادامه بدید لازم است و تخصص کافی دارید بیایید روی یک فریم ورک زوم کنیم و ارتقاعش بدیم
مهم سایت آپو غیر آپ نیست مهم دانش و مهارت طرف است .
وقتی چند نفر پیدا میشن و به شما میگن فریمورکت آشغاله یعنی آشغاله یعنی باید تلاشتو و دقت رو بیشتر کنی تو این کار و باید شما انتقاد پذیر باشی .
در ضمن نمیشه که هر کی از مامانش قهرکرد بیاد یک فریمورک داغون بنویسه بعد بزاره برای دانلود و به همه پیشنهاد بده که این بهترین فریمورک است و دائما بگه که تو انفورماتیک ثبت شده ( اینارو بزار در کوزه آبشو بخور) حداقل برای تمرین و بالا رفتن مهارت خودت میخوای فریمورک بنویسی ؟ دیگه این فریمورک آشغالو نزار برای دانلود و چهار نفر دیگه رو تو دردسر ننداز .
موفق باشید .
گتنا (http://gtna.net)

MMSHFE
یک شنبه 30 تیر 1392, 08:13 صبح
استفاده از کلماتی مثل آشغ... و امثال اون مناسب این مکان علمی نیست. درصورت تکرار، مطابق قوانین با افراد خاطی برخورد خواهد شد. اینکه یک فریمورک ایرانی (هرچند ضعیف در ابتدای امر) ساخته شده، به خودی خود شایسته تحسینه و زمانی باید ایراد بگیریم که با پیدا شدن یک مشکل (Bug) و گزارش کردنش، به سرعت رفع نشه (توی پشتیبانی ضعیف کار کنن). تا وقتی هم که این فریمورک ضعیف، برای دانلود گذاشته نشه، مشکلاتش کشف نمیشه چون ازنظر سازنده، هیچ مشکلی وجود نداره. نسخه Beta رو برای همین وقتها گذاشتن دیگه، درسته؟ ضمناً بحث تعداد سایتهای آپ شده هم ملاک تجربه نیست. خیلی وقتها کارهایی با PHP انجام میشه که اصلاً قرار نیست بصورت Web Site و دامین خاصی در دسترس قرار بگیره (سایتهای داخل شبکه، وب سرویسها و...). دانش و مهارت هم لزوماً به آپ کردن سایت نیست؛ چه بسا افرادی که سایتهای زیادی آپلود کردن ولی همه اون سایتها از پایه مشکل دارن.