آمارگیری درمورد امنیت فایلهای سشن در هاستهای اشتراکی

[eshpilen]

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


<?php

error_reporting(E_ALL);
ini_set('display_errors', '1');

echo '<hr><center><b>session_save_path:</b> ', session_save_path(), '</center><hr>';

echo '<hr><center><b>open_basedir:</b> ', ini_get('open_basedir'), '</center><hr>';

phpinfo();

?>

اون دستور اول (session_save_path) مکان ذخیره سازی سشن های شما رو نشون میده.
مثلا برای سایت من خروجیش اینه:

/var/www/clients/client**/web***/tmp
نکته: بجای هرکدام از اون ستاره ها یک عدد بود که فکر کردم بهتره به دلایل امنیتی پنهانشون کنم.

خب الان مثلا در مورد من مشاهده میکنید که هاست بصورت پیشفرض فایلهای سشن من رو در یک دایرکتوری در داخل دایرکتوری مخصوص اکانت خودم ذخیره میکنه (تا جاییکه واضحا از آدرس برمیاد).
بنابراین بنظر میاد هاست من تنظیمات امنی داره.
اما باید توجه داشت که در این بین تنظیمات دیگری مثل open_basedir و پرمیشن های دایرکتوریهای اکانت خودمون هم نقش دارن (تازه فعال بودن یا نبودن امکان استفاده از برنامه های CGI غیر از PHP رو هم باید بحساب آورد!!). خلاصه ریزه کاری زیاد هست که باید چک کرد. واسه همین من مقدار open_basedir رو هم در کد گذاشتم (مال خودتون رو درج کنید. البته یوزرنیم اکانت خودتون رو میتونید بخاطر امنیت تبدیل به ستاره کنید).
open_basedir من اینه:

/var/www/clients/client**/web***/web:/var/www/clients/client**/web***/tmp:/var/www/example.com/web:/srv/www/example.com/web:/usr/share/php5:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin
البته بازم به دلایل امنیتی، اسم دامین خودم رو با example.com جایگزین کردم.
جهت توضیح بگم که open_basedir آدرس دایرکتوری هایی روی سرور که میتونید در برنامه های PHP بهشون دسترسی داشته باشید رو مشخص میکنه.
اگر دقت کنید، در لینوکس هر آدرس با کالن (:) از آدرسهای دیگر جدا شده. روی سرورهای ویندوز احتمالا از سمی کالن استفاده میشه.

اما یک وقت اگر آدرس session_save_path شما چنین چیزی باشه:

/tmp
به معنای اینه که فایلهای سشن شما در سمت سرور در دایرکتوری tmp عمومی سرور ذخیره میشن، و بنابراین دیگر سایتهای روی اون سرور ممکنه بهش دسترسی داشته باشن.

خب حالا این ممکنه رو از کجا باید بفهمیم؟

در بخش خروجی phpinfo نگاه کنید ببینید جلوی Server API چی نوشته.
اگر چیزی مثل این رو نوشته:

Apache 2.0 Handler
به معنای اینه که سشن های شما در معرض دسترسی سایتهای دیگر روی اون هاست هستن.

اما اگر یه چیزی مثل اینه:

CGI/FastCGI

اونوقت بگید تا باز هم تستهایی رو بگم که انجام بدید. چون بقیش رو خودمم الان اطمینان/حضور ذهن ندارم! البته در خروجی phpinfo در قسمت Loaded Modules ببینید چیزی به نام mod_suexec و/یا mod_suphp دیده میشه یا نه. هرکدام که بود بگید اون مورد هست.
بعد میتونیم یکسری تستهای بیشتر هم انجام بدیم تا بفهمیم واقعا روی سرور چه خبره و آیا فایلهای سشن ما امنیت دارن یا نه.

--------------------------------------------------------------------

اینه که میگم سشن خیلی دردسر داره و تامین امنیتش مشکله.
چون به شونصد جا ربط داره!! منجمله کانفیگ های هاست که دست شما یا PHP هم نبودن.
ولی دیتابیس دیگه این همه تنظیم و ترکیب های گوناگون داخلی و خارجی نداره. خیالتون راحته و در کنترل کامل خودتون. دیتابیس اصلا حالت ناامنی نداره!

