لیست مواردی که برای امنیت برنامه php لازم است چک شود
موارد زیر، نکات امنیتی هستند که لازم است قبل از شروع به فعالیت سایتی که با زبان PHP نوشته‌اید، چک شوند تا خیالی آسوده‌تر داشته باشید که موردی از قلم نیفتاده است. این موارد بر مبنای مطالعات شخصی و طبق موارد لیست شده در اینجا آورده شده است:
نکات مقدماتی
- کلمات عبور قوی انتخاب شده‌اند
- رمزها به صورت امن ذخیره شده‌اند
- register_globals و Magic quotes غیرفعال شده است
- display_errors خاموش شده است
- سرور از نظر فیزیکی امن است
ورودی‌ها
- $_GET و $_POST و $_COOKIE و $_REQUEST آلوده فرض شده است
- اعتبار ورودی‌ها سنجیده شده است
- متوجه هستم که تنها برخی موارد از آرایه $_SERVER و $_ENV پاک هستند
- کاراکتر «بک اسلش صفر» (کاراکتر نول) در ورودی نادیده گرفته شده است و سایر کاراکترهای نامرئی و خاص لحاظ شده است
- $_SERVER['PHP_SELF'] قبل از چاپ اسکیپ شده است
- طول ورودی‌ها محدود شده است
- در ورودی‌های عددی، اعداد بسیار بزرگ، اعداد با نمایش علمی (مثل 1e9 که توسط PHP تفسیر می‌شود) و صفر و اعداد منفی درنظر گرفته شده است
- داده خروجی تحلیل و پالایش شده است تا خطر حملاتی چون xss دفع شود
- در صورتی قرار است کاربر css ی را وارد کند، لازم است:
- ویژگی absolute مورد بررسی دقیق قرار گیرد
- CSS Escape Sequences ها در نظر گرفته شده‌اند
- جاوا اسکریپت در css غیرفعال شده است (expressions, behaviors, bindings)
- عدم واکشی css خارجی با دستور @import بررسی شده است
- URLها تحلیل و با پروتکل‌های ناخواسته و همچنین ناشناخته مقابله شده است
- پلاگین‌های Embed شده (مانند فلش پلیر) از نظر اجرای js یا هر گونه کد مخربی تست و محدود شده‌اند
توضیح آنکه، گاهی برخی افراد از فلش‌های آماده و کامپایل شده در سایت خود خود استفاده می‌کنند و سایت‌شان از این طریق مورد نفوذ قرار می‌گیرد.
ذکر این تذکر نیز لازم است که منظور از پلاگین‌های Embed شده فقط فلش نیست و هر گونه کد خارجی (جاوا، جاوا اسکریپت و ...) را شامل می‌شود. - از یک انکدینگ امن و ثابت در برنامه استفاده شده و ورودی‌ها بر اساس آن اعتبارسنجی شده‌اند
توضیح آنکه، گاهی یک عبارت در انکدینگ زبان فارسی ممکن است امن باشد اما از نظر انکدینگ utf-8 امن نباشد...
آپلود فایل از کاربر به سرور
- نوع فایل بر اساس mime_type اعتبار سنجی شده و فقط به پسوند آن بسنده نشده است
همچنین این نکته لحاظ شده که فایلی با mime_type تصویری gif باز هم ممکن است دارای اطلاعات غیرمترقبه باشد - حجم فضای خالی سرور، حجم فایل آپلودی، بیشتر نبودن حجم از حد مجاز بررسی شده است
- محتوای فایل تست شده است و در صورت نیاز با یک آنتی ویروس و اسکنر بررسی دقیق شده است
- اگر فایل آپلود شده یک فایل html است، حتما به صورتی امن نمایش داده شده است
- فایل‌های آپلود شده به پوشه قابل دسترسی مستقیم از طریق url منتقل نشده است
- فایل‌های آپلود شده، include نشده‌اند
- فایل‌های آپلود شده به وسیله سرآمد (header) امن Content-Disposition سرو شده‌اند (تا به عنوان فایل ضمیمه جهت دانلود ارائه شوند و تحت دامنه شما اجرا نشوند)
- برنامه، سرآیند X-Content-Type-Options: nosniff را ارسال کرده است تا براوزر با توجه به محتوا mime_type را تعیین نکند و برخلاف میل شما آن را احتمالا اجرا کند
- تا زمانی که ضرورتی درکار نبود، برنامه از ارسال فایل با هدر‌های application/octet-stream, application/unknown, plain/text اجتناب ورزیده است
ارسال فایل از سرور به کاربر
- ورودی کاربر، مستقیما در مسیر فایل سرو شونده قرار نگرفته (مثلا کاراکتر /.. که مربوط پیمایش مسیر است، ممنوع شده و کاراکتر نول حذف شده است. همچنین مراقب کاراکتر دو نقطه : بوده‌اید)
- دسترسی به فایل‌ها، صرفا با مخفی کردن مسیر آنها انجام نشده است
- فایل‌های راه دور (از آدرس هاستی دیگر) اینکلود نشده است
پایگاه داده
- جهت پیشگیری از حملات sql injection ، داده‌های ارسال شده به دیتابیس، به یکی از روش‌های زیر ایمن شده‌اند و از تابع غیراستاندارد addslashes استفاده نشده است
- اسکیپ (escape) شدن با توابع mysql_real_escape_string یا استفاده از توابع مشابه در صورت استفاده از PDO یا MySQLi و ...
- پارامتری کردن (parameterized) و درج نکردن مستقیم متغیرها در کوئری
- عبارات از پیش آماده شده (prepared statements)
- دسترسی و امتیازات (privileges) در حد لازم داده شده نه بیشتر
- دسترسی از راه دور (Remote connections) در صورتی که استفاده نمی‌کنید، غیرفعال شده است
هویت سنجی کاربر
- به کاربر اجازه انتخاب پسورد ضعیف داده نشده است
- برای تشخیص روبات‌ها فکر موثری شده است (کپچا یا تاخیر زمانی با توجه به یوزر و ...)
- برای اسنیف نشدن پسورد ورودی کاربر توسط دیگران، از SSL استفاده شده است
- پسوردها در کوکی ذخیره نشده است
- پسوردها به صورتی امن هش شده است
- از md5 ساده استفاده نشده است و بجای آن از توابع قوی‌تری چون hash_hmac یا crypt با rounds مناسب استفاده نمایید
- برای هر کاربر از salt مجزا استفاده شده است
- فرم ریکاوری اکانت، ایمیل مخاطب را آشکار نمی‌کند
- صفحاتی که به صرف فراخوانی ایمیل ارسال می‌کنند، بایکوت شده‌اند
سشن
- سشن فقط از کوکی برای ذخیره خود استفاده می‌کند (session.use_only_cookies فعال شده است)
- در صورت logout اطلاعات سشن نابود شده است
- در جاهایی که سطح دسترسی تغییر کرده، سشن دوباره تولید شده است
- محل پیش‌فرض ذخیره سشن در سرور اشتراکی عوض شده است
اجزای برنامه و صفحات سایت
- از حملات CSRF به وسیله token یا key جلوگیری شده
- به آدرس ارجاع (Referrer) اعتماد و اتکاء نشده
- از متد POST برای ارسال اطلاعات استفاده شده نه GET
- جلوگیری از نمایش سایت در فریم به وسیله js ارزش امنیتی ندارد و علاوه بر آن لازم است از هدر X-Frame-Options برای پیشگیری از آن استفاده شود
نکاتی که درباره هاست اشتراکی باید مراعات شود
- استفاده از هاست اشتراکی ایمن شده در مقابل دسترسی سایر مشتریان آن هاست به فایل‌های یکدیگر
- پوشه ذخیره سشن و آپلود فایل مشترک و قابل دسترس برای سایر مشتریان نیست
موارد متفرقه که لازم است چک شوند
- برای تولید کدهای رندوم (مثل کد فعال‌سازی حساب کاربر) از روش امنی استفاده شده است. مثلا در صورتی که از تابع rand/mt_rand استفاده شده، لازم است Suhosin نیز نصب شده باشد
- مواردی که منابع زیادی از سرور مصرف می‌کنند (مثل گرفتن اطلاعات از سرویس‌های دیگر) محدود و به دقت استفاده شده
- از الگوریتم رمزنگاری شخصی استفاده نشده
- آرگومان‌های ارسالی به دستورات و برنامه‌های سیستمی اعتبارسنجی شده
- تمامی تغییر مسیر (redirect) های داخلی و خارجی امن شده‌اند
- در خصوص نمایش کدهای php در صورت اختلال در سرور یا تنظیمات آن، توجه و پیش‌بینی لازم انجام شده است
- فایل‌های حساس و کانفیگ، خارج از ناحیه قابل به وسیله آدرس وب قرار داده شده است
سایر مطالب مربوط به بحث امنیت و ارتقاء آن
نهایتا دقت داشته باشید که امنیت امری نسبی است و لازم است با مطالعه پیوسته مطالب مربوطه، اطلاعات خود در این زمینه را به روز نگه دارید...
منبع
