ASP.NET طلب حماية التزوير (XSRF/CSRF) في هذه النواة

البيئه

استوديو البصرية

• استوديو البصرية 2019

ASP.NET الأساسية

• 3.0
• 3.1

ما هو طلب عبر الموقع forgeri؟

التزوير في الطلب عبر الموقع (CSRF/XSRF) هو لأولئك الذين تتم معالجتهم فقط داخل موقع الاهتمام. هجوم على مشكلة عدم حصانة تقوم بتنفيذ عملية تحديث من موقع خارجي.

على سبيل المثال، افترض أن لديك القدرة على نشر التعليقات على موقع ويب. عادة ، وأعتقد أنك سوف آخر عن طريق إدخال تعليق من الموقع ، غالبًا ما يتم استخدام عملية الإرسال هذه لرمي البيانات في عنوان URL المستهدف.

لذلك، إذا قمت بإرسال بيانات مشابهة إلى عنوان URL من شخص آخر غير الموقع المستهدف، انها نفس المعاملة التي نشرتها.

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

أنا لن تذهب إلى عمق هنا ، لذا يرجى معرفة المزيد عن طلب عبر الموقع forgeri.

ASP.NET كور يدمج هذا التدبير المضاد في الإطار.

التحقق من تزوير طلب عبر الموقع للعمل

حاول معرفة ما إذا كان يتم تنفيذ عملية التحديث بالفعل من مواقع أو أدوات خارجية.

يقوم Index.cshtml بإنشاء نموذج إدخال يرسل النص الذي أدخلته إلى الخادم. ثم ضع بيانات العرض بحيث يعرض الملقم الرسائل التي قمت بإنشائها لمطابقة نص الإدخال.

Index.cshtml

@{
  ViewData["Title"] = "Home Page";
}

<div class="text-center">
  <h1 class="display-4">Welcome</h1>
  <p>Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core</a>.</p>
</div>

<form method="post">
  <input type="text" name="text" />
  <button type="submit">送信</button>
</form>

<p>@ViewData["Message"]</p>

يقوم HomeController.cs من جانب الخادم بمعالجة النص المرسل وإخراجه إلى تتبع Visual Studio. تعيين نفس النص إلى ViewData بحيث يمكن عرضه على العميل.

HomeController.cs

public class HomeController : Controller
{
  // 省略

  [HttpPost]
  public IActionResult Index(string text)
  {
    System.Diagnostics.Trace.WriteLine($"「{text}」が入力されました。");
    ViewData["Message"] = $"「{text}」が入力されました。";
    return View();
  }

  // 省略
}

حاول تنفيذ الوظيفة التي قمت بإنشائها للتو في الخطوات العادية. عند تشغيل التصحيح وتظهر الشاشة، أدخل النص وانقر فوق الزر إرسال.

يظهر النص المعالج على الشاشة كما هو متوقع.

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

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

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

عند إنشاء ملف .http مشابه للما يلي في ملف نصي، ثم فتح الملف في رمز Visual Studio، يمكنك إرسال GET أو POST بالنقر فوق إرسال الطلب.

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

RestTest.http://www.restTest.http

### Form で POST 送信
POST https://localhost:44372/home/index HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="text"

なんらかのテキスト
------WebKitFormBoundary7MA4YWxkTrZu0gW--

عند إرساله، يمكنك أن ترى أن الملقم يتلقى النص ومعالجته.

يمكن للمدونة البصرية استوديو الحصول على النتائج. إذا قمت بإلقاء نظرة فاحصة على رمز النتيجة، يمكنك أن ترى أن يتم عرض مجموعة القيمة لـ ViewData. (يتم عرضه في Unicode، ولكن يتم عرض النص بشكل صحيح إذا تم عرضه في مستعرض ويب.)

معالجة مشكلة عدم حصانة طلب مزوري عبر الموقع

وكما ذكرت في البداية، فإن ASP.NET كور يتضمن تدابير ضد التزوير في طلب عبر الموقع في الإطار. ويتمثل أحد التدابير الشائعة في إصدار رمز مميز فريد للعميل مقدمًا على شاشة تتطلب مشاركة ، وما إلى ذلك. لم يكن لديك لقبول المعالجة إلا إذا قمت برمي الرمز المميز إلى الملقم.

بالطبع، إذا قمت بالوصول إلى عنوان URL مباشرة من موقع خارجي، فإن الرمز المميز غير معروف ولن يقبل المعالجة.

أولا ، أود أن أتحدث عن إصدار الرموز للعميل (HTML) ، ولكن الحقيقة هي أن الإطار غير قادر على القيام بذلك. سوف تذهب. إذا قمت بتحديد أسلوب POST في علامة النموذج، يمكنك دمج معلمات الرمز المميز في HTML دون إذن.

في HTML أدناه، هو اسم الإدخال ="__RequestVerificationToken" نوع ="مخفي". يتم إرسال هذا إلى الملقم معاً عند الضغط على زر الإرسال. بالمناسبة، لا يتم إلحاقه بواسطة أسلوب GET.

على جانب الخادم، Startup.cs الخدمات. خيارات أسلوب AddControllersWithViews. عوامل التصفية إلى AutoValidateAntigerygeryTokenAttribute، جميع الإجراءات تتم إضافة هذا الاختيار الرمز المميز تلقائيًا إلى (على وجه الدقة فقط طرق HTTP من POST و PUT و PATCH و DELETE).

إذا كنت ترغب في إضافة هذا القيد فقط إلى إجراءات محددة، وليس كل الإجراءات، لكل وحدة تحكم، لكل إجراء من الممكن أيضًا تعيين.

وعلى العكس من ذلك، إذا كنت ترغب في فرض قيود على معظم الإجراءات، ولكنك تريد استبعاد إجراءات محددة، إذا قمت بتعيين السمة IgnoreAntigeryTokens إلى وحدة تحكم والعمل، فإنه موافق.

Startup.cs

public void ConfigureServices(IServiceCollection services)
{
  services.AddControllersWithViews(options =>
  {
    // 全ての「POST, PUT, PATCH, DELETE」アクションに自動で ValidateAntiForgeryToken を付与。
    // 個別に除外したい場合は「IgnoreAntiforgeryToken」属性を指定すること
    // API では HTML 側にトークンを発行できないのでコントローラーに「IgnoreAntiforgeryToken」を指定する必要がある。
    options.Filters.Add(new Microsoft.AspNetCore.Mvc.AutoValidateAntiforgeryTokenAttribute());
  });
}

دعونا نرى كيف يعمل. أولا وقبل كل شيء، تتم عملية الإرسال من الشاشة بشكل طبيعي.

وانعكست النتائج على الشاشة كما هو متوقع.

هو أيضا إخراج إلى الأثر.

الآن، دعونا نحاول الوصول إليه من الخارج.

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

موجز

هذه المرة حاولت تنفيذ تدابير ضد طلب عبر الموقع forgeri. وكان من السهل جدا تنفيذ ذلك لأنه مدمج بالفعل في الإطار.

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