سؤال

في ASP.NET MVC 1.0، توجد ميزة جديدة للتعامل مع مشكلة أمان تزوير الطلبات عبر المواقع:

 <%= Html.AntiForgeryToken() %>
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
    // ... etc
}

لقد وجدت أن الرمز المميز الذي تم إنشاؤه في نموذج html يتغير باستمرار في كل مرة يتم فيها تقديم نموذج جديد.

أريد أن أعرف كيف يتم إنشاء هذه الرموز؟وعند استخدام بعض البرامج لفحص هذا الموقع، فإنه سيتم الإبلاغ عن مشكلة أمنية أخرى:تم إصلاح الجلسة.لماذا؟بما أن الرمز يتغير باستمرار، كيف يمكن أن تأتي هذه المشكلة؟

وهناك وظيفة أخرى، وهي "الملح" لل antiForgeryToken, ، لكنني أعرف حقًا الغرض من استخدام هذا، حتى من خلال عدم استخدامنا "الملح" لإنشاء الرمز المميز، فإن الرمز المميز سيتغير طوال الوقت، فلماذا توجد مثل هذه الوظيفة؟

هل كانت مفيدة؟

المحلول

الكثير من المعلومات حول AntiForgeryToken هنا: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

وذلك لمنع تزوير الطلب عبر المواقع (CSRF).إنه سلوك قياسي جدًا أن تقوم بالنقر فوق "حفظ" وإلقاء نموذج وتنفيذ بعض الإجراءات على الخادم، على سبيل المثال.حفظ تفاصيل المستخدم.كيف تعرف أن المستخدم الذي يرسل النموذج هو المستخدم الذي يدعي أنه هو؟في معظم الحالات، يمكنك استخدام بعض ملفات تعريف الارتباط أو المصادقة المستندة إلى نظام التشغيل Windows.

ماذا لو استدرجك أحد المهاجمين إلى موقع يرسل نفس النموذج تمامًا في إطار IFRAME مخفي قليلاً؟يتم إرسال ملفات تعريف الارتباط الخاصة بك سليمة ولا يرى الخادم أن الطلب مختلف عن الطلب الشرعي.(كما اكتشف Gmail: http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/)

يمنع رمز مكافحة التزوير هذا النوع من الهجوم عن طريق إنشاء رمز مميز لملف تعريف الارتباط في كل مرة يتم فيها إنشاء صفحة.الرمز المميز موجود في النموذج وملفات تعريف الارتباط، إذا كان النموذج وملف تعريف الارتباط غير متطابقين، فسنتعرض لهجوم CSRF (حيث لن يتمكن المهاجم من قراءة رمز مكافحة التزوير باستخدام الهجوم الموصوف أعلاه).

وماذا يفعل الملح من المقال أعلاه:

الملح هو مجرد سلسلة تعسفية.تعني قيمة الملح المختلفة أنه سيتم إنشاء رمز مميز مختلف لمكافحة التزوير.وهذا يعني أنه حتى إذا تمكن المهاجم من الحصول على رمز صالح بطريقة أو بأخرى، فلن يتمكن من إعادة استخدامه في أجزاء أخرى من التطبيق حيث تكون هناك حاجة إلى قيمة ملح مختلفة.

تحديث: كيف يتم إنشاء الرمز المميز؟تحميل مصدر, ، وإلقاء نظرة على فئات AntiForgeryDataSerializer وAntiForgeryData.

نصائح أخرى

لقد طرحت بعض المشاكل غير ذات الصلة:

  1. لا أعرف لماذا يقوم برنامج الأمان الخاص بك بالإبلاغ عن "تم إصلاح الجلسة".حاول قراءة الوثائق التي تأتي مع التقرير
  2. رمز مكافحة التزوير:

يتم استخدام هذا (من المفترض) للتحقق من صحة كل طلب.لذا ضع في اعتبارك أن شخصًا ما يحاول تقديم رابط للصفحة ?x=1, ، إذا لم يتم تمرير الرمز المميز أيضًا، فسيتم رفض الطلب.علاوة على ذلك، (يجوز) منع النشر المكرر لنفس العنصر.إذا نقرت على "نشر" مرتين، فمن المحتمل أن يتغير الرمز المميز (كل طلب)، وسيتم اكتشاف هذه الحالة عبر شيء مثل:

Session["nextToken"] = token;
WriteToken(token);

...

if( !Request["nextToken"] == Session["nextToken"] ){
    ...
}

// note: order in code is slightly different, you must take the token
// before regenerating it, obviously

أعتقد أن المصطلح الخاص بهذا (الهجوم الذي يحميه) يسمى "CSRF" (تزوير طلب عبر المواقع)، هذه الأيام.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top