نکات امنیتی در کد نویسی php : بخش اول

امنیت در صفحات php

متین کهریزی  ،  ۱۳۹۷/۰۹/۰۸ نکات امنیتی در کد نویسی 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) در صورتی که استفاده نمی‌کنید، غیرفعال شده است . بزودی با بخش دوم در خدمتتون هستیم .