ASP.NET הגנת זיוף בקשות (XSRF/CSRF) בליבה זו

סביבה

ויז סטודיו

• ויז סטודיו 2019

ASP.NET ליבה

• 3.0
• 3.1

מהי בקשת מרובת אתרים?

זיוף בקשה בין אתרים (CSRF/XSRF) מיועד לאלה המעובדים רק בתוך אתר העניין. התקפה על פגיעות המבצעת תהליך עדכון כזה מאתר חיצוני.

לדוגמה, נניח שיש לך את היכולת לפרסם הערות באתר. בדרך כלל, אני חושב שתפרסם על ידי הזנת תגובה מהאתר, תהליך שליחה זה משמש לרוב לזריקת נתונים בכתובת ה-URL של היעד.

לכן, אם אתה שולח נתונים דומים לכתובת ה-URL ממישהו אחר מאשר אתר היעד, . זה אותו היחס שפרסמת

אם רק תוקף היה עושה זאת, זה לא היה מהווה איום. הדבר המפחיד על CSRF הוא שתוקפים יכולים לבנות אתרים מזויפים או להטביע כתובות Url נסתרות באתר. זה המקום שבו מישהו אחר ניגש אליו בשוגג והופך להיות תוקף.

אני לא הולך לעומק כאן, אז בבקשה לברר יותר על הבקשה באתר בקשה.

ASP.NET Core משלבת את אמצעי הנגד הזה לתוך המסגרת.

בדוק זיוף בקשה לאתרים מסוימים כדי לעבוד

נסה לבדוק אם תהליך העדכון מבוצע למעשה מאתרים או מכלים חיצוניים.

Index. cshtml יוצר טופס קלט ששולח את הטקסט שהזנת לשרת. לאחר מכן הצב נתוני תצוגה כך שהשרת יציג הודעות שיצרת כדי להתאים לטקסט הקלט.

אינדקס. 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();
  }

  // 省略
}

נסה לבצע את הפונקציונליות שיצרת זה עתה בשלבים הרגילים. בעת הפעלת איתור באגים והמסך מופיע, הזן את הטקסט ולחץ על לחצן שלח.

הטקסט המעובד מופיע על המסך כמצופה.

מכיוון שזהו גם פלט למעקב, חלון הפלט של הסטודיו החזותי מציג גם טקסט. למעשה, אנחנו עושים דברים כמו רישום נתוני קלט במסד נתונים, אבל אנחנו לא מתכוונים לפשט את הקוד כאן.

כעת, נסה לגשת לתוכנית מחוץ לאתר היעד בעת איתור באגים והפעלה. למען הפשטות, אני אפרסם הודעה באמצעות כלי שנקרא קוד Visual Studio. אם באפשרותך לשלוח POST, באפשרותך להשתמש בכלים אחרים או לבנות תוכנית אתר אחרת עבור ההתקפה.

בעת התקנת סיומת בשם ' לקוח מנוחה ' בקוד Visual Studio, באפשרותך להשתמש בתכונה המאפשרת לך לבדוק בקלות את הפעולה של ה-API של השאר רק על-ידי פתיחת קובץ ה-. http.

כאשר אתה יוצר קובץ. http הדומה להודעה הבאה בקובץ טקסט ולאחר מכן פותח את הקובץ בקוד Visual Studio, באפשרותך לשלוח את האפשרות קבל או POST על-ידי לחיצה על שלח בקשה.

אם תיצור את נתוני POST הבאים, תישלח כמעט אותה כמות נתונים בעת הקלדת טקסט על המסך ולחיצה על לחצן submit. (מספר היציאה של localhost אמור להיות זהה לסביבת הביצוע.)

מבחן המשך. 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--

כאשר אתה שולח אותו, באפשרותך לראות שהשרת מקבל טקסט ומעבד אותו.

הקוד של Visual Studio יכול לקבל את התוצאות. אם תסתכל מקרוב על קוד התוצאה, תוכל לראות שמוצגת הערך עבור ViewData. (הוא מוצג ב-Unicode, אך הטקסט מוצג כראוי אם מוצג בדפדפן אינטרנט.)

מטפל בפגיעות של בקשה מרובת אתרים בבקשה

כפי שציינתי בהתחלה, ASP.NET Core משלבת צעדים נגד זיוף בקשת האתר במסגרת. מידה נפוצה היא להנפיק אסימון ייחודי ללקוח מראש על המסך המחייב הצבה, וכו '. אינך חייב לקבל את העיבוד אלא אם כן אתה משליך את האסימון לשרת.

כמובן, אם אתה ניגש לכתובת ה-URL ישירות מאתר חיצוני, האסימון אינו ידוע ולא יקבל את העיבוד.

ראשית, אני רוצה לדבר על הנפקת אסימונים ללקוח (HTML), אבל העובדה היא כי המסגרת אינה מסוגלת לעשות זאת. . זה בסדר. אם תציין שיטת POST בתג הטופס, תוכל לשלב פרמטרי token ב-HTML ללא הרשאה.

ב-HTML שלהלן, זהו שם הקלט = "__RequestVerificationToken" type = "מוסתר". פעולה זו נשלחת לשרת יחד עם לחיצה על לחצן השליחה. דרך אגב, הוא אינו מצורף לשיטה ' קבל '.

בצד השרת, שירותי Startup.cs. הקצאת אפשרויות של שיטות תצוגה. מסננים ל באמצעות התכונה ' יישור אוטומטי ', כל הפעולות בדיקת אסימון זו נוספת באופן אוטומטי ל-(כדי לדייק רק בשיטות ה-HTTP של POST, הצבת, PATCH ו-DELETE).

אם ברצונך להוסיף אילוץ זה רק לפעולות מסוימות, לא לכל הפעולות, לכל הקונטרולר, לכל פעולה ניתן גם להגדיר.

לעומת זאת, אם ברצונך לכפות הגבלות על רוב הפעולות, אך ברצונך שלא לכלול פעולות מסוימות, אם תגדיר את התכונה בעיה במניעת המשך לבקר ולפעולה, היא תהיה בסדר.

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());
  });
}

. בוא נראה איך זה עובד קודם כל, תהליך השידור נעשה מהמסך כרגיל.

התוצאות השתקפות על המסך כמצופה.

זהו גם פלט למעקב.

עכשיו, בואו ננסה. לגשת אליו מבחוץ

Access הוחזר, אך הבקשה הרעה הוחזרה. זו תוצאה שונה מאשר. כשאתה לא נוקט באמצעים מובן כי הוא שמור כי זה לא פלט למעקב.

סיכום

הפעם ניסיתי ליישם אמצעים נגד בקשת מרובת אתרים. היה קל מאוד ליישם אותו משום שהוא כבר נבנה במסגרת.

בניית אתר אינטרנט דורשת הרבה יותר פגיעות מאשר CSRF. באפשרותך לבדוק מה יש בחוץ, או להשתמש בכלים כגון OWASP כדי לבדוק אם יש פגיעויות באתר שלך.