عنوان مقاله :

5 نکته امنیتی مهم برای یک برنامه لاراولی

گردآوری و تالیف : امیررضا سیستانه ای
تاریخ انتشار : 01 مرداد 1396
دسته بندی ها : لاراول

1 – جلوگیری از تزریق SQL injection – SQL

یک تزریق SQL وقتی خطرناک میشه که یک اپلیکیشن مقادیر ورودی خودسرانه و فیلترنشده رو وارد یک کوئری SQL می کنه. این مقادیر ورودی میتونه از کوکی ها, مقادیر Server ها یا اغلب بصورت مقادیر ورودی GET و POST وارد بشه. این حمله ها سعی میکنند تا به مقادیری که بصورت نورمال قابل دسترس نیستند دسترسی پیدا کنند یا اونها رو ویرایش کنند و یا گاهی فرایند عادی اپلیکیشن رو دچار خرابی کنند.

بصورت پیشفرض لاراول درمقابل این حملات از سایت شما محافظت می کنه چون Query builder و Eloquent هر دو از PDO – PHP Data Objects استفاده می‌کنند. PDO از حالات آماده استفاده می کنه که به شما اجازه میده تا بصورت امن پارامترها رو ارسال کنید بدون اینکه نیاز به کار خاصی داشته باشید.

در برخی موارد شما ممکنه بخواید کدهای پیچیده‌تر یا کدهای خاص دیتابیس رو بصورت کوئری در SQL بنویسید. این کار با استفاده از متد DB::raw امکان پذیره. وقتی از این متد استفاده می‌کنید شما باید بسیار دقت کنید که کوئری های خطرناکی مثل این نسازید :

Route::get('sql-injection-vulnerable', function() {

$name = "'Bobby' OR 1=1";

return DB::select(

DB::raw("SELECT * FROM cats WHERE name = $name"));

});

برای محافظت از این کوئری در مقابل SQL injection شما باید در کوئری بجای پارامتر ها از علامت سؤال استفاده کنید و سپس مقادیر رو در یک آرایه بعنوان دومین پارامتر متد raw ارسال کنید :

Route::get('sql-injection-not-vulnerable', function() {

$name = "'Bobby' OR 1=1";

return DB::select(

DB::raw("SELECT * FROM cats WHERE name = ?", [$name]));

});

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

2 – مجبور کردن HTTPS هنگام تبادل اطلاعات حساس

اگر شما دارید اپلیکیشن خودتون رو در بستر HTTP اجرا می کنید, شما باید توجه کنید که هر اطلاعاتی که تبادل میشه – شامل پسوردها – در cleartext (متن خالص) ارسال میشه. یک هکر در همان شبکه میتونه اطلاعات خصوصی رو بدست بیاره, شامل اطلاعات متغیرهای Session و بعنوان یک قربانی login کنه. تنها راهی که میتونیم از اینجور حمله ها جلوگیری کنیم استفاده ی از HTTPS هست.

اگر شما یک گواهی SSL در وب سرور خودتعون دارید, لاراول تعداد زیادی راهنما برای سوویچ بین HTTP به HTTPS داره و دسترسی به مسیرهای خاصی رو محدود می کنه. شما میتونید یک فیلتر HTTPS تعریف کنید که کاربر رو از مسیر مبدأ به مسیر خانه منتقل می کنه – بصورت زیر :

Route::filter('https', function() {

if ( ! Request::secure())

return Redirect::secure(URI::current());

});

3 – استفاده ی با احتیاط از Mass assignment

یک ویژگی راحت که به شما اجازه میده یک مدل رو براساس ورودی input بسازه, بدون اینکه بخواهید تک تک مقادیر رو تخصیص بدید. این ویزگی باید خیلی دقیق و با احتیاط استفاده بشه. یک کاربر مخرب میتونه در client side فرم رو تغییر بده و یک ورودی جدید به فرم اضافه کنه. 

<input name="is_admin" value="1" />

و وقتی که فرم ارسال شد ما تلاش میکنیم که یک مدل جدید بسازیم :

Cat::create(Request::all())

با استناد به ویژگی آرایه fillable$ که در مدل وجود داره و لیستی از فیلدهایی که میتونند توسط mass assignment پر شوند رو فراهم می کنه.

همچنین برعکس این قضیه هم وجود داره و شما میتونید یک blacklist از فیلدها توسط پراپرتی guarded@ تعریف کنید. بهرحال این option میتونه خطرناک باشه چون شما ممکنه فراموش کنید که وقتی فیلد جدید به مدل اضافه می‌کنید این رو آپدیت هم کنید.

اما کوکی ها بصورت پیشفرض امن هستند. لاراول کار رو برای ساخت,خوندن و expire کردن کوکی ها آسون کرده. شما ممکنه ندونید که تمام کوکی ها بصورت اتوماتیک کدگذاری می شوند. این بدین معنیست که اگر اونها دستکاری بشوند لاراول اونها رو دور میاندازه. این معنی رو هم میده که شما نمیتونید توسط client side اونها رو بخونید!

4 – تقاضای جعلی Cross-site

حمله های از نوع تقاضای حعلی Cross-site یا CSRF توسط هدف قراردادن URL هایی انجام میشه که اثرات جانبی side effect دارن (بدین معنی که عملی رو انجام میدن و فقط کارشون نمایش دیتا نیست). با استفاده از GET در Route ها ما بصورت پیشفرض از بخشی از حملات CSRF مصون هستیم که تأثیرش میتونه بصورت DELETE/cats/1 باشه, ازونجایی که این توسط لینک ساده یا کدهای iframe قابل دسترس نیست. 

