ما در این مقاله می خواهیم درباره موارد امنیتی در لاراول صحبت کنیم . لاراول با این که یکی از امن ترین فریمورک های لاراول می باشد، اما شما با یک چیز بسیار کوجیک یا بهتر بگم با در نظر نگرفتن یک سری موارد می توانید یک نقطه نفوذ و یک باگ امنیتی در آن ایجاد کنید با اینکه ممکن است شما اصلا متوجه آن نشوید و برنامه شما به درستی کار کند.
از نظر من هر برنامه نویسی که با زبان PHP کد نویسی می کند نیاز است که با موارد تست نفوذ و هک و امنیت آشناییت داشته باشد تا همچین مشکلاتی براش پیش نیاد.
خب پس بیایید به این موارد بپردازیم و 10 مورد از رایج ترین مشکلات امنیتی را که در لاراول وجود دارد، بررسی کنیم.
10# اعتبارسنجی ورودی ناکافی باشد
یافتن اعتبار سنجی ورودی ناکافی که در کنترلرها پراکنده شده است معمول است. اغلب یک اعتبارسنجی وجود دارد که کلیدهای ورودی مورد انتظار را بررسی می کند (اگرچه گاهی اوقات حتی چنین نیست)، و از()request()->all بلافاصله پس از آن استفاده می شود و داده ها را در model ها، رویدادها و غیره ارسال می کند. بدون اعتبار سنجی مناسب، تزریق مقادیر مخرب برای ایجاد خطا، حملات تزریق و موارد دیگر آسان است.
به عنوان مثال، دفاع انبوه انتساب معمول برای این مورد به عنوان fillable$ در model در نظر گرفته می شود، اما اگر fillable$ باشد admin برای ادمین پنل باشد، هر کسی می تواند یک کاربر ادمین جدید از صفحه ثبت نام ایجاد کند. (و این یک مثال واقعی است.)
برای مثال:
class User extends Model
{
protected $fillable = ['name', 'email'];
}
در مرحله بعد، هنگام ایجاد یا به روز رسانی مدل، فقط ویژگی های مجاز را می توان پر کرد.
$input = [
'name' => 'Bilbo Baggins',
'email' => 'bilbo@example.com',
'admin' => true
];
$user = User::create($input);
// $user->name -> 'Bilbo Baggins'
// $user->email -> 'bilbo@example.com'
// $user->admin -> false
در مثال بالا admin = true هنگام ایجاد مودل User نادیده گرفته می‌شود و در برابر یک سوءاستفاده از تخصیص انبوه برای افزایش امتیازات کاربر جدید ایجاد شده محافظت می‌کند.
و اینجاست که بسیاری از افراد از یادگیری در مورد آسیب‌پذیری‌های تخصیص انبوه دست می‌کشند و تصور می‌کنند که آنها تحت پوشش هستند.
بنظر می رسد که fillable$ محافظت کمتر، یا احتمالاً حتی اختیاری در برابر تخصیص انبوه است. اگر می توانید استفاده کنید عالی است، اما ضروری نیست و قطعا برای اولین انتخاب نباشد.
در واقع، من غالباً با استفاده از ;[]=guarded$ یا حتی ()Model::unguard در کل برنامه در AppServiceProvider اجازه انتساب انبوه را در تمام فیلدهای یک مدل می دهم. هر چقدر هم که بحث برانگیز باشد، متوجه می شوم که fillable$ بیشتر از اینکه از من محافظت کند، سر راهم قرار می گیرد. غیرفعال کردن حفاظت در واقع کد را تمیزتر و قابل نگهداری تر می کند.
9# عدم وجود امنیت زیرمنبع (SRI)
عدم وجود امنیت زیرمنبع (SRI) یک لایه حفاظتی در برابر اسکریپت های شخص ثالث آسیب دیده که بر سایت شما تأثیر می گذارند اضافه می کند، و به نظر من به طور جدی مورد استفاده قرار نمی گیرد. خطر این است که اسکریپت ها و استایل های شخص ثالث را می توان تغییر داد تا شامل کدهای مخرب مانند Magecart، keylogger، cryptominers و غیره شود. اگر اسکریپت در معرض خطر را در سایت خود دارید، کاربران شما در معرض خطر هستند حتی اگر برنامه شما نبود به خطر افتاد.
SRI با تعریف یک هش یکپارچگی روی هر تگ <script> و <style> کار می‌کند که یک منبع شخص ثالث را بارگیری می‌کند، که مرورگر قبل از بارگیری منبع آن را تأیید می‌کند. اگر هش مطابقت نداشته باشد، منبع مسدود می شود.
8# محدودیت نرخ ناکافی
محدود کردن نرخ برای محدود کردن حملات ربات و جلوگیری از سوء استفاده ضروری است، و با این حال یافتن نقاط پایانی که فاقد محدودیت نرخ هستند معمول است. هنگامی که صحبت از مسیرهایی مانند احراز هویت یا جستجو برای اطلاعات حساس مانند وجود حساب های کاربری می شود، این موضوع بسیار نگران کننده است. به عنوان مثال، من متوجه شدم که مسیر احراز هویت چند عاملی مبتنی بر پیامک (MFA) فاقد محدودیت نرخ است - و کد 6 رقمی در عرض 5 دقیقه منقضی شده است. بی‌اهمیت بود که یک کد معتبر را به زور وارد کنم.
با این حال، محدود کردن نرخ می تواند مشکل باشد - آیا آن را بر اساس IP یا نام کاربری یا هر دو قرار می دهید؟ یا چیز دیگری؟ این بستگی به مسیر دارد، اما قطعا داشتن برخی از آنها بهتر از هیچ است. پس از آن غافل نشوید!
7# اسکریپت های بین سایتی (XSS)
XSS معمولاً در یک مسیر از طریق یک ورودی منفرد ظاهر می‌شود، به دلیل چیزی مانند Markdown (که به طور پیش‌فرض ناامن است) یا فرمت‌بندی محدود که دچار یک حلقه گریز از ایمنی بوده است، ظاهر می‌شود.
برای مثال:
use Illuminate\Support\Str;
>>> Str::markdown('Inject: <script>alert("Hello XSS!");</script>', [
'html_input' => 'strip',
'allow_unsafe_links' => false,
]);
// <p>Inject: alert("Hello XSS!");</p>
بهترین استراتژی در اینجا این است که به دنبال آن تگ‌های خطرناکی مانند {!!… !!} و دستورات خام HTML مانند v-html باشید، و اطمینان حاصل کنید که همه کاربردها به درستی اسکیپ شده‌اند، و ویژگی‌های امنیتی Markdown فعال شده‌اند و HTML کاربران تصفیه شده باشد. من توصیه می‌کنم که از این تگ‌ها در حد امکان خودداری کرده و فقط در صورت لزوم از آنها استفاده کنید، تا هر کاربردی که وجود دارد به راحتی شناسایی و بازبینی شود.
6# وابستگی های قدیمی و آسیب پذیر
یکی دیگر از موارد امنیتی آخرین باری که composer/npm به روز رسانی را اجرا کردید کی بود؟
به تعویق انداختن به‌روزرسانی‌های وابستگی، جلوگیری از خرابی و پایدار نگه داشتن برنامه تون عادی است، اما آسیب‌پذیری‌های وابستگی‌ها می‌توانند برنامه‌های شما را بدون انجام کاری در معرض دید قرار دهند. همچنین شامل تعداد زیادی وابستگی معمول است، اما هر وابستگی آسیب‌پذیری‌های احتمالی را افزایش می‌دهد که باید از آنها آگاه باشید.
توصیه می‌کنم همه چیز را به‌صورت هفتگی یا ماهانه به‌روزرسانی کنید و از ابزارهایی مانند composer audit --locked و npm audit در اپ خود استفاده کنید تا هنگام کشف آسیب‌پذیری‌ها بتوانید آن را مسدود کنید. همچنین پیشنهاد می‌کنم وابستگی‌های خود را به حداقل برسانید، و هر چیزی که می‌تواند به راحتی با یک میدلور ساده داخلی یا پکیج جایگزین شود، باید باشد.
5# استفاده از توابع ناامن
من تعداد دفعاتی را که از زمان شروع به کار در PHP استفاده شده از md5(time()) و md5(microtime())) را از دست داده ام .بدتر از آن، اغلب برای تولید توکن های تصادفی یا نام فایل های منحصر به فرد استفاده می شود. با این تفاوت که نه تصادفی است و نه منحصر به فرد. حدس زدن و brute-force فوق‌العاده آسان است، و حملات برخورد نیز می‌توانند بسیار پیش پا افتاده باشند.
شرط می بندم اگر همین الان وارد قسمت های کد خود شوید و md5 را جستجو کنید، متوجه می شوید که در جایی به طور ناامن استفاده شده است.
این فقط به طور خاص md5(time()) نیست، بلکه توابع دیگری مانند ()rand و ()array_rand است که از نظر رمزنگاری ایمن نیستند و برای هر چیزی که نیاز به امنیت دارد نباید به آنها اعتماد کرد.
همیشه از توابع تولید کننده اعداد تصادفی ایمن مناسب، ()random_int و ()Str::random برای تولید ایمن مقادیر تصادفی استفاده کنید.
4# سرصفحه های امنیتی از دست رفته
اکنون ما وارد لایه‌های حفاظتی اضافی می‌شویم که به خوبی درک نشده‌اند. مرورگرهای وب شامل مجموعه ای از ویژگی های امنیتی واقعا عالی هستند، فقط باید آنها را با استفاده از هدرهای پاسخ در سایت خود فعال کنید. در حالی که نبود آنها مستقیماً سایت شما را برای هک کردن باز نمی کند، آنها به جلوگیری از مواردی مانند جک کلیک، نشت اطلاعات ارجاع دهنده، حملات XSS و سایر حملات تزریقی، حملات کاهش رتبه HTTPS و غیره کمک می کنند. فعال کردن بسیاری از این هدرهای امنیتی بی اهمیت است، اما اکثر سایت ها این کار را انجام نمی دهند. حتی مواردی که آسان هم هستند را فعال نکنید.
بهترین پیشنهادی که می توانم به شما بدهم این است که به این وبسایت بروید و سایت خود را اسکن کنید. تمام هدر هایی را که از دست داده‌اید فهرست می‌کند و پیوندهایی به منابع در اختیار شما قرار می‌دهد تا درباره افزودن آنها بیشتر بدانید.
3# خط مشی امنیتی محتوای گمشده (CSP)
خط‌مشی‌های امنیتی محتوا آنقدر مهم هستند که می خواهیم بررسی کنیم. CSPها خط دفاعی ثانویه در برابر XSS و کلیک‌جک هستند و به شما نشان می‌دهند که چه اسکریپت‌ها، استایل ها، فونت‌ها، فرم‌ها، فریم‌ها و غیره اجرا می‌شوند. در برنامه شما CSP به مرورگر می‌گوید که چه منابعی مجاز به استفاده در سایت هستند، و هر گونه تخلف از این خط‌مشی را مسدود و/یا گزارش می‌کند - از حملات XSS جلوگیری می‌کند و به شما امکان مشاهده آنچه در سایت شما می‌افتد را ارائه می‌دهد.
آنها اغلب بیش از حد سخت رد می‌شوند، اما به‌کارگیری یک خط‌مشی فقط گزارش، دید کامل را بدون شکستن چیزی برای شما فراهم می‌کند. بنابراین، این قطعاً راهی است که باید زمانی که شروع می کنید، بروید! ساده ترین راه برای راه اندازی این است که از CSP Wizard در گزارش URI استفاده کنید.
2# مجوز از دست رفته
این یکی شامل مجموعه ای از موارد در مورد مجوز (و احراز هویت به نوعی) است.ارجاعات مستقیم آبجکت ناامن (IDOR)، میدلور ها و signed، تأیید اعتبار و خط‌مشی، فراخوان‌های فراموش‌شده ()autorize، وب هوک های بدون اعتبارسنجی، و غیره… در نهایت، کد واقعاً بررسی نمی‌کرد که آیا درخواست‌کننده مجاز به انجام این کار است یا خیر.
اما معلوم شد که برای اکثر پروژه‌ها کاملاً معمول است که یکی از این موارد در جایی پنهان شده و منتظر بهره‌برداری باشد. معمولاً یک مورد ساده است که توسعه‌دهنده فراموش می‌کند در یک خط اضافه کند، اما به طور بالقوه حفره‌ای بزرگ باقی می‌گذارد.
بهترین توصیه من در اینجا این است که آزمایش‌هایی را برای احراز هویت و مجوز در هر مسیر، در کنار سایر آزمایش‌های خود قرار دهید. به این ترتیب، مجوزهای معتبر و نامعتبر را به عنوان بخشی از جریان تست استاندارد خود بررسی می‌کنید، و متوجه می‌شوید که آیا مجوز وجود ندارد، زیرا زمانی که قرار است با شکست مواجه شود، یک آزمون قبول می‌شود.
1# کلیدها و رمزهای عبور API در معرض دید
کلیدهای API و گذرواژه‌ها به کنترل ورژن کامیت شده و در بخش های کد پراکنده شدند.
در نظر داشته باشید که کد شما کجا قرار می گیرد ... این کد بر روی تمام دستگاه های توسعه دهندگان شما، با پیمانکاران به اشتراک گذاشته می شود، در GitHub، Bitbucket، GitLab و غیره، در سرویس های شخص ثالث و ابزارهای ساخت قرار دارد. این کد در بسیاری از جاها منتشر شده است. در حالی که کلیدهای API شما فایل های پشتیبان، اطلاعات شناسایی شخصی، ذخیره سازی فایل، صورتحساب، زیرساخت و غیره را باز می کند. بسیاری از اطلاعات حساس و دسترسی ها، و اگر به دست افراد نامناسب بیافتد، ممکن است بد تمام شود.
می دانم که آموزش هایی وجود دارند که توصیه می کنند این کارها را انجام دهید، بنابراین می توانم ببینم چرا این اتفاق می افتد. اما این چیزی است که به عنوان یک جامعه باید برای جلوگیری از آن بکوشیم.
اگر به طور تصادفی اعتبارات را ثبت کردید، مطمئن شوید که آن را در منبع لغو کنید. این باعث می شود هر کسی که آن را پیدا کرد، نتواند از آن استفاده کند. همچنین پیشنهاد می کنم از ابزارهایی مانند Gitleaks و TruffleHog برای پیدا کردن سکرت ها در کد پروژه های خود استفاده کنید.
نتیجه
ما در این مقاله 10 تا از رایج ترین موارد امنیتی در لاراول را بررسی کرده ایم.چیزی بود که با آن مخالف باشید؟ می توانید در قسمت نظرات آن را به اشتراک بگذارید.
نکته کلیدی برای من این است که در حالی که لاراول ایمن است، همه چیزهای کوچکی هستند که نادیده گرفته می شوند و فراموش می شوند. آسان است که فرض کنید مجوز را در هر مسیر بررسی کرده اید، و خروجی شما به طور کامل از بین رفته است، اما ممکن است یک نمونه وجود داشته باشد که از دست داده باشید.