#ثريد أعلى 7 أخطاء أمنية يقع فيها مطورين Laravel
1 - استخدام {!! !!}
هذا النوع لا يقوم بعمل أي escaping للمدخل وتم وضعها بواسطة !! لتدل على خطورتها، وتجعلك عرضه لثغرة XSS(ثغرة تمكن من حقن اكواد HTML, CSS, JavaScript)
قم باستخدام {{ }} كبديل لها.
وإن مازلت تريد {!! !!} فتأكد انك تقوم بعمل تحقيق للمدخلات أولا.
هذا النوع لا يقوم بعمل أي escaping للمدخل وتم وضعها بواسطة !! لتدل على خطورتها، وتجعلك عرضه لثغرة XSS(ثغرة تمكن من حقن اكواد HTML, CSS, JavaScript)
قم باستخدام {{ }} كبديل لها.
وإن مازلت تريد {!! !!} فتأكد انك تقوم بعمل تحقيق للمدخلات أولا.
2 - عدم حماية ملف .env
ملف .env يحتوي على معلومات حساسة خاصة بإعدادات الموقع و قواعد البيانات، عدم حمايتها يؤدي الوصول إلى هذه المعلومات وقد يصل للدخول في قاعدة البيانات بشكل مباشر!
تأكد من وضع هذا الملف في .gitignore أو عن طريق وضع صلاحيات منخفضة لهذا الملف في السيرفرات.
ملف .env يحتوي على معلومات حساسة خاصة بإعدادات الموقع و قواعد البيانات، عدم حمايتها يؤدي الوصول إلى هذه المعلومات وقد يصل للدخول في قاعدة البيانات بشكل مباشر!
تأكد من وضع هذا الملف في .gitignore أو عن طريق وضع صلاحيات منخفضة لهذا الملف في السيرفرات.
3 - استخدام getClientOriginalName أو getClientOriginalExtension
هذه الدوال عادة تتواجد عندما يكون هناك رفع للملفات وتريد إنشاء أسم معين للملف ولسوء الحظ انهما غير أمنتين.
تُرشد Laravel doc بالابتعاد عنها واستخدام hashName و extension كبديل لها.
هذه الدوال عادة تتواجد عندما يكون هناك رفع للملفات وتريد إنشاء أسم معين للملف ولسوء الحظ انهما غير أمنتين.
تُرشد Laravel doc بالابتعاد عنها واستخدام hashName و extension كبديل لها.
4 - وضع APP_DEBUG=true في مرحلة Production
تفعيل debugging قد يكشف بيانات حساسة مثل قواعد البيانات او حتى الكود نفسه! المفترض أن يستخدم في مرحلة development فقط
تأكد من عمل APP_DEBUG=false داخل ملف .env في مرحلة production
تفعيل debugging قد يكشف بيانات حساسة مثل قواعد البيانات او حتى الكود نفسه! المفترض أن يستخدم في مرحلة development فقط
تأكد من عمل APP_DEBUG=false داخل ملف .env في مرحلة production
5 - استخدام Route::get وثغرة CSRF
أصبحت Laravel تُجبر ان يكون هناك CSRF_token لكل من POST, PUT, PATCH أو DELETE لكن بدون GET لأنه عادة ما يستخدم للعرض فقط, ان كنت تستخدم GET في حفظ المدخلات او تعديل او حتى حذف للبيانات فتأكد ان تضع CSRF داخل form وإلا ستكون عرضه لثغرة CSRF
أصبحت Laravel تُجبر ان يكون هناك CSRF_token لكل من POST, PUT, PATCH أو DELETE لكن بدون GET لأنه عادة ما يستخدم للعرض فقط, ان كنت تستخدم GET في حفظ المدخلات او تعديل او حتى حذف للبيانات فتأكد ان تضع CSRF داخل form وإلا ستكون عرضه لثغرة CSRF
6 - استخدام request->all
عندما تقوم بعملها فأنت تجلب كل ما تم إدخالها، ماذا لو كان هناك عمود بمسمى is_admin ويقوم المستخدم بعمل is_admin=true هذه ثغرة وتسمى mass assignment .
لحسن الحظ Laravel تُجبر ان تضع ما يجب ان يدخل في fillable داخل model إلا في GET request
عندما تقوم بعملها فأنت تجلب كل ما تم إدخالها، ماذا لو كان هناك عمود بمسمى is_admin ويقوم المستخدم بعمل is_admin=true هذه ثغرة وتسمى mass assignment .
لحسن الحظ Laravel تُجبر ان تضع ما يجب ان يدخل في fillable داخل model إلا في GET request
7 - عدم تقييد requests والتعرض DDoS
طريقة عمل DDoS هو إنشاء عدد هائل من requests إلى السيرفر حتى يتفوق على قدراته فيقوم بإرجاع 5xx status code
لعدم مقدرته في التعامل مع requests
تأكد من تحديد requests في كل دقيقة
وهذا رابط Laravel doc لطريقة الحماية:
laravel.com
طريقة عمل DDoS هو إنشاء عدد هائل من requests إلى السيرفر حتى يتفوق على قدراته فيقوم بإرجاع 5xx status code
لعدم مقدرته في التعامل مع requests
تأكد من تحديد requests في كل دقيقة
وهذا رابط Laravel doc لطريقة الحماية:
laravel.com
Code Safe and Happy Coding 🛡️
جاري تحميل الاقتراحات...