یک وبلاگ دیگر از یک برنامه نویس دیگر
نوشتههایی با برچسب امنیت در PHP
HTTP Redirect
شهریور ۲۸م
یه چند وقتی هست که مدام درگیر کارهای امنیتی، خصوصا برای PHP هستم. این دفعه میخوام یه مشکل کوچیک رو توضیح بدم. خیلی ها معمولا اینکار رو انجام میدن (دست کم کدی که من امروز دیدم اینطوری بود! ) :
<?php
if (!check_current_user_has_privilege_to_this_page()){
header("Location: some_other_page.php");
}
//
echo "This is very important data!";
این کد، بررسی میکنه یه تابع دسترسی به این صفحه رو داره، اگر نه پاسش میده به یه صفحه دیگه، در غیر اینصورت (یعنی اگه کاربر دسترسی داشت) اطلاعاتی رو که باید نشون بده نشون میده، یا کارهایی که باید انجام بشه رو انجام میده. اطلاعات و یا کارهایی که ما نمیخوایم کاربر عادی بدون رد کردن شرطهای امنیتی مثل رمز ببینه.
ولی اینجا یه مشکل هست :) خیلی هم بزرگه. header() اطلاعات رو میفرسته به طرف کاربر و در طرف کاربر عمل جابجایی (redirect ) انجام میشه. حالا اگه با یه برنامه که درکی از Redirect و اصولا پروتکل HTTP نداره این صفحه باز بشه؟؟ یا بدتر، اول این افزونه فایرفاکس رو نصب کنید بعد صفحه رو باز کنید، البته قبلش آدرس صفحه رو توی تنظیمات افزون اضافه کنید، اینجوری:
میبینید که صفحه کاملا باز میشه.برای مثال آدرس
http://cyberrabbits.net/non/bigbang/headercheck.php
رو چک کنید که این مشکل رو داره، کدش هم اینه :
<?php
/*
* this is an example for redirect problem :)
* */
if (true)
header("Location: http://google.com");
echo "This is very important data, you can not see this!(or you can :) )";
قاعدتا فسمت echo هیچوقت نباید نمایش داده بشه، ولی اون افزونه نصب و فعال باشه دیده میشه :) این یعنی که این روش یه چیزی کم داره.
خوب چاره چیه؟؟
خیلی ساده :
<?php
if (!check_current_user_has_privilege_to_this_page()){
header("Location: some_other_page.php");
die(); //Very sweet :) little , beautiful function!!
}
//
echo "This is very important data!";
ایجاد مکرر کلید جلسه
شهریور ۱۴م
در مورد جلسات این چند روزه زیاد نوشتم. تو آخرین نوشته، یه دوستی کامنت گذاشتن که استفاده از تابع session_regenerate_id میتونه کمک کنه برای جلوگیری از دزدیدن جلسه ؟ برای تست به این چیزها احتیاج هست :
اول از همه فایرفاکس
دوم فایرباگ
سوم FireCookie
چهارم یک بروزر دیگه غیر از فایرفاکس، مثلا Opera .
کدی مثل این رو ایجاد کنید :
<?php
session_start();
session_regenerate_id();
if (isset($_SESSION['test'])){
echo $_SESSION['test'];
echo "<br />";
echo session_id();
}else{
$_SESSION['test']=$_SERVER['HTTP_USER_AGENT'];
echo "First time";
}
این کد، رشته مربوط به User Agent رو توی جلسه ذخیره میکنه. بعد از دفعه اول که جلسه ایجاد بشه هر بار کلید جلسه هم نمایش داده میشه و همون رشته ذخیره شده، نمایش کلید جلسه فقط برای اینه که دسترسی به کلید جلسه یک کمی راحت شه :D
اول این کد رو توی Opera یا هر بروزری غیر از فایرفاکس اجرا کنید. البته یه Refresh نیازه که کلید و محتوا رو نشون بده.
حالا همون صفحه رو توی فایرفاکس باز کنید. دوبار هم Refresh کنید که هم کلید جلسه رو ببینید هم محتوا رو، این یکی با اون یکی فرق میکنه (طبیعیه دیگه!) حالا توو همین صفحه فایرباگ رو فعال کنید، اگه FireCookie نصب باشه یه تب داره به اسم Cookies اونجا برید، روی PHPSESSID کلیک راست کنید و گزینه Edit رو بزنید:
بعد تو دیالوگ زیر توی قسمت Value مقداری که الان توی Opera (یا هر Browser دیگه که دوست دارید) نمایش داده میشه رو کپی کنید.قبل از اینکه این مقدار کپی شده رو توی فایرفاکس بگذارید، چند بار Opera رو Refresh کنید که یه کلید جدید ساخته بشه (با کمک اون تابع session_regenerate_id ) بعد اون کلیدی که مربوط به جلسه قبل بود و کپی کردید رو توی دیالوگ زیر قسمت Value بگذارید (این دیالوگ رو گفتم، با کلیک راست روی کلمه PHPSESSID و انتخاب گزینه Edit میتونید ببینید، قسمت Host و زمان و … مهم نیست و برای هر کس متفاوته و بستگی داره به هاستی که دارید این کد رو اجرا میکنید ) اینطوری مطمئن میشید که دیگه اون کلید جلسه برای Opera از بین رفته (که البته نرفته !) :
تایید کنید و بعد یه Refresh و اونوقته که اینو میبینید :
یه مشکل دیگه این تابع، اینه که دو بار کوکی مربوط به جلسه رو توی Header میفرسته، Browser های جدید و مدرن مشکلی ندارن با این قضیه ولی مثلا روی بعضی گوشیها قاطی میکنه :)
اگر هم با آرگومان true این تابع رو فراخوانی کنیم، ممکنه مشکل از دست دادن جلسه رو داشته باشیم(توی تست من با Refresh های سریع)، بعلاوه اینکه سرعت رو هم کم میکنه، البته نسبتا.
ممنون از پیام واسه اینکه این تابع رو هم گوشزد کردن.
ذخیره جلسات در پایگاه داده
شهریور ۱۲م
دفعه قبل، درباره دزدیدن جلسه صحبت کردم، هنوز منتشر نشده که فیدبک رو ببینم) به هر صورت، این دفعه میخوام روشی رو توضیح بدم که میشه مشکل ذخیره جلسه رو در فایل سیستم حل کرد.
این راه حل آخرین راه حل در این زمینست. اگه تنظیمات سرور درست نباشه، و یه کاربر دیگه روی سیستم شما، بتونه فایلهاتون رو از طریق کاربر خودش باز کنه، خیلی راحت میتونه سورس شما رو بدزده، به دیتابیس شما دسترسی پیدا کنه و … (تنظیمات دیتابیس رو توی PHP معمولا توی فایل متنی مینویسن، خوب اگه یکی اونو باز کنه و بخونه دیتابیس هم امن نیست :) ) اگه میخواید برنامه خودتون رو منتشر کنید و نمیخواید دیگران به سورسش دسترسی داشته باشن، حتما با یه چیزی مثل Zend Guard از اون محافظت کنید، و از اون مهمتر،قیمت مهمترین فاکتور خرید هاست نیست!!!! فکر میکنم اعتماد و امنیت مهمتر باشه!
شاید بد نباشه که اول راه حل ساده تر رو نشون بدیم.
اولین مساله، اینکه مشخص کنیم آیا واقعا از آخرین دسترسی به این جلسه، یه مدت زمان خاص گذشته یا نه؟ دوم اینکه مشخص کنیم این جلسه واقعا برای همین کاربریه که الان میخواد ازش استفاده کنه؟
این کد رو ببینید :
<?php
//session_save_path("../tmp");
session_start();
//Settings
$diff=10*60; //600 Sec time out
$salt="this-is-uniq-hash-for-any-program";
$_ip=isset ($_SERVER['HTTP_CLIENT_IP'])?
$_SERVER['HTTP_CLIENT_IP'] : "UNKNOWN";
$_ip.=isset ($_SERVER['HTTP_X_FORWARDED_FOR'])?
$_SERVER['HTTP_X_FORWARDED_FOR'] : "UNKNOWN";
$_ip.=isset ($_SERVER['REMOTE_ADDR'])?
$_SERVER['REMOTE_ADDR'] : "UNKNOWN";
$_agent = isset ($_SERVER['HTTP_USER_AGENT']) ?
$_SERVER['HTTP_USER_AGENT'] : 'NO USER AGENT';
$browser_data=$salt.$_ip.$_agent;
$browser_hash=md5($browser_data);
$now=time();
if (isset($_SESSION['last_time']) && isset($_SESSION['browser_hash'])){
if (strcasecmp($browser_hash,$_SESSION['browser_hash'])!=0
|| $now-$_SESSION['last_time']>$diff){
foreach ($_SESSION as $key => $value){
unset($_SESSION[$key]);
}
session_destroy();
//You can pass to login page or whatever :-"
header("Location: ".$_SERVER['PHP_SELF']);
die(); //THIS IS IMPORTANT, never trust user browser,
}
}else{
//this is new session....
//Old session but without time and browser hash ?
//Just destroy it, if any, to prevent hijaking
foreach ($_SESSION as $key => $value){
unset($_SESSION[$key]);
}
$_SESSION['last_time']=$now;
$_SESSION['browser_hash']=$browser_hash;
}
این کد رو دقیقا در ابتدای برنامه بگذارید. دقیقا در ابتدای فایل index.php (معمولا) میتونید یه فایل جدا درست کنید این کد رو توش بنویسید و در ابتدای برنامه اینو include کنید. حالا دیگه هم زمان کنترل میشه هم بروزر، گرچه این متد بسیار بسیار سادست :) ولی خیلی هم موثره.
دقیقا اولین خط کد، که کامنت هم شده،میتونه این امکان رو به شما بده که جای ذخیره شدن جلسات رو عوض کنید، مثلا بیاریدشون روی پوشه های خودتون(که البته باید یه فولدری باشه که وب سرور بهش دسترسی نداشته باشه، یعنی یا با htaccess یا با هر ابزار دیگه ای کاملا قفلش کرده باشید یا اینکه اصلا خارج از پوشه ریشه باشه. البته این پوشه باید توسط PHP قابل نوشتن باشه که بتونه جلسات رو اونجا ذخیره کنه. اگر نه یکی از بیرون و به راحتی از طریق Browser میتونه فایل رو ببینه)
اما راه دوم، که به شما این امکان رو میده که مثلا جلسات رو توی دیتابیس ذخیره کنید، نه توی فایل. از PDO برای دیتابیس استفاده شده.
ادامه مطلب
جلسات PHP : آره یا نه؟ مساله اینه.
شهریور ۵م
مقدمه
باور کنید دست خودم نبود!!! هدفم هم اصلا خرابکاری نیست. بیشتر آزمایشه و اطلاع رسانی. من چیکار کنم آخه؟ وقتی اینقدر ساده میشه امنیت یه وب سایت رو به مخاطره انداخت! هدف من آموزش این نیست که چطور خرابکاری کنید، هدفم اینه که کمک کنم این مشکل برطرف بشه.
بحث اصلی : جلسات
معمولا جلسات، از اون چیزهاییه که تو تمام زبانهای برنامه نویسی تحت وب استفاده میشه. این جلسات، اطلاعاتی هستن که در طرف سرور ذخیره میشه، ولی کلید اونها در طرف کلاینت. این کلید معمولا یه رشته غیر قابل حدسه و به دو صورت رد و بدل میشه.
روش اول از طریق لینکه، یعنی مثلا یه لینکی داریم به این صورت :
http://example.com/?sessid=zGNQE1DlHGFjDZLEfdeNK3rvRC7
وقتی این درخواست میرسه به PHP (من کاری به بقیه زبانها ندارم) خودش جلسه با این شماره (zGNQE1DlHGFjDZLEfdeNK3rvRC7) رو پیدا میکنه و بارگذاری میکنه. البته اگه باشه. اگه نباشه هم که خیلی ساده چشماشو میبنده و رد میشه. راه دوم اینه که کلید جلسه از طریق کوکی منتقل شه، یه جورایی محبوب تره این روش، علتشم اینه که لینک خراب نمیشه، لزومی هم نداره هر لینکی تو صفحه هست این اطلاعات بهش الصاق بشه. (شما باید وقت اجرا این کلید جلسه رو بگیرید و هر لینکی که خواستید ایجاد کنید اینو به انتهاش اضافه کنید ولی توی روش کوکی چون این اطلاعات با کوکی رد و بدل میشه نیاز نیست.)
اگه به صورت لینک باشه، دیگه میشه گفت CSRF که قبلا دربارش نوشتم پیش نمیاد، اما معایبشو گفتم.
حالا اگه یکی تو یه کامپیوتر دیگه، به هر نحوی به این کلید دست پیدا کنه، در زمانی که شما هنوز آنلاین هستید و جلسه اعتبار داره بیاد و صفحه شما رو، با این کلید باز کنه (یعنی اگه لینکه که با ایجاد لینک شبیه سازی شده و اگه کوکیه با ایجاد کوکی مورد نظر درخواستو شبیه سازی کنه، خیلی ساده میره تو حساب شما! ایجاد کوکی هم با FireBug و FireCookie مثل آب خوردنه!!)
به همین علته که میگن هر وقت از پای صفحه خودتون بلند شدید، حتما logout کنید. فکر نکنید چون پشت کامپیوتر خودتونید همه چی آرومه!! نه، ممکنه همین الان یه نفر جلسه شما رو از اون طرف دنیا دزدیده باشه و داخل صفحه شما شده باشه!! با این logout جلسه تعطیل میشه و کلیدش بی ارزش میشه.و اینطوری اون آقا/خانم دزد،با خارج شدن شما، ناکام میمونه، اما اگه اینکارو نکنید ممکنه تا مدتها همچنان فعال باقی باشه.
این که از وسط راه جلسه دزدیده بشه، فقط و فقط یه راه حل داره اونم استفاده از https هستش. یعنی در حالت عادی و غیر https راهی نیست که از دزدیدن کلید در میانه راه جلوگیری کنیم. به عبارتی ISP شما، و تمام کسانی که در مسیر ارتباط شما به سایت قرار گرفتن با یه مانیتورینگ ساده میتونن اطلاعات جلسه رو بدزدن. خوب، اینو میتونید با یه هزینه اضافه امن کنید ولی آیا خطر این دزدیده شدن جلسه فقط همین جاست؟ یعنی اگه جلسه سالم به مقصد رسید :D اونوقت همه چی سر جاشه؟ خوب بالاخره رسیدم به اصل مطلب.
ادامه مطلب
CSRF یا چطور چرخ رو دوباره اختراع کردم
مرداد ۲۲م
امروز یه اتفاق خیلی ساده، یه درس بزرگ بهم داد. داشتم یه برنامه ساده CRUD مینوشتم، یعنی یه برنامه ای که یه سری فیلد رو توی دیتابیس بنویسه، ویرایش داشته باشه و حذف کنه و در نهایت نشون بده.
این برنامه فقط برای نمایش برای یه نفر بود که میخواست یه چیزی یاد بگیره :دی خیلی ساده.
مساله لینک حذف بود، این لینک :
http://localhost/admin.php?del=10
در حقیقت این میومد و ردیف شماره ۱۰ رو حذف میکرد. البته توی admin.php بررسی میشد که آیا کاربر اجازه دسترسی داره یا نه. اگه اجازه حذف داشت اونوقت حذف رو انجام میداد. به نظر همه چی درست بود، ولی یه اتفاق باعث شد بفهمم یه جای کار میلنگه.
این لینک رو اتفاقی کپی کردم توی کلیپ برد. خودمم همزمان میخواستم یه جایی تو یه پیغام شخصی فروم، یه عکس بگذارم. منتها اشتباها این لینک کپی شد به جای لینک عکس اصلی. از اونجایی که دقت منم در حد تیم ملیه :) عکس رو با بدون اینکه آدرسش رو چک کنم گذاشتم توی پیغام، دکمه پیشنمایش رو زدم و …
باقیش معلومه. فیلد ۱۰ حذف شد، و من حتی متوجه نشده بودم تا یه کم بعد رفتم دوباره سراغ برنامه.
خوب این یعنی که با اینکه من امنیت رو کاملا حفظ کرده بودم توی فایل admin.php ولی این امنیت خیلی راحت به هم ریخت با وادار شدن من برای دیدن یه عکس. خوب اگه اینکار رو یه نفر دیگه انجام میداد و یه پیغام حاوی لینک حذف برای من میفرستاد که مثلا به صورت عکس جاسازی شده بود، خیلی راحت به مقصودش میرسید. من اجازه حذف دارم، و فقط کافیه اون لینک یه بار توسط من ویزیت بشه، به هر صورتی.
راه چاره چیه؟؟ اینکه از متد GET استفاده نکنیم.یا اینکه تو صفحه دوم هم یه سوال بپرسیم و بعد از طریق متد پست حذف نهایی رو توی مرحله دوم انجام بدیم، یه کمی به نظر من اعصاب خورد کنه.
البته من یه پیشنهاد هم دارم، که فکر میکنم بد نباشه. یه کلمه رندوم ایجاد بشه تو هر جلسه برای هر کاربر، مثلا به اسم $salt . از هر جلسه به جلسه دیگه متفاوت باشه. به جای لینک بالا، از این لینک استفاده بشه (یا چیزی شبیه اون):
http://localhost/admin.php?del=10&salt=$slat
وقت حذف علاوه بر بررسی سطح دسترسی کاربر این “نمک” هم بررسی بشه :) اگه اونم با متغییری که تو جلسه ذخیره شده برابر بود کاری که باید انجام بشه،انجام بشه.
اینطوری، کسی نمیتونه لینک رو درست کنه. (مگه اینکه یه جوری جلسه مدیر رو بدزده، که خوب در اون صورت دسترسی خود مدیر رو داره و دیگه لازم نیست یه همچین کارهایی رو انجام بده، خودش دسترسی داره و میتونه هر کاری میخواد بکنه!!)
پ.ن : به این روش میگن CSRF یا Cross-Site Request Forgery که جالب اینه که خودم هم میدونستم ولی هیچوقت دقت نکرده بودم یعنی همیشه طور دیگه ای بهش نگاه میکردم، اینکه مثلا یه سایت خطرناک رو به خورد کاربر بدن نه سایتی که اصلا خطری نداره و اتفاقا کاربر اجازه دسترسی بهش رو داره و از دسترسی کاربر سواستفاده بشه. این روش هم من دوباره کشف کردم، قبل از من بازم کشف شده بوده :D و من فقط دوباره چرخ رو اختراع کردم!!
بیشتر درباره این قضیه که بگردید دوباره منابع بهتری رو پیدا میکنید و راه حلهای دقیقتر و بهتری.








