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$ !!} استفاده کنید که شما مطمئن هستید مقادیر برای نمایش امن هستند.
در این مقاله ما درمورد انواع حمله ها به نرم افزارهای تحت وب صحبت کردیم و یاد گرفتیم که لاراول چطور دربرابر یکسری از این حملات از پروژه ما نگهداری می کنه اما فراموش نکنید یک فریمورک نمیتونه پروژه شما رو از همه چیز مصون نگه داره.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید