8 بهترین روش امنیتی در لاراول : از CSRF تا آپلود امن

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

از ()request->all$ استفاده نکنید

استفاده از ()request->all$ در متد store یا متد update می‌تواند آسیب‌پذیری‌های امنیتی را با فیلتر نکردن ورودی از frontend یا API ایجاد کند. به عنوان مثال اگر پایگاه داده شما دارای فیلدی مانند is_admin باشد و در مدل Eloquent قابل پر کردن باشد، کسی می تواند نام این فیلد را حدس بزند و با تغییر HTML آن را به داده های فرم اضافه کند.

به جای استفاده از ()request->all$ از کلاس های درخواست فرم برای اعتبارسنجی استفاده کنید و سپس از ()request->validated$ استفاده کنید. فیلدهای دقیقی را که از فرم انتظار دارید با استفاده از ()request->only$ یا ()request->except$ برای محافظت از پایگاه داده خود در برابر ورودی های مخرب مشخص کنید.

آپلود فایل با داده های کلاینت

آپلود فایل نیز می تواند خطرات امنیتی ایجاد کند. استفاده از متد های مانند ()file->getClientOriginalName$ یا ()file->getClientOriginalExtension$ می‌تواند ناامن باشد، زیرا نام و پسوند فایل را می‌توان عمداً توسط یک کاربر مخرب تغییر داد تا امنیت برنامه شما را دور بزند.

مستندات لاراول در مورد این متد ها بیان می کند:

به خاطر داشته باشید که متد های getClientOriginalName و getClientOriginalExtension ناامن در نظر گرفته می‌شوند، زیرا ممکن است نام و پسوند فایل توسط یک کاربر مخرب دستکاری شود. به همین دلیل، معمولاً باید متد hashName و پسوند را برای دریافت نام و پسوند برای آپلود فایل داده شده ترجیح دهید."

به جای استفاده از این متد های ناامن، از ()hashName و ()extension استفاده کنید تا یک نام و پسوند امن برای فایل آپلود شده بدست آورید.

آشنایی با تست نویسی در لاراول

میکروسرویس در لاراول

حفاظت CSRF و درخواست های GET

هنگام ایجاد فرم ها در لاراول معمولاً یک توکن csrf@ به طور پیش فرض وجود دارد. اگر متد های POST، PUT، PATCH یا DELETE HTTP توکن csrf@ پیدا نکردند، این درخواست‌ها توسط پیکربندی پیش‌فرض برنامه لاراول رد می‌شوند. توکن CSRF در لاراول برای کاربر منحصربه‌فرد است، اگر فردی خارج از برنامه شما بخواهد درخواست مخربی ارائه دهد، به دلیل وجود توکن CSRF رد می‌شود.

با این حال، برای درخواست های GET، توکن csrf@ در دسترس نیست. به عنوان مثال، اگر از یک درخواست GET برای یک اقدام حذف استفاده می کنید، حفاظت CSRF اعمال نمی شود و کاربر خارج از برنامه شما می تواند از آن درخواست GET برای حذف داده های برنامه استفاده کند. بنابراین اطمینان حاصل کنید که از درخواست های GET برای اقداماتی که داده های برنامه را تغییر می دهند استفاده نمی کنید.

از فایل env. خود به هر قیمتی محافظت کنید

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

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

حملات Blade و XSS

در فایل‌های Blade می‌توانیم با استفاده از سینتکس {{ var$ }} و به ترتیب {!!  var$ !!}. برای مثال فرض کنید می خواهیم متغیری حاوی متن HTML را از یک کنترلر، پایگاه داده یا دریافت از یک برنامه شخص ثالث نمایش دهیم.

با استفاده از escape text :

$var = '<b>Hello, this is some HTML text</b>';

{{$var}}

<b>Hello, this is some HTML text</b>

استفاده از متن non-escaped :

Hello, this is some HTML text

متن non-escaped HTML را در مرورگر اجرا می کند که می تواند خطرناک باشد. به عنوان مثال:

$var = '<b>Hello, this is some HTML text<script>alert("I executed this in your browser")</script><b>';
{!! $var !!}

این بخش کد مستقیماً در مرورگر اجرا می شود و به طور بالقوه به کاربران مخرب اجازه می دهد داده ها را جمع آوری کنند یا باعث آسیب شوند.

بنابراین، از استفاده از بلوک های متنی non-escaped مانند {!! var$ !!} مگر اینکه متغیر به صورت داخلی توسط سیستم تولید شود. اگر داده های متغیر از پایگاه داده می آیند و توسط کاربران مدیریت می شوند، می توانند کدهای مخرب را وارد کنند.

TDD در لاراول

بررسی تزریق وابستگی در لاراول

هرگز حالت Debug را در سرورهای UAT / Production فعال نکنید

در سرور Production، همیشه باید APP_DEBUG = FALSE را تنظیم کنید. اگر این کار را نکنید، هنگامی که خطایی در برنامه وب شما رخ می دهد و به درستی مدیریت نمی شود، صفحه خطا برای هر کاربری، خواه وارد شده یا نشده باشد، قابل مشاهده خواهد بود.

این صفحه می تواند حاوی مقادیر env. و سایر اطلاعات حساس باشد و نشان می دهد که برنامه شما با لاراول و نسخه خاص مورد استفاده ساخته شده است. این دانش می تواند به کاربر مخرب کمک کند تا آسیب پذیری های خاص مربوط به آن نسخه لاراول را بررسی کند و به سیستم شما دسترسی پیدا کند.

علاوه بر این، عاقلانه است که صفحات خطای پیش‌فرض در لاراول (مثلاً صفحات 500 و 404) و هدر X-Powered-By را تغییر دهید تا کاربران نتوانند به راحتی تشخیص دهند که برنامه شما با لاراول یا PHP ساخته شده است.

در اسناد رسمی لاراول آمده است:

برای توسعه محلی، باید متغیر محیطی APP_DEBUG را روی true تنظیم کنید. در محیط تولید شما، این مقدار باید همیشه نادرست باشد. اگر متغیر در تولید روی true تنظیم شود، شما در معرض خطر قرار دادن مقادیر حساس پیکربندی در معرض کاربران نهایی برنامه خود هستید.

محدود کردن نرخ Rate Limiting

در حالی که یک مشکل مستقیم امنیتی نیست، محدودیت نرخ یا Rate Limiting اقدامی برای جلوگیری از درخواست‌های بیش از حد یک کاربر به سرور شما است. به عنوان مثال، اگر شخصی سعی کند سرور شما را اسپم کند یا یک حمله انکار سرویس توزیع شده (DDoS) را در مقیاس کوچکتر انجام دهد، می توانید برای کاهش این حملات محدودیت نرخ را برای برنامه خود اعمال کنید. محدود کردن نرخ را می توان برای یک مسیر، گروه مسیر یا به صورت سراسری اعمال کرد و می توانید پاسخ و وضعیت پیش فرض HTTP 429 را سفارشی کنید.

این هدرهای امنیتی را تنظیم کنید

هدرهای امنیتی زیر را به وب سرور یا میدلور برنامه لاراول خود اضافه کنید:

X-Frame-Options

این هدر HTTP برای کنترل اینکه آیا یک مرورگر باید اجازه داشته باشد یک صفحه را در <frame>، <iframe>، <embed> یا <object> ارائه کند یا خیر استفاده می‌شود. این هدر امنیتی می تواند برای جلوگیری از حملات کلیک جک استفاده کند که در آن مهاجم می تواند یک سایت را در داخل iframe در سایت مخرب خود جاسازی کند و کاربران را فریب دهد تا با آن تعامل داشته باشند و به طور بالقوه امنیت آنها را به خطر بیندازد.

مثال استفاده :

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
X-Frame-Options: DENY

X-Content-Type-Options

با استفاده از X-Content-Type-Options: هدر nosniff با جلوگیری از تفسیر فایل‌ها به‌عنوان یک نوع MIME متفاوت از آنچه توسط سرور مشخص شده است، امنیت برنامه وب شما را افزایش می‌دهد. این به محافظت در برابر حملاتی مانند Cross-Site Scripting (XSS) و سایر حملات تزریق کد کمک می کند که در آن مهاجم ممکن است سعی کند مرورگر را فریب دهد تا محتوای مخرب را با تفسیر نادرست نوع MIME اجرا کند.

مثال استفاده :

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff

Strict-Transport-Security (فقط برای برنامه های کاربردی HTTPS)

هدر HTTP Strict-Transport-Security (HSTS) برای افزایش امنیت یک وب سایت با دستور دادن به مرورگرها برای استفاده همیشه از HTTPS برای تمام درخواست های آینده به سایت استفاده می شود. این به محافظت در برابر انواع مختلف حملات مانند حملات man-in-the-middle با اطمینان از رمزگذاری شدن اتصالات به سرور کمک می کند.

مثال استفاده :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Content-Security-Policy

هدر HTTP Content-Security-Policy (CSP) ابزار قدرتمندی است که برای افزایش امنیت برنامه های کاربردی وب با کنترل منابعی که مرورگر مجاز است برای یک صفحه معین بارگذاری کند، استفاده می شود. این به کاهش انواع حملات مانند اسکریپت بین سایتی (XSS)، حملات تزریق داده و سایر اشکال حملات تزریق کد با مشخص کردن منابع مورد اعتماد برای انواع مختلف محتوا کمک می کند.

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

نمونه سیاست CSP :

Content-Security-Policy: 
    default-src 'self'; 
    script-src 'self' https://trustedscripts.example.com; 
    style-src 'self' https://trustedstyles.example.com; 
    img-src 'self' https://trustedimages.example.com; 
    connect-src 'self' https://api.example.com; 
    font-src 'self' https://trustedfonts.example.com; 
    frame-ancestors 'self'

دیزاین پترن Observer در لاراول 11

نتیجه

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

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