بهرحال اگر یک حمله کننده قادر باشه که مقادیر مخربش رو به یک صفحه ارسال کنه میتونه براحتی یک فرم رو به آدرس مورد نظرش ارسال کنه و اگر این فرد موفق به login کردن در سیستم شده باشه اپلیکیشن هیچ راهی جز پذیرش مقادیر مخرب نداره !

از مؤثرترین راه‌های مقابله استفاده از یک token هست ابتدا وقتی که فرم نمایش داده میشه و سپس چک کردن اون token زمانی که فرم ارسال میشه. Form::open و Form::model هردو بصورت خودکار ورودی token_ رو ارسال میکنه و middleware به اون متصل شده که token های درخواست های ورودی چک می کنه.

5 – خلاصی محتوا برای جلوگیری از Cross-site scripting – XSS

حمله های Cross-site scripting یا XSS وقتی اتفاق میافته که حمله کننده ها قادر به قراردادن کدهای client-side جاوا اسکریپت در صفحه‌ای که توسط کاربران مشاهده میشه, باشند. در نرم‌افزار ما با فرض اینکه نام محصول ما مشخص نشده, اگر ما تکه کد زیر رو بعنوان مقدار نام محصول وارد کنیم, هر بازدیدکننده هرکجا که نام محصول ما نمایش داده بشه یک آلارم می بینه :

Evil Product <script>alert('Meow!')</script>

از اونجایی که این یک کد نسبتاً خطرناک هست, بسیار ساده میشه یک اسکریپت طولانی‌تر یا لینکی به یک اسکریپت خارجی رو که مقادیر Session یا کوکی رو میدزده رو وارد کنیم. برای جلوگیری از اینجور حمله ها, شما باید به هیچ دیتای واردی از کاربر اعتماد نکنید و به کاراکترهای خطرناک توجه کنید. شما باید از syntax بصورت {{ value$ }} در قالب‌های blade خودتون استفاده کنید و فقط وقتی از {!! value$ !!} استفاده کنید که شما مطمئن هستید مقادیر برای نمایش امن هستند.

در این مقاله ما درمورد انواع حمله ها به نرم افزارهای تحت وب صحبت کردیم و یاد گرفتیم که لاراول چطور دربرابر یکسری از این حملات از پروژه ما نگهداری می کنه اما فراموش نکنید یک فریمورک نمیتونه پروژه شما رو از همه چیز مصون نگه داره.

منبع

مقالات پیشنهادی

مجموعه 50 آیکون فروشگاهی

آیکون ها نقش یک قانون را در usability (قابلیت استفاده) وبسایت های فروشگاهی بازی میکنند . با یک نگاه ساده میتوانیم متوجه این موضوع شویم که آیکون ها معم...

40 مجموعه از بهترین آیکون های 2015

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

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

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

25 آیکون طراحی و اشکال

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

دیدگاه های ارزشمند شما

برای ارسال نظر لازم است ابتدا وارد سایت شوید
دانا میرافضل | 5 ماه پیش

مقاله کاربردی بود . با تشکر از شما ;-)

حسام موسوی | 5 ماه پیش

تشکر از نظرتون

امیررضا سیستانه ای | 5 ماه پیش

ممنون از نظرتون

نیما | 5 ماه پیش

خیلی گیج کننده ترجمه شده ولی منظور رسونده
قسمت Cross-site راه کارش به خوبی گفته نشده

پرچم لاراولی های راکت بالاس

حسام موسوی | 5 ماه پیش

سلام مرسی از نظرتون
در قسمت ۴ منظورش اینکه شما به دیگران اجزاه ندید که درخواست های fake به سیستمتون ارسال کنند و برای اینکه مطمئن بشین یه درخواست حتما از وبسایت شماست از CSRF TOKEN میتونید استفاده کنید که در لاراول این برای روت های POST ضررویه

امیررضا سیستانه ای | 5 ماه پیش

همینطور که آقای موسوی گفتند راه حل این هستش که از توکن ها در post استفاده بشه. چشم در مقالات آینده سعی میکنم توضیح بیشتری اضافه کنم

وب مستر | 5 ماه پیش

سلام خسته نباشید
مقاله خیلی مبهم و ترجمه کاملی نداره
البته از سوء نیت ان نگفتم
در ضمن در لاراول پکیج های زیادی وجود داره که تمام این کارارو انجام میده

بهترین سایت لاراول راکته دوره های آموزشیش عالیه
متشکر از راکت

حسام موسوی | 5 ماه پیش

سلام تشکر بابت نظرتون
از نظر خودم مقاله بدی نبود
چون نکات خوبی گفته شد که گاهن کاربران دقت نمی کنن
اینکه کمی نامفهوم بود بخاطر این بود که شاید پیش زمینه ای این حملات در php نداشته بودین
در هر صورت سعی میکنیم خیلی بهتر ترجمه و تالیف بشه تا شما بتونیند راحت تر موارد گفته شده رو متوجه بشین

امیررضا سیستانه ای | 5 ماه پیش

ممنون از نظرتون تلاش میکنم در آینده توضیحات بیشتری اضافه کنم