یادداشتهای بیت نیمسوز

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

این راه حل آخرین راه حل در این زمینست. اگه تنظیمات سرور درست نباشه، و یه کاربر دیگه روی سیستم شما، بتونه فایلهاتون رو از طریق کاربر خودش باز کنه، خیلی راحت میتونه سورس شما رو بدزده،‌ به دیتابیس شما دسترسی پیدا کنه و … (تنظیمات دیتابیس رو توی 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 برای دیتابیس استفاده شده.
خواندن ادامه این مطلب »

اگه دقت کنید، سمت راست سایت یه افزونه هست که تگها رو به صورت فلش نشون میده که جلوه قشنگی هم داره. منتها این افزونه فارسی رو درست نشون نمیداد و همین زیاد به دل من یکی نمینشست.
از طرفی، نویسنده این افزونه در این پست خودش نوشته چطور فارسی رو بهش اضافه کنید که ما رفتیم سراغش و متاسفانه موفقیت آمیز نبود :) یعنی همه نوشته ها رو جدا جدا نشون میداد مثل این :

افزونه WP-Cumulus

منتها از اونجایی که دیگه تصمیم بر این شده بود که حتما اینکار انجام بشه، با یه کم این ور و اون ور کردن تونستم این نسخه رو پیدا کنم که خیلی هم درست و حسابی کار میکنه، فقط البته با فلش ۱۰ و دیگه فلش ۹ رو پشتیبانی نمیکنه :)‌
از کجا؟؟ اینو از اینجا برداشتم :))
شما کافیه که فایل اتچ شده به انتهای این پست رو دانلود کنید، توی پوشه افزونه WP-Cumulus کپی کنید (به جای فایل tagcloud.swf اصلی) و بعد همه چی درسته !! اینم نتیجش (که البته توی سایت هم میتونید ببینید ) :
خواندن ادامه این مطلب »

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

http://example.com/?sessid=zGNQE1DlHGFjDZLEfdeNK3rvRC7

وقتی این درخواست میرسه به PHP (من کاری به بقیه زبانها ندارم) خودش جلسه با این شماره (zGNQE1DlHGFjDZLEfdeNK3rvRC7) رو پیدا میکنه و بارگذاری میکنه. البته اگه باشه. اگه نباشه هم که خیلی ساده چشماشو میبنده و رد میشه. راه دوم اینه که کلید جلسه از طریق کوکی منتقل شه، یه جورایی محبوب تره این روش، علتشم اینه که لینک خراب نمیشه، لزومی هم نداره هر لینکی تو صفحه هست این اطلاعات بهش الصاق بشه. (شما باید وقت اجرا این کلید جلسه رو بگیرید و هر لینکی که خواستید ایجاد کنید اینو به انتهاش اضافه کنید ولی توی روش کوکی چون این اطلاعات با کوکی رد و بدل میشه نیاز نیست.)
اگه به صورت لینک باشه، دیگه میشه گفت CSRF که قبلا دربارش نوشتم پیش نمیاد، اما معایبشو گفتم.

حالا اگه یکی تو یه کامپیوتر دیگه،‌ به هر نحوی به این کلید دست پیدا کنه، در زمانی که شما هنوز آنلاین هستید و جلسه اعتبار داره بیاد و صفحه شما رو،‌ با این کلید باز کنه (یعنی اگه لینکه که با ایجاد لینک شبیه سازی شده و اگه کوکیه با ایجاد کوکی مورد نظر درخواستو شبیه سازی کنه، خیلی ساده میره تو حساب شما! ایجاد کوکی هم با FireBug و FireCookie مثل آب خوردنه!!)
به همین علته که میگن هر وقت از پای صفحه خودتون بلند شدید، حتما logout کنید. فکر نکنید چون پشت کامپیوتر خودتونید همه چی آرومه!! نه، ممکنه همین الان یه نفر جلسه شما رو از اون طرف دنیا دزدیده باشه و داخل صفحه شما شده باشه!! با این logout جلسه تعطیل میشه و کلیدش بی ارزش میشه.و اینطوری اون آقا/خانم دزد،‌با خارج شدن شما،‌ ناکام میمونه، اما اگه اینکارو نکنید ممکنه تا مدتها همچنان فعال باقی باشه.

این که از وسط راه جلسه دزدیده بشه، فقط و فقط یه راه حل داره اونم استفاده از https هستش. یعنی در حالت عادی و غیر https راهی نیست که از دزدیدن کلید در میانه راه جلوگیری کنیم. به عبارتی ISP شما، و تمام کسانی که در مسیر ارتباط شما به سایت قرار گرفتن با یه مانیتورینگ ساده میتونن اطلاعات جلسه رو بدزدن. خوب، اینو میتونید با یه هزینه اضافه امن کنید ولی آیا خطر این دزدیده شدن جلسه فقط همین جاست؟ یعنی اگه جلسه سالم به مقصد رسید :D اونوقت همه چی سر جاشه؟ خوب بالاخره رسیدم به اصل مطلب.
خواندن ادامه این مطلب »

یه سایت خیلی چیزها نیاز داره، خیلی چیزها،ولی بعضی چیزها اونقدر مهمن که از نون شبم واجبترن. یکی از این بعضی چیزها Sitemap هستش، نه مثل این نقشه سایتی که من توی منوی کناریم دارم! نه. یه نقشه سایت با فرمت XML برای موتورهای جستجو، مثل این که تو این آدرسه.
خوب این چیه؟ چه اطلاعاتی رو ارایه میده و اصولا چرا ساخته میشه؟ خیلی سادست، این فایل تمام صفخات ما رو به موتورهای جستجو معرفی میکنه. البته موتورهای جستجو، اکثرا فید رو هم قبول میکنن برای اینکار ولی این sitemap یه چیز دیگست.
پروتکل نقشه سایت اینجا تعریف شده و در حقیقت ابتکار اولیه مربوط به گوگله ولی در حال حاضر همه (دست کم موتورهای جستجوی با پدر و مادر مثل bing یا yahoo یا ask) ازش پشتیبانی میکنن.
برای اینکار یه فایل xml (معمولا به اسم sitemap.xml ) ایجاد میشه،‌و توش یه ساختاری شبیه این پیاده میشه :
خواندن ادامه این مطلب »

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

نمیدونم مشکل از وردپرس بود که با این ساختار قاطی میکرد یا اینکه پلاگینها مشکل داشتن؟ به هر حال WP_Query وقتی این لینکها رو بررسی میکرد، بدون دلیل توی کوئری مربوط به صفحه یه جفت شرط بی معنی هم اضافه میکرد حالا حتی اگه میخواستی لینک رو دلخواه بدی و حتی اگه لینک رو خودت دستی ایجاد کرده بودی، به عبارتی کلاس WP_Query به هیچ عنوان مستقل عمل نمیکرد!