سشین در امنیت چقدر میتونه تاثیر داشته باشه؟

[raspina007]

سلام دوستان و استادان عزیز
بنده یه مسئله ای چندین وقته که خیلی مغزم رو درگیر کرده و از دوستان عزیزم میخام منو راهنمایی کنند
اگر در فایل پی اچ پی من از سشین استفاده کنم و اگر این سشین یا مقامش مدیر بود صفحه لاگین رو بیاره و اگر نبود ریدایرکت کنه به صفحه ای دیگر چقدر روی امنیت تاثیر داره؟
ایا سشین رو میشه دستکاری کرد یا دور زد؟ نمونه کد نوشته شده و ادرس یک فایل که با این دستور نوشتم رو میذارم ممنون میشم تست کنید و بنده حقیر رو راهنمایی کنید





if (isset($_SESSION['etchat_db1_user_id'])) {
$id=$_SESSION['etchat_db1_user_id'];
$t=mysql_query("select * from db1_etchat_user where etchat_user_id ='".$id."'");
$o=mysql_fetch_array($t);
$magham=$o['etchat_userprivilegien'];

$r=mysql_query("select * from db1_etchat_createdaraje where daraje ='".$magham."'");
$a=mysql_fetch_array($r);


if (($o['etchat_userprivilegien']=="admin") || ($o['etchat_userprivilegien']=="mod") || ( $o['etchat_userprivilegien']=="moaven") || ($a['panel'] == "1") ){


}
else {

header("location:../index.php");
}
}
else {

header("location:../index.php");
}