[eshpilen]

سشن و امنیت اون مسأله مهمی هست که باید در مورد اون خیلی بحث کنیم
بدبختی اینکه روی هر هاست خاص باید بررسی و تستهای دستی هم انجام داد تا مطمئن شد. میگم که به شونصد جا ربط داره! بعضیاش هم دست برنامه نویس یا تنظیمات PHP نیست اصلا.
حالا شما میخوای یه برنامه بنویسی که به راحتی و خودکار روی هر هاستی که نصب بشه امن باشه و اینقدر وابسته به عوامل خارجی و نیازمند دستکاری و بررسی کاربر نباشه. خب راحتترین و سریعترین راهش اینه که اصلا از سشن استفاده نکنیم و هر چیزی رو که میتونیم در دیتابیس ذخیره کنیم و فقط درموارد کمتر امنیتی و موقتی از سشن استفاده کنیم. البته بنده یک سیستم رمزنگاری روی سشن های خودم گذاشتم که بخش اعظم این مشکلات رو برطرف میکنه، ولی خب اونم پردازش مصرف میکنه و بازم اون انعطاف و راحتی دیتابیس رو نداره، علاوه بر پیچیدگی افزوده ای که خودش مایهء نگرانی هست بخاطر احتمال وجود باگ.
البته یک راه دیگر هم ذخیرهء سشن در دیتابیس هست، ولی اونم برای خیلی کاربردها شاید دنگ و فنگ بیش از حد داشته باشه.

[imanitc]

صحبتهاي دوستان در اين رابطه درسته ولي ذخيره سازي سشن در هاست اشتراکي اشکالاتي داره ولي فهميدن اينکه کدوم سشن الان مال کدوم سايت و کاربر کار ساده اي نيست ضمنا شما ميتونيد مسير ذخيره شدن سشن رو تغيير بديد البته اگر هاست بهتون اين اجازه رو بده ذخيره کردن اطلاعات سشن در ديتا بيس هم مشکلات خاص خودش داره کندي و افزونگي ديتا و ايمني از جمله معايبي که به ذهن من ميرسه در هر صورت بنظر نبايد هيچ وقت چيز مهمي رو داخل سشن ريخت ميشه اطلاعات رو با يه کليد و کد شخصي رمز کرد تا کسي از اون سر در نياره

[eshpilen]

ولي فهميدن اينکه کدوم سشن الان مال کدوم سايت و کاربر کار ساده اي نيست
در خیلی سناریوها هم کار نسبتا ساده ایه.
روشها و نشت های اطلاعاتی زیادی هست که میشه ازشون استفاده کرد. میشه با همون PHP براش برنامه نوشت که خودش بر طبق معیارهای خاصی بگرده و پیدا کنه.
گذشته از اینکه کسی که میخواد از در دسترس بودن سشن سوء استفاده کنه ممکنه کاربر خود سیستم باشه و میخواد سشن خودش رو پیدا کنه، که در این صورت براش مثل آب خوردنه (چون آیدی سشن خودش رو داره).
البته اینکه میگم کاربر خود سیستم منظورم این نیست که همهء کاربران سایت شما میتونن به سشن های شما دسترسی داشته باشن. نه شرطش اینه که طرف هم مثل شما روی سرور شما اکانت داشته باشه. ولی خب این کاری نیست که نشه کرد. شاید هم طرف روی سرور شما اکانت داشته و بعد از اینکه بررسی کرده که به سشن ها دسترسی داره اومده و توی سایت شما ثبت نام کرده تا از دسترسی ای که به سشن های شما داره سوء استفاده کنه.

[imanitc]

اگر اطلاعات رو کد کنيم بصورتيکه کسي غير برنامه نويس نتونه سر در بياره بعد بريزيم توي سشن حتي کوکي اونوقت مشکلي پيش نمياد
ببينيد بالاخره ما ناگذير از استفاده از سشن هستيم حتي کوکي
سايت هاي مهم معتبري مثل گوگل يا ياهو و .... از کوکي به راحتي استفاده ميکنن حالا چون سرور احتصاصي دارن ميگيم مشکل سشن ندارن و کوکي دارن استفاده ميکنن به راحتي هم شما ميتونيد پيداش کني روي سيستمت ولي چيزي ازش سر در نمياري منم منظور همين امنينت کد ببريم بالا تا امنيت برنامه به سرور و هاست و کاربر بستگي نداشته باشه

