گیک فارسی

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

وقتی توی سایت از قابلیت File Upload استفاده میکنیم باید چه نکات امنیتی را رعایت کنیم؟

نویسنده:
16 می 15

خیلی از مواقع پیش میاد که ما توی وب سایتی که توسعه میدیم نیازمند ارسال فایل بواسطه کاربر هستیم. مثل مواقعی که نیاز داریم کاربر عکس پروفایل یا رزومه‌اش را ارسال کنه. اگرچه پروسه ارسال فایل کلاً موضوع پیچیده‌ای نیست اما یکسری مسائل امنیتی هست که حتماً باید رعایت بشه.

ارسال فایل

۱ – یکی از مواردی که اهمیت داره این هست که فایل را با نام اصلیش ذخیره نکنیم و اگه در آینده نیاز به بازیابی فایل با همون نام اصلیش هست فقط کافیه در زمان ذخیره فایل نامش را توی پایگاه داده نگهداری کنیم. نام فایل جدید میتونه یک MD5 HASH یا حتی شماره رکورد با اندکی تغییرات منطقی باشه.

۲ – بهتره فایل را خارج از Document Root ذخیره کنیم. در این صورت هیچ‌کس امکان دسترسی از طریق وب به مسیر ذخیره شده را نداره.

۳ – حتماً توی برنامتون برای فایل‌ها محدودیت حجم بگذارین ، قطعاً وقتی یک عکس پروفایل در فرمت JPG و سایز ۱۲۰×۱۰۰ در DPI ۷۲ مورد نیاز هست در نتیجه حجم ارسالی نباید مثلاً از ۱۰۰ کیلوبایت بیشتر بشه.

۴ – علاوه بر محدودیت حجم حتماً محدودیت تعداد فایل در یک Request را از طریق max_file_uploads اعمال کنید تا از حملات DOS در امان باشین.

۵ – توجه داشته باشین که پسوند فایل‌ها نشون دهنده این نیستند که فایل واقعاً کارایی مرتبط با پسوندش را داره. یک فایل ممکنه با پسوند jpg ارسال بشه ولی واقعاً یک فایل عکس نباشه و سمت سرور یا کلاینت بتونه مشکلات امنیتی به وجود بیاره. شما حتما باید با استفاده از ابزار و توابع موجود بررسی عمیق‌تر از پسوند فایل انجام بدین. مثلاً در مورد فایل‌های عکس میتونین با استفاده از تابع getimagesize اطلاعات بیشتری را نسبت به فایل بدست بیارین و کاملاً مطمئن بشین اون فایل یک عکسه.

۶ – متأسفانه با وجود بررسی پسوند و Header و استفاده از ابزار شناسایی دیگه باز هم امکان داره فایل مورد نظر آلوده به Bug ها و Exploit های فایل‌های مختلف از جمله همون عکس‌ها باشه.در این رابطه بهترین کار این هست که از طریق یک نرم‌افزار Malware Scan بررسی های بیشتری انجام بدیم. این کار را میشه با ارسال فایل (با استفاده از CURL) به سایت‌های Malware Scan آنلاین مثل virustotal.com انجام داد ، خودتون هم میتونید میزبانی اختصاصی بگیرین و نرم‌افزار مورد نظرتون را نصب کنید و از طریق ابزار اون فایل‌ها را بررسی کنید.

۷ – پس از Upload فایل روی سرور حتماً سطح دسترسی به فایل را کنترل کنید. البته مدیر سیستم عموما موارد امنیتی را انجام داده و مانع از دسترسی های غیر ضروری مثل اجرایی بودن شده اما شما هم میتونید این دسترسی ها را کنترل کنید. این کنترل هم میتونه روی خود فایل باشه یا روی پوشه ای که فایل در اون ذخیره میشه.

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

امن کردن سرویس SSH در میزبانی(Host) های اختصاصی VPS یا Dedicated

نویسنده:
8 ژانویه 15

پس از خرید میزبانی اختصاصی ، اولین قدم برای مدیریت میزبانی اتصال به آن از طریق SSH یا همون Secure Shell هستش. اولین قدم برای امن کردن میزبانی هم به همین سرویس ssh بر میگرده.