و اینم لینک نمونه جهت تست (http://elizabetchat.net/mod)
تشکر

[raspina007]

دوستان و استادان عزیز کسی نیست جواب بده؟:افسرده:

[omidabedi]

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

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

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

یک نکته ی دیگه اینکه سشن هرچند که حودشم ایمن باشه اما خب امنیت یه چیز ارتباطی هست یعنی شاید یه باگ دیگه در اسکریپت باشه که باعث بشه سشن هم سرقت بشه مثل xss

یا مثلا با باگ sqli میشه باگ xss ساخت

یا یک باگ sqli باعث بشه کل سرور هک بشه

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

[raspina007]

درود
با تشکر از دوست عزیزمون از کمکی که کردن
ولی من واسه جلوگیری از این باگ ها هم از این روش استفاده کردم
و اینپوت ها رو با استفاده از این روش فیلتر گذاشتم ایا جوابگوی کار من هست ؟





function check_post ($input) {

$res1 = mysql_real_escape_string($input);
$res2 = htmlspecialchars($res1);
$res3 = strip_tags($res2);
$res4 = addslashes($res3);
$res5 = trim($res4);

return $res5;
}

[omidabedi]

درود
با تشکر از دوست عزیزمون از کمکی که کردن
ولی من واسه جلوگیری از این باگ ها هم از این روش استفاده کردم
و اینپوت ها رو با استفاده از این روش فیلتر گذاشتم ایا جوابگوی کار من هست ؟





function check_post ($input) {

$res1 = mysql_real_escape_string($input);
$res2 = htmlspecialchars($res1);
$res3 = strip_tags($res2);
$res4 = addslashes($res3);
$res5 = trim($res4);

return $res5;
}





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

و این کارو انجام دادن برای همه ی داده ها , باعث میشه داده هاتم مشکل پیدا کنه

یه زمانی هست اصلا شما میخواید از متغییر در برنامه استفاده کنید قرار نیست در دیتابیس ذخیره بشه پس لازم نیست mysql_real_escape_string استفاده کرد!

و ....

[godofphp]

بهتره برای امنیت بیشتر مقادیر سشن ها رو encrypt کنید یعنی یه جوری به حالت کد در بیارید که کسی نفهمه چی داره توش مثلا میتونی از md5 استفاده کنی ...

[behnamy01]

این جریان session hijacking چیه دوستان؟

[omidabedi]

این جریان session hijacking چیه دوستان؟

به سرقت سشن از طریق باگ های برنامه,کاربر,مرورگر و ... میگن session hijacking

باگ رایج اینکار XSS هست اما خب تنها راه نیست

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

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

سرور هستید رو سرقت کرد (البته در مورد این مورد اخری اطلاعات دقیقی ندارم اما فکر کنم به کانفیگ سرور هم ربط داشته باشه)

روش های دیگه هم هست که رایج نیست و یا patch شده

مثل باگ heartbleed که همین چند مدت پیش کل جهان رو نگران کرد از این طریقم میشه به سشن دسترسی داشت (مثالی از باگ خاص)

یکی از راه های غیر متعارف حدس زدن token سشن هست!!که خب امروزه بدلیل اینکه اکثر برنامه نویس ها از source های موجود استفاده میکنن برای یادگیری میشه یجورایی پیش بینی کرد که این روش خیلی

غیرمتعارفم نیست

یکی از راه هایی هم که قبلا برای سرقت سشن استفاده میشد باگ مرورگر بود

نمیگم الان همه ی مرورگرها اوکی هستند اما خب تا حد قابل قبولی امنیت رو تامین میکنن

حتی کروم خودش میاد جلوی باگ XSS رو میگیره باگی که از طریق URL هست که همون escape نکردن GET

یکی دیگه از راه ها استفاده از تروجان ها هست برای سرقت سشن که از دست برنامه نویس خارج هست و به MAN IN THE BROWSER ATTACK معروف هست (یعنی بهتر بگم یکی از زیرشاخه های این نوع حمله)

یک نوع حمله ی دیگه هم هست که زیر شاخه ی MAN IN THE MIDDLE هست که میشه با استفاده از SSL جلوشو گرفت اما خب اینم راه دور زدن داره که خب بصرفه نیست برای هر سایتی!

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

[abolfazl-z]

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

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


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

البته از نظر من چه سشن روی هاست باشه و چه روی DBMS در امنیت هیچ تفاوتی حاصل نمیشه.

[behnamy01]

به سرقت سشن از طریق باگ های برنامه,کاربر,مرورگر و ... میگن session hijacking

باگ رایج اینکار XSS هست اما خب تنها راه نیست

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

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

سرور هستید رو سرقت کرد (البته در مورد این مورد اخری اطلاعات دقیقی ندارم اما فکر کنم به کانفیگ سرور هم ربط داشته باشه)

روش های دیگه هم هست که رایج نیست و یا patch شده

مثل باگ heartbleed که همین چند مدت پیش کل جهان رو نگران کرد از این طریقم میشه به سشن دسترسی داشت (مثالی از باگ خاص)

یکی از راه های غیر متعارف حدس زدن token سشن هست!!که خب امروزه بدلیل اینکه اکثر برنامه نویس ها از source های موجود استفاده میکنن برای یادگیری میشه یجورایی پیش بینی کرد که این روش خیلی

غیرمتعارفم نیست

یکی از راه هایی هم که قبلا برای سرقت سشن استفاده میشد باگ مرورگر بود

نمیگم الان همه ی مرورگرها اوکی هستند اما خب تا حد قابل قبولی امنیت رو تامین میکنن

حتی کروم خودش میاد جلوی باگ XSS رو میگیره باگی که از طریق URL هست که همون escape نکردن GET

یکی دیگه از راه ها استفاده از تروجان ها هست برای سرقت سشن که از دست برنامه نویس خارج هست و به MAN IN THE BROWSER ATTACK معروف هست (یعنی بهتر بگم یکی از زیرشاخه های این نوع حمله)

یک نوع حمله ی دیگه هم هست که زیر شاخه ی MAN IN THE MIDDLE هست که میشه با استفاده از SSL جلوشو گرفت اما خب اینم راه دور زدن داره که خب بصرفه نیست برای هر سایتی!

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

[alireza.stack]

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

این دو متد روشی کاملا جدا از هم و راستای هم هستند و برنامه نویسان بسته به Scale کاری آن را در فایل یا بانک ذخیره میکنند و اینطور نمیتوان گفت که چند سالی است سشن در بانک ذخیره میشود!


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

سرور هستید رو سرقت کرد (البته در مورد این مورد اخری اطلاعات دقیقی ندارم اما فکر کنم به کانفیگ سرور هم ربط داشته باشه)

کاملا به کانفیگ سرور ربط دارد و ادمین میتواند scope های متفاوت برای ذخیره سشن های virtual host ها در نظر بگیرد.


مثل باگ heartbleed که همین چند مدت پیش کل جهان رو نگران کرد از این طریقم میشه به سشن دسترسی داشت (مثالی از باگ خاص)

Heartbleed باعث Memory leak می شود و باعث میشود از آدرسهای خاص رم کامپیوتر کاربر شروع به واکشی اطلاعات کرد که session hijacking یکی از آنهاست (تنها در جهت تکمیل حرفهای شما ;-) )

[omidabedi]

این دو متد روشی کاملا جدا از هم و راستای هم هستند و برنامه نویسان بسته به Scale کاری آن را در فایل یا بانک ذخیره میکنند و اینطور نمیتوان گفت که چند سالی است سشن در بانک ذخیره میشود!


ذخیره سشن در دیتابیس از همون اول عرف نبوده که

الان خیلی وقت نیست عرف شده

و اینکه بسته به کاربرد بعضی جاها استفاده میشه اصلا حرف صحیحی نیست (مطمئنا دلیل نمیشه که فقط برا همون کار استفاده بشه)

خودمم میدونم که این 2متد sqli و session highjacking دوتا چیز متفاوت هستند اگه توجه کنید میبینید که دارم روش های مختلفی برای سرقت سشن میگم

که منظور اینه که اگر سشن در دیتابیس ذخیره بشه از طریق این باگ میشه سرقتش کرد !