[mtchabok]

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

[eshpilen]

اگر اطلاعات رو کد کنيم بصورتيکه کسي غير برنامه نويس نتونه سر در بياره بعد بريزيم توي سشن حتي کوکي اونوقت مشکلي پيش نمياد
چیزی که شما داری میگی، «امنیت از طریق تیرگی (http://barnamenevis.org/showthread.php?325555-security-through-obscurity-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%A7%D8%B2-%D8%B7%D8%B1%DB%8C%D9%82-%D8%AA%DB%8C%D8%B1%DA%AF%DB%8C)» است.
واقعا چقدر برنامه نویسهای ما برا امنیت از طریق تیرگی اتکا میکنن! راجع بهش قبلا مقاله دادم و صحبت کردم بخاطر همین.
اتکا بر امنیت از طریق تیرگی در دنیای امنیت حرفه ای جایی نداره.

اگر بخوایم چنین کاری بکنیم، درستش اینه که از روشهای رمزنگاری حرفه ای استفاده بشه، نه اینکه فقط یک کاری کنیم که «کسي غير برنامه نويس نتونه سر در بياره». اون رمزنگاری و امنیت نیست، شبه رمزنگاری و شبه امنیته.
این دوتا دیدگاه و روش با هم خیلی تفاوت دارن.


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

بله کوکی رو هم اگر درست استفاده کنی هیچ مشکلی نداره. اصلا راه دیگری نداره. بالاخره کلاینت رو باید از سمت کلاینت احراز هویت کنیم دیگه. ولی باید بدونی چطوری.
در 99% موارد نیاز ضروری به پیچوندن هم نیست.
بلکه باید برنامه رو طوری بنویسی که در برابر همهء حملات و جعل و دستکاری اطلاعات سمت کلاینت بقدر کافی امن باشه. اصلا فرض آدم موقعی که برنامه وب مینویسه باید این باشه که یک هکر باسواد و باانگیزه با دسترسی به امکانات سخت افزاری و نرم افزاری گسترده که کدمنبع و الگوریتم برنامه رو هم در اختیار داشته و کامل و دقیق مطالعه کرده و فهمیده در سمت کلاینته و میخواد به سیستم نفوذ کنه یا خرابکاری کنه. در دنیای امنیت حرفه ای و بخصوص علم رمزنگاری، این یک فرض و شرط پایه و تغییرناپذیره.

[eshpilen]

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

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

بعد تازه شما فکر میکنی فقط همینه و به همین سادگیه و دیگه احتمال خطری نیست؟
باید بگم اینطور نیست.
داستانش از این پیچیده تر و گسترده تره.
کاملا امکانش هست که در یک دایرکتوری اختصاصی هم ذخیره کنی، ولی هنوز امکان دسترسی باشه.
چون به خیلی تنظیمات و پارامترهای خارجی دیگر این مسئله وابسته هست.
مثلا در شرایطی ممکنه بشه با برنامه های CGI دسترسی پیدا کرد (حالا توضیح و جزییاتش رو فعلا بخاطر کوتاه شدن مطلب و اینکه خودمم وقت و حوصله ندارم نمیگم، ولی اونی که به ساختار سرورهای لینوکس وارد باشه یخورده فکر کنه میفهمه چی میگم).
از یک طرف دیگه مثلا باید تنظیم open_basedir رو هم چک کنی که مشکلی نداشته باشه.

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

منم حرفم این نبود که سشن رو نمیشه امن کرد و اصلا بدرد هیچ کاری نمیخوره، بلکه میخواستم بگم چقدر ضعفهای امنیتی داره و یک آماری هم بگیریم (چون نسبت به چند سال پیش احتمالا وضع کانفیگ های پیشفرض ممکنه خیلی بهتر شده باشه و تعداد سرورهایی که کانفیگ امنی ندارن خیلی کمتر شده باشه).

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

ضمنا با استفاده از دیتابیس بجای سشن، برنامه میتونه به راحتی و بصورت خودکار نصب و کانفیگ بشه و نیاز به دخالت دستی کاربر نباشه. این هم از نظر یوزرفرندلی خیلی بهتره و هم از نظر امنیتی (چون کاربر ممکنه به علل مختلف اون کار رو درست انجام نده).


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

[mtchabok]

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

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


بعد تازه شما فکر میکنی فقط همینه و به همین سادگیه و دیگه احتمال خطری نیست؟
باید بگم اینطور نیست.
داستانش از این پیچیده تر و گسترده تره.
کاملا امکانش هست که در یک دایرکتوری اختصاصی هم ذخیره کنی، ولی هنوز امکان دسترسی باشه.
چون به خیلی تنظیمات و پارامترهای خارجی دیگر این مسئله وابسته هست.
مثلا در شرایطی ممکنه بشه با برنامه های CGI دسترسی پیدا کرد (حالا توضیح و جزییاتش رو فعلا بخاطر کوتاه شدن مطلب و اینکه خودمم وقت و حوصله ندارم نمیگم، ولی اونی که به ساختار سرورهای لینوکس وارد باشه یخورده فکر کنه میفهمه چی میگم).
از یک طرف دیگه مثلا باید تنظیم open_basedir رو هم چک کنی که مشکلی نداشته باشه.

من در زمینه ای گفتم که برنامه نویسان در هاست اشتراکی و محل ذخیره شدن فایل سشن مشترک استفاده میکنند ، در این زمان میشه با تغییر مسیر مشکل رو حل کرد . البته مسایلی همچون دسترسی کاربران سرور به هر دایرکتوری و ... جزو وظایف مدیر سرور هست که برنامه نویس هم قبل از راه اندازی سایت حتما باید بررسی خودش رو انجام بده .


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


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


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

ضمنا با استفاده از دیتابیس بجای سشن، برنامه میتونه به راحتی و بصورت خودکار نصب و کانفیگ بشه و نیاز به دخالت دستی کاربر نباشه. این هم از نظر یوزرفرندلی خیلی بهتره و هم از نظر امنیتی (چون کاربر ممکنه به علل مختلف اون کار رو درست انجام نده).

بله موافقم .


اطلاعات مهم مثل اکانت یعنی چی دقیقا؟
منظورم این بود که در یه چنین سایتهایی فقط به کوکی اتکا نمیکنن و از روشهای دیگه ای هم استفاده میکنند . منظورم از اکانت همون اطلاعات کاربری بود .


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

[eshpilen]

اتفاقا من خودم برای یکی از پروژه هام از این روش استفاده کردم و اصلا سشن رو گذاشتم کنار اما نکته ای وجود داره ، زمانیکه به صورت درونی در php یه چنین قابلیتی وجود داره چرا ما باید بیایم و مجددا یه چنین چیزی رو طراحی کنیم . ( فقط به این دلیل که php تنظیمات زیادی داره و شاید چندتاییش از قلم بیافته و ... ، که نمیشه دلیل . ما باید تا اونجایی که پروژه واسمون مهمه امنیت رو تامین کنیم )
چون این قابلیت در PHP خیلی بد طراحی شده و مشکلات بزرگی داره:
- عدم امکان اتکا به امن بودن درحالت پیشفرض.
- تنظیمات و ترکیبات زیادی که باید برای امن بودن چک/تنظیم بشن.
- وجود عوامل خارج از PHP در این بین که ریسک رو بالا میبره و کار چک و تنظیم خودکار اونا رو دشوار یا غیرممکن میکنه.

البته من نمیگم از سشن کلا استفاده نکنیم. بلکه میگم برای کاربردهای امنیتی و یا کاربردهایی که نیاز به امکانات و انعطافی درحد سشن ندارن و میتونیم خودمون نسبتا براحتی سیستمی با کوکی و دیتابیس طراحی و پیاده سازی کنیم، از سشن استفاده نکنیم (حتی الامکان).

از سشن میتونیم در کاربردهای کمتر امنیتی و موقتی مثل ذخیرهء هش کپچای فرمها یا سبد خرید استفاده کنیم. هرچند من ترجیح میدم حتی در این کاربردها حداقل از رمزگذاری محتویات سشن استفاده کنم (البته یک راه جایگزین هم همون تنظیم پارامترهای سشن هست، ولی دردسرش زیاده و شک توش زیاد هست. من ترجیح میدم همه چیز در درون خود برنامه و خودکار باشه و بدون ابهام و تردید).


قبول دارم که میشه ، اما منابع زیادتری نسبت به سشن میخواد ، مثل رمزشدن اطلاعاتی که در کوکی قرار ذخیره بشه یا رمزگشایی و یا حتی بررسی صحت اطلاعات و خیلی چیزای دیگه که همشون استفاده از منابع رو افزایش میده . در صورتیکه همه این موارد رو میشه در مورد سشن آی دی اعمال کرد و اونم فقط یکبار در هر درخواست.هرچیزی هزینه داره. امنیت هم هزینه داره.
طبیعتا برنامهء حرفه ای و بی نقص پیچیده تر و حجیم تر خواهد شد (و احتمالا کلی منابع/پردازش بیشتر مصرف میکنه).
ضمنا من فقط مثال زدم که بگم میشه (اگر نیاز بشه).
من خودم از رمزنگاری محتویات کوکی تاحالا استفاده نکردم. بیشتر کاربردها نیازی به رمزنگاری برگشت پذیر ندارن. ولی یک وقت شاید جایی هم نیاز شد. بهرحال نباید از پردازش بیشتر بترسیم. بلکه بهتره از ساده ترین و سریعترین روشی که بی نقصه استفاده کنیم. چون پیشاپیش نباید مشکلی رو که وجود نداره موجود فرض کرد. پرفورمنس مهمه و میتونه مشکل بشه، اما امنیت هم مهمه و میتونه مشکل بشه، و وقت و انرژی برنامه نویس هم مهمه و نباید بی دلیل خرجش کرد، خوانایی و کوتاهی و سادگی کد هم همینطور مهمه.
خلاصه پرفورمنس همه چیز یا مهمترین چیز نیست. امروزه خیلی پارامترهای دیگر همونقدر یا بیشتر اهمیت دارن و بیشتر هم با مشکل مواجه میشه. از طرف دیگر توان و منابع سخت افزاری افزایش زیادی پیدا کرده نسبت به گذشته و در خیلی کاربردها مشکل جدی ای با پرفورمنس پیش نخواهد آمد، و بنابراین نباید دقیقا با همون ذهنیت و روش و محدودیت هایی که برنامه نویسان در قدیم تر کار میکردن کار کنیم (اونا مجبور بودن چون اون زمان منابع سخت افزار خیلی محدودتر/گرانتر بودن؛ الان چنین کاری مگر درصورت نیاز واقعی منطقی و هنر نیست - برخلاف ذهنیت و رفتار افراطی ای که هنوز مثل ویروس در بین برنامه نویسان وجود داره و مدام تکثیر میشه).
مثلا من در برنامهء خودم خیلی ریلکس کار کردم در این زمینه. حتی بخشها و عملیات به ظاهر سادش پر از پردازش و شرط و الگوریتم های مفصله. مشکلی رو هم با پرفورمنس قبول ندارم، مگر وقتیکه بصورت عملی دیده و مشکل جدی بشه. البته من اصولا این سیستم رو برای مقیاس بزرگ طراحی نکردم، بلکه برای مقیاس کوچک و شاید تا متوسط هست (که فکر میکنم بهرحال بقدر کافی کاربرد براش هست). کوچک اما مستحکم و امن و کامل و دقیق! من اینطور برنامه نوشتن رو ترجیح میدم تا اینکه یه برنامه درست کنیم که سرعتش زیاده اما از نظر استحکام و کمال منطق و الگوریتم و امنیت و امکانات ضعف و نقص زیاد داره.


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

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

البته من نمیگم که از «امنیت از طریق تیرگی» هیچوقت استفاده نکنیم و به هیچ وجه نمیتونه مفید یا حتی لازم باشه (حداقل در بعضی شرایط/کاربردها). بلکه نکتهء مهم اینه که سیستم باید در عمق خودش تماما بر امنیت از طریق تیرگی اتکا نکرده باشه، و بر الگوریتم ها و روشهای اصولی متکی باشه. یعنی از نظر حرفه ای معمولا ابتدا برنامه رو با فرض و قالب عدم وجود امنیت از طریق تیرگی طراحی میکنیم، یعنی تاجایی که میتونیم اون رو کامل و قوی بصورت اصولی طراحی میکنیم، و تازه بعد از این مرحله ممکنه برای یک لایه امنیت افزوده و احتیاط بیشتر یا درصورت نیاز (در موارد خاص و کمی که روشهای اصولی تر ممکن یا کافی نیستن)، امنیت از طریق تیرگی رو هم به سیستم اضافه کنیم.
بطور مثال شما میخواید یک اطلاعاتی رو در کوکی ذخیره کنید بدون اینکه کاربر بتونه اون رو بخونه یا دستکاری کنه.
یک روش اصولی اینه: AES + HMAC. البته با یک کلید بقدر کافی امن (داستان خودش رو داره).
یعنی باید از الگوریتمهای حرفه ای استاندارد استفاده کنید، نه روشهای من درآوردی یا اتکا بر اینکه کاربر از اون دیتا و ساختارش سردرنمیاره و سورس برنامه رو نداره و نهایت یخورده مخدوش کنید و ترفند زدن رو بکار ببرید که کاربر رو گیج و گمراه کنید.

بنظر منکه این الگوریتم ها کافی هستن. اما حالا شما میگی نه من شک دارم یا میخوام بیشتر محکم کاری کنم.
خب شما میتونی خروجی اون AES + HMAC رو مستقیم ندی دست/سمت کاربر. میتونی خروجی رو با همون روشهای من درآوردی یا حقه های خودت دستکاری کنی.

این میشه یک لایهء بیشتر و افزودن امنیت از طریق تیرگی روی امنیت بدون استفاده از تیرگی.
این مشکلی نداره. چون سیستم شما الان چیزی کمتر از امنیت اصولی و حرفه ای نداره، بلکه چیزی بیشتر داره. نهایتش روش شما اگر شکسته بشه، تازه طرف با AES + HMAC مواجه میشه که در کل دنیا کسی تاحالا نتونسته بشکنش. حالا بعضیا میگن ممکنه بعضی نوابغ و فرضا سازمانهای جاسوسی توان شکست این الگوریتم ها رو داشته باشن، اما اسناد/دلایلی در این باب وجود نداشته تاحالا (بلکه برای عکسش دلایل و اسنادی هست).

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

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

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

[eshpilen]

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

بعدم من یکی که اصلا حال نمیکنم با نوشتن برنامه های کشکی. چون نه لذتی و نه یادگیری چندانی داره برام. دوست دارم توانم در بالاترین حدود باشه. در سطح برترین های دنیا. هدف و تلاشم این بوده تاحالا، وگرنه به نصف این دانش و بینش و توانی هم که رسیدم نمیرسیدم.

[mtchabok]

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

[eshpilen]

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

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

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

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

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

من خواستم از این دانش و بینش و توان خودم استفاده کنم و یه کار برجسته از نظر امنیتی درست کنم. روی پروژهء خودم.
حالا از من میپرسی، خب شما مجبور نیستی این کار رو بکنی، و بهت برنخوره، اصلا وقتی اون مطالعات و تخصص رو نداری، نمیتونی یک سیستم حرفه ای بی نقص درست کنی از این نظر. بهتره هدفت درحدی باشه که تخصص و توانش رو داری. چون اگر هدفت بالاتر باشه، اصولیش اینه که اول بری سراغ یادگیری مورد نیازش.

شاید شنیدی که میگن امنیت مثل یک زنجیره، و استحکام اون برابر با استحکام ضعیف ترین حلقهء اونه.

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


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

[eshpilen]

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

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

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

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

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

یک متخصص رمزنگاری بخواد برنامه بنویسه داستان همین میشه که واسه من شده.
یعنی یک چیزی که برای دیگران تنها یک جزء معمولی و کوچک یا نه چندان بزرگ از یک سیستم ، مثلا یک نرم افزار فروم یا وبلاگ/CMS، هست، واسش میشه یک پروژهء مهم و بزرگ و پیچیده با حتی 10 برابر حجم و پیچیدگی کد.