به صورت پیش‌فرض برای ورود به سیستم عامل میزبان از نام کاربری root و کلمه عبورش استفاده میکنیم. اما استفاده از کلمه عبور اون هم در شرایطی که معمولاً همین کلمه های عبور به دلیل ضعفشون باعث هک شدن سرویس ما از طریق Brute Force (حدس زدن کلمه عبور از طریق هکر با استفاده از ربات ها) می‌شوند اصلاً عقلانی نیست.
بهترین راه برای امن کردن ssh استفاده از RSA key Pair هست. برای این کار کافیه روی سیستم خودتون از دستور زیر استفاده کنید :

ssh-keygen -t rsa

پس از زدن این دستور ، دو تا سؤال از شما میپرسه ، یکی اینکه کجا Private Key را ذخیره کنه که به نظر من بهتره توی ssh./~ ذخیره بشه و سوال دوم در مورد Passphrase هست که تعیین کردنش باعث میشه برای استفاده از اون Private Key به Passphrase نیاز باشه که حُسنش اینه کسی اگه فایل Private Key را داشته باشه (البته اهمیت RSA Key Pair اینه که کسی این کلید اختصاصی را نداشته باشه!) نیاز به Passphrase داشته باشه. و بدیش اینه در زمان استفاده در ارتباط با ssh سیستم از شما این Passphrase را میپرسه.

وقتی سؤالات را پاسخ دادین دو تا فایل در پوشه ای که تعیین کردیم ایجاد میشه ، یکی به صورت پیش‌فرض id_rsa و دیگری id_rsa.pub (البته اگه نام دیگری میگذاشتین نامش متفاوت بود). این فایل pub همون کلید عمومی هست که باید روی سِرور شما قرار بگیره. پس با استفاده از دستور زیر این کار را انجام میدیم :

ssh-copy-id root@host-ip-address

ssh از شما کلمه عبور root را میپرسه و بعدش پیامی مبنی بر موفقیت کار نشون میده و از شما میخواد بررسی کنید که همه چیز توی فایل ssh/authorized_keys./~ درسته.حالا بدون استفاده از کلمه عبور میتونیم از طریق ssh وارد سِرور بشیم.

یک قدم دیگه از کار هنوز باقی مونده ، ابتدا باید برای ssh تعیین کنیم که اجازه ورود با کاربر root را از طریق کلمه عبور نده و به طور کلی ورود از طریق کلمه عبور را ببندیم. پس توی فایلetc/ssh/sshd_config/ مقادیر زیر را تغییر میدیم :

PermitRootLogin without-password
PasswordAuthentication no

توجه: یادتون باشه تا مطمئن نشدین ورود از طریق RSA کار میکنه این تغییرات بالا را انجام ندین.

در آخر هم با دستور زیر ssh را restart میکنیم :

sudo service ssh restart

آیا session ها امن هستند و میتوان از آن‌ها با خیال راحت استفاده کرد ؟

نویسنده:
14 آگوست 14

من با این سؤال خیلی جا ها روبرو شدم و حتی خوندم که بعضی از همکاران به دوستان برنامه نویس تازه کار میگویند session ها امن نیستند و نباید از آن‌ها استفاده کرد. خوب اینجاست که مغز آدم سوت میکشه که چرا هر کسی میاد هر حرفی را دوست داشت اونم به یک تازه کار میزنه ؟ من سعی میکنم هر چی در مورد session ها میدونم توضیح بدم تا شاید دوستان من ازش استفاده کنند.

به طور کلی ما برای بازیابی ، پروسس و انجام محاسبات مرتبط با فرد یا افرادی که در حال بازدید از سایت ما هستند از session ها استفاده میکنیم. یکی از مهمترین استفاده هاش هم در زمان پیاده سازی Login و کلاً Authentication هست. امنیت session ها را باید در سمت client و server بررسی کنیم.

برای اینکه کاربرای تازه کار که شاید متأسفانه از بحث‌های امنیتی لذت نبرند هم این مطلب کمکشون کنه توصیه میکنم به آخر مطلب بروند و قسمت راه حل را بخونند. اما توضیحات فنی تر :

در سمت client تنها اثری که از session وجود داره فایل کوکی هست که مشخص کننده session برای سمت سرور هستش. پس در‌ واقع اگه کسی بتونه محتوای این cookie را بدست بیاره در‌ واقع session hijacking انجام داده و میتونه خودش را جای قربانی جا بزنه ! این کار به سه روش معمول انجام میشه ،‌ روش اول session fixation هست که در‌ واقع هکر میاد و با ارسال یک لینک به قربانی از طریق POST یا GET (بعضی زبان‌ها هم از GET و هم POST برای ست کردن session استفاده میکنند) session مورد نظرش را برای قربانی ست میکنه و به حساب شخص دسترسی پیدا میکنه. روش دوم که بهش میگن session sidejacking در‌ واقع همون packet sniffing هست و در‌واقع با بررسی packet های رد و بدل شده cookie مورد نظر و در نهایت session لو میره. در روش سوم هم از طریق Cross Site Scripting یا همون XSS هکر میتونه به session ها دسترسی پیدا کنه.

اما در سمت server هم مشکلات امنیتی در زمان استفاده از session وجود داره. این مشکلات مربوط به هاست های اشتراکی میشه و در‌ واقع همسایه های ما میتونند برامون دردسر ساز بشوند. مثلاً من متوجه میشم قربانی از کجا هاست میگیره و با گرفتن هاست از اون شرکت شروع به سوء‌ استفاده میکنم.

در‌ واقع به صورت پیش‌ فرض همه session ها توی پوشه tmp/ ذخیره می‌شوند و این فایل‌ها متعلق به کاربری هست که web server داره تحتش اجرا میشه ، از اونجا که همه سایت‌ها با همین کاربر به این پوشه و فایل‌ها دسترسی دارند پس میتونند هر بلایی سر این فایل‌ها بیارند و کلاً امنیت سایت شما در مورد session ها از بین میره. راه حل‌های متفاوتی برای مقابله هست که بهترینش استفاده از FastCGI یا suPHP به منظور اختصاص یک کاربر برای هر سایت هستش که در این حالت دیگه کاربر ها نمیتونند به فایل‌های session هم دیگه دسترسی داشته باشند.

راه حل : برای جلوگیری از session hijacking در گام اول باید مانع از ست شدن session از طریق GET و POST بشین.
توجه : به صورت پیش‌فرض یک HOST خوب مانع از این کار شده ولی برای اطمینان دو خط زیر را در فایل htaccess. توی root قرار بدین :

php_flag session.use_trans_sid off
php_flag session.use_only_cookies on

در گام دوم باید هر زمانی که نوع دسترسی کاربر تغییر میکنه ما هم session id جدید ایجاد کنیم. مثلاً بعد از login کاربر session id جدید ایجاد کنیم تا اگه session fixation اتفاق افتاده بی اثر بشه.

در گام سوم برای جلوگیری از session sniffing تنها راه استفاده از SSL هستش.

در مورد مشکل امنیتی server باید بگم بهتره از هاست های معتبر استفاده کنین که براتون از این نظر مشکلی وجود نداشته باشه ولی اگه مطمئن نیستین من سه تا راه را پیشنهاد میکنم که به الویت اینها هستند :

– PHP به شما این امکان را میده که کنترل کنین session چطوری handle بشه. در‌واقع شما میتونید به جای اینکه خود PHP بیاد و session های شما را مدیریت کنه با استفاده از session_set_save_handler مدیریت session ها را بدست بگیرین و به جای استفاده از فایل سیستم اونها را توی database یا حافظه (از طریق Memcache) ذخیره و بازیابی کنید.

– PHP به شما این امکان را میده که از طریق session_save_path مسیر مربوط به ذخیره فایل‌های session را تغییر بدین و امنیت پوشه مربوط مربوط به شما و در اختیار شما خواهد بود.

– کار دیگه ای که میتونید انجام بدین encrypt کردن محتوای session ها هسش تا اگه هم لو رفتند قابل استفاده نباشن.

توجه : تمام مطالب بالا تجربیات و مطالعات شخصی خود من هستش و من هیچ مسئولیتی در صورت بروز هر مشکلی به خاطر استفاده از اونها به عهده ندارم و با مسئولیت خودتون ازش استفاده کنین.