Heartbleed باعث Memory leak می شود و باعث میشود از آدرسهای خاص رم کامپیوتر کاربر شروع به واکشی اطلاعات کرد که session hijacking یکی از آنهاست (تنها در جهت تکمیل حرفهای شما ;-) )


منم نگفتم که این باگ فقط برای سرقت سشن هست

گفتم که از این طریقم میشه

داشتم لیست میکردم چندتا راه رو

بعدشم اینکه استارتر تازه کاره من با جزئیات بگم بدتر گیج میشه

کافیه تو ویکی پدیا سرچ کنه heartbleed

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

[omidabedi]

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

ای دی سشن رو ذخیره میکنیم در دیتابیس و هر اطلاعات اضافه ای که برای همون ای دی ثبت میشه

بعلاوه یک ساعت انقضا که اگه کاربر با سیستمش کار نکرد خودش پاک بشه

زیاد پیچیده نیست

[omidabedi]

http://php.net/manual/en/session.security.php

اینم بخون مال خود سایت php

[alireza.stack]

ذخیره سشن در دیتابیس از همون اول عرف نبوده که

الان خیلی وقت نیست عرف شده

و اینکه بسته به کاربرد بعضی جاها استفاده میشه اصلا حرف صحیحی نیست (مطمئنا دلیل نمیشه که فقط برا همون کار استفاده بشه)

خودمم میدونم که این 2متد sqli و session highjacking دوتا چیز متفاوت هستند اگه توجه کنید میبینید که دارم روش های مختلفی برای سرقت سشن میگم

که منظور اینه که اگر سشن در دیتابیس ذخیره بشه از طریق این باگ میشه سرقتش کرد !



منم نگفتم که این باگ فقط برای سرقت سشن هست


بسته به کاربرد استفاده میشه میدونید چرا؟ در مقیاس یه شبکه اجتماعی در نظر بگیرید یا سیستم فایل آپلود... در این حالت آیا منطقی است که ما اطلاعات رو در Database ذخیره کنیم یا در SystemFile؟ (هر چند هر دو در سیستم فایل در نهایت ذخیره میشونو اما اونی که در بانک هست یک خواندن ساده فایل نیست و باید اتصال به بانک برقرار بشه و بابت اون رم اختصاص داده بشه و Query Planner اجرا بشه و هزار داستان دیگه اما در خواندن فایل از سیستم فایل اینگونه نیست) در زمانی که نیاز به Performance هست و کاربران زیادی داریم منطقی به نظر نمی رسد که در بانک ذخیره کنیم و باید از File system بخوانیم/

نکته HeartBleed رو هم اگر دقت کرده باشید عرض کردم :‌در تکمیل صحبتهای شما و حرف شما را بنده نقد نکردم.

موفق و پیروز باشید. ;-)

[omidabedi]

بسته به کاربرد استفاده میشه میدونید چرا؟ در مقیاس یه شبکه اجتماعی در نظر بگیرید یا سیستم فایل آپلود... در این حالت آیا منطقی است که ما اطلاعات رو در Database ذخیره کنیم یا در SystemFile؟ (هر چند هر دو در سیستم فایل در نهایت ذخیره میشونو اما اونی که در بانک هست یک خواندن ساده فایل نیست و باید اتصال به بانک برقرار بشه و بابت اون رم اختصاص داده بشه و Query Planner اجرا بشه و هزار داستان دیگه اما در خواندن فایل از سیستم فایل اینگونه نیست) در زمانی که نیاز به Performance هست و کاربران زیادی داریم منطقی به نظر نمی رسد که در بانک ذخیره کنیم و باید از File system بخوانیم/

نکته HeartBleed رو هم اگر دقت کرده باشید عرض کردم :‌در تکمیل صحبتهای شما و حرف شما را بنده نقد نکردم.

موفق و پیروز باشید. ;-)

دوست عزیز performance دیتابیس انجین هم اونقدرا کم نیست بخصوص واسه سایت های بزرگ که از ابر رایانه ها استفاده میکنن

نتنها ذخیره سشن در دیتابیس برای سایت های بزرگ لازمه و باعث کند شدن سایت نمیشه بلکه واجب هست که سشن رو در دیتابیس ذخیره کنن

حالا چرا؟

چون سایتی به اون بزرگی که شما میفرمایید نیاز به چند سرور داره در نتیجه باید سشن رو در دیتابیس ذخیره کنه که از همه ی سرور ها بهش دسترسی داشته باشه

اگر توی temp file ذخیره کنه تنها سشن بر روی سروری معتبر هست که یوزر لاگین کرده و authenticate شده

موجه تر از این دلیل پیدا نکردم که ارائه بدم هرچند ذخیره کردن سشن در دیتابیس توجیه های زیادی داره

کلا نباید این روش رو محدود کرد و بگیم استفاده ی خاص (به این معنی نیست که نباید و یا نشه در سیستم های عادی استفاده بشه)