لاحظت أن Discourse يحفظ معلومات وكيل المستخدم في بعض الجداول، مثل web_crawler_requests. ومن المعروف أن المهاجمين يستخدمون حقل “user-agent” لحقن أكواد خبيثة، كما في هجمات Sleepy User Agent. أتساءل عما إذا كانت Discourse تتخذ أي إجراءات للحماية من هذا النوع من الهجمات؟
Discourse هو تطبيق مبني على إطار عمل Rails، لذا نستفيد من حماية الإطار في مشروعنا:
6 إعجابات
مرحبًا @mbaker341997
إن دليل أمان Rails يقدم نظرة عامة جيدة، ولكن في رأيي، لا يغطي دليل أمان Rails بشكل كافٍ ما يعتبره الكثيرون (يمكن القول) أهم ضابط للتخفيف من هجمات حقن SQL.
الخط الدفاعي الأول ضد “حقن SQL” هو التحقق القوي من صحة بيانات الإدخال.
دعني أعطي مثالًا مباشرًا من دليل أمان Rails (أعلى):
يُظهر دليل أمان Rails هذا المثال البسيط:
Project.find(:all, :conditions => "name = '#{params[:name]}'")
والذي يمكن استغلاله عن طريق الحقن في معلمات الإدخال:
' OR 1=1'
ومع ذلك، يمكن منع ذلك من خلال وجود تحقق قوي في النموذج، على سبيل المثال:
before_validation :filter_name_param
private
def filter_name_param
### ضع هنا كود تصفية المعلمات المخصص الخاص بك لضمان عدم السماح بأي أحرف خاصة أو
### "كود خطير" آخر بالقرب من قاعدة البيانات
end
يحتوي Rails على الكثير من عمليات التحقق “الجاهزة” التي يمكن (ويجب) تضمينها في النماذج لضمان التحقق من صحة معلمات الإدخال قبل وقت طويل من دخولها قاعدة البيانات.
إليك المزيد حول التحقق في Rails هنا:
ينسى الكثيرون أن التحقق من صحة بيانات الإدخال هو الخط الدفاعي الأول ضد هجمات حقن SQL، وهذا ينطبق على جميع أكواد تطوير الويب من جانب الخادم مثل Ruby و PHP و Python وما إلى ذلك. بشكل عام، يمكن استغلال التحقق من جانب العميل ويجب التحقق منه أيضًا من جانب الخادم.
على وجه الخصوص، أوصي بقراءة قسم “التحقق المخصص”:
أتمنى أن يكون ذلك مفيدًا.
إعجابَين (2)