يمكن البرنامج الوسيط ASP.NET Core OpenId الاتصال تطبيقك من اعتراض الاستدعاء إلى نقطة نهاية تسجيل الخروج النظام الأساسي للهويات في Microsoft عن طريق توفير حدث OpenId الاتصال المسمىOnRedirectToIdentityProviderForSignOut
استخدام مدة البقاء المحدودة الرموز المميزة لـ SaS التي تم إنشاؤها
العنوان
التفاصيل
المكون
جهاز IoT
مرحلة SDL
بناء
التقنيات المعمول بها
العام
السمات
غير متاح
المراجع
غير متاح
الخطوات
يجب أن يكون لرموز SaS التي تم إنشاؤها للمصادقة على Azure IoT Hub فترة انتهاء صلاحية محدودة. حافظ على عمر رمزية SaS إلى الحد الأدنى للحد من مقدار الوقت الذي يمكن إعادة تشغيله في حالة اختراق الرموز المميزة.
استخدام الحد الأدنى لعمر الرمز المميز للرمز المميزة للمورد الذي تم إنشاؤه
العنوان
التفاصيل
المكون
Azure Cosmos DB
مرحلة SDL
بناء
التقنيات المعمول بها
العام
السمات
غير متاح
المراجع
غير متاح
الخطوات
تقليل الفترة الزمنية للرمز المميز للمورد إلى الحد الأدنى للقيمة المطلوبة. تحتوي الرموز المميزة للموارد على فترة زمنية صالحة افتراضية تبلغ ساعة واحدة.
تنفيذ تسجيل الخروج المناسب باستخدام أساليب WsFederation عند استخدام ADFS
العنوان
التفاصيل
المكون
ADFS
مرحلة SDL
بناء
التقنيات المعمول بها
العام
السمات
غير متاح
المراجع
غير متاح
الخطوات
إذا كان التطبيق يعتمد على رمز STS الذي تم إصداره بواسطة ADFS، فيجب على معالج حدث تسجيل الخروج استدعاء أسلوب WSFederationAuthenticationModule.FederatedSignOut () لتسجيل خروج المستخدم. يجب أيضاً إتلاف جلسة العمل الحالية، ويجب إعادة تعيين قيمة الرمز المميز للجلسة وإبطالها.
مثال
[HttpPost, ValidateAntiForgeryToken]
[Authorization]
public ActionResult SignOut(string redirectUrl)
{
if (!this.User.Identity.IsAuthenticated)
{
return this.View("LogOff", null);
}
// Removes the user profile.
this.Session.Clear();
this.Session.Abandon();
HttpContext.Current.Response.Cookies.Add(new System.Web.HttpCookie("ASP.NET_SessionId", string.Empty)
{
Expires = DateTime.Now.AddDays(-1D),
Secure = true,
HttpOnly = true
});
// Signs out at the specified security token service (STS) by using the WS-Federation protocol.
Uri signOutUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Issuer);
Uri replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm);
if (!string.IsNullOrEmpty(redirectUrl))
{
replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm + redirectUrl);
}
// Signs out of the current session and raises the appropriate events.
var authModule = FederatedAuthentication.WSFederationAuthenticationModule;
authModule.SignOut(false);
// Signs out at the specified security token service (STS) by using the WS-Federation
// protocol.
WSFederationAuthenticationModule.FederatedSignOut(signOutUrl, replyUrl);
return new RedirectResult(redirectUrl);
}
تنفيذ تسجيل الخروج المناسب عند استخدام Identity Server
يدعم IdentityServer القدرة على الاتحاد مع موفري الهوية الخارجيين. عندما يسجّل المستخدم خروجه من موفر هوية أولية، اعتماداً على البروتوكول المستخدم، قد يكون من الممكن تلقي إشعار عند تسجيل خروج المستخدم. يسمح لـ IdentityServer بإخطار عملائها حتى يتمكنوا أيضاً من تسجيل خروج المستخدم. تحقق من الوثائق في قسم المراجع للحصول على تفاصيل التنفيذ.
يجب أن تستخدم التطبيقات المتوفرة عبر HTTPS ملفات تعريف الارتباط الآمنة
عادةً ما تكون ملفات تعريف الارتباط متاحة فقط للمجال الذي تم تحديد نطاقها من أجله. لسوء الحظ، لا يتضمن تعريف "المجال" البروتوكول لذلك يمكن الوصول إلى ملفات تعريف الارتباط التي يتم إنشاؤها عبر HTTPS عبر HTTP. تشير سمة "آمن" للمتصفح إلى أن ملف تعريف الارتباط يجب أن يكون متاحاً فقط عبر HTTPS. تأكد من أن جميع ملفات تعريف الارتباط التي تم تعيينها عبر HTTPS تستخدم السمة آمن. يمكن فرض المطلب في ملف web.config عن طريق تعيين السمة requireSSL إلى صواب. إنه النهج المفضل لأنه سيفرض السمة آمن لجميع ملفات تعريف الارتباط الحالية والمستقبلية دون الحاجة إلى إجراء أي تغييرات إضافية في التعليمات البرمجية.
يتم فرض الإعداد حتى إذا تم استخدام HTTP للوصول إلى التطبيق. إذا تم استخدام HTTP للوصول إلى التطبيق، فإن الإعداد يقاطع التطبيق لأنه تم تعيين ملفات تعريف الارتباط بالسمة الآمنة ولن يرسلها المتصفح مرة أخرى إلى التطبيق.
العنوان
التفاصيل
المكون
تطبيق ويب
مرحلة SDL
بناء
التقنيات المعمول بها
نماذج ويب، MVC5
السمات
EnvironmentType - OnPrem
المراجع
غير متاح
الخطوات
عندما يكون تطبيق الويب هو جهة الاعتماد، ومعرف الهوية هو خادم ADFS، يمكن تكوين السمة الآمنة للرمز المميز FedAuth عن طريق الإعداد يتطلبSSL إلى True في system.identityModel.services قسم من web.config:
مثال
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:20:0" />
....
</federationConfiguration>
</system.identityModel.services>
يجب أن تحدد التطبيقات المستندة إلى http جميعها http فقط لتعريف ملف تعريف الارتباط
للتخفيف من مخاطر الكشف عن المعلومات من خلال هجوم البرمجة النصية عبر المواقع (XSS)، تم تقديم سمة جديدة - httpOnly - لملفات تعريف الارتباط وهي مدعومة من قبل جميع المتصفحات الرئيسية. تحدد السمة أنه لا يمكن الوصول إلى ملف تعريف الارتباط من خلال البرنامج النصي. باستخدام ملفات تعريف الارتباط HttpOnly، يقلل تطبيق الويب من احتمالية سرقة المعلومات الحساسة الموجودة في ملف تعريف الارتباط عبر البرنامج النصي وإرسالها إلى موقع الويب الخاص بالمهاجم.
مثال
يجب أن تحدد جميع التطبيقات المستندة إلى HTTP والتي تستخدم ملفات تعريف الارتباط HttpOnly في تعريف ملف تعريف الارتباط، من خلال تنفيذ التكوين التالي في web.config:
يتم تعيين قيمة الخاصية RequireSSL في ملف التكوين لتطبيق ASP.NET باستخدام سمة requiredSSL لعنصر التكوين. يمكنك تحديد في ملف Web.config لتطبيق ASP.NET الخاص بك ما إذا كان Transport Layer Security (TLS)، المعروف سابقاً باسم SSL (طبقة مآخذ التوصيل الآمنة)، مطلوباً لإرجاع ملف تعريف ارتباط مصادقة النماذج إلى الخادم عن طريق تعيين سمة requiredSSL.
مثال
يعين مثال التعليمات البرمجية التالي السمة requireSSL في ملف Web.config.
التخفيف من هجمات تزييف الطلبات عبر المواقع (CSRF) على صفحات الويب ASP.NET
العنوان
التفاصيل
المكون
تطبيق ويب
مرحلة SDL
بناء
التقنيات المعمول بها
العام
السمات
غير متاح
المراجع
غير متاح
الخطوات
تزييف طلب المواقع المشتركة (CSRF أو XSRF) هو نوع من الهجوم يمكن للمهاجم فيه تنفيذ إجراءات في سياق الأمان لجلسة مستخدم مختلفة على موقع ويب. الهدف هو تعديل أو حذف المحتوى، إذا كان الموقع المستهدف يعتمد حصرياً على ملفات تعريف الارتباط الخاصة بالجلسة لمصادقة الطلب المستلم. يمكن للمهاجم استغلال مشكلة عدم الحصانة هذه عن طريق الحصول على مستعرض مستخدم مختلف لتحميل عنوان URL بأمر من موقع ضعيف قام المستخدم بتسجيل الدخول إليه بالفعل. هناك العديد من الطرق التي يمكن للمهاجم القيام بذلك، مثل استضافة موقع ويب مختلف يقوم بتحميل مورد من الخادم الضعيف، أو جعل المستخدم ينقر فوق ارتباط. يمكن منع الهجوم إذا كان الخادم يرسل رمز مميز إضافي إلى العميل، يتطلب العميل لتضمين هذا الرمز المميز في كافة الطلبات المستقبلية، ويتحقق من أن كافة الطلبات المستقبلية تتضمن رمز مميز يتعلق بجلسة العمل الحالية، مثل باستخدام antiForgeryToken أو ViewState ASP.NET.
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
مثال
في الوقت نفسه، يمنح Html.AntiForgeryToken () للزائر ملف تعريف ارتباط يسمى __RequestVerificationToken، بنفس قيمة القيمة المخفية العشوائية الموضحة أعلاه. بعد ذلك، للتحقق من صحة منشور نموذج واردة، إضافة عامل التصفية [ValidateAntiForgeryToken] إلى أسلوب الإجراء الهدف. على سبيل المثال:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
عامل تصفية التخويل الذي يتحقق من ما يلي:
يحتوي الطلب الوارد على ملف تعريف ارتباط يسمى __RequestVerificationToken
يحتوي الطلب الوارد على Request.Form إدخال يسمى __RequestVerificationToken
تتطابق ملفات تعريف الارتباط Request.Form والقيم هذه مع افتراض أن كل شيء على ما يرام، ويمر الطلب كالمعتاد. ولكن إذا لم يكن الأمر صحيحاً، فإن فشل التخويل مع الرسالة "لم يتم توفير رمز مميز مطلوب لمكافحة التزييف أو كان غير صالح".
مثال
Anti-CSRF و AJAX: يمكن أن يمثل الرمز المميز للنموذج مشكلة لطلبات AJAX، لأن طلب AJAX قد يرسل بيانات JSON، وليس بيانات نموذج HTML. أحد الحلول هو إرسال الرموز المميزة في عنوان HTTP مخصص. التعليمات البرمجية التالية يستخدم بناء الجملة Razor لإنشاء الرموز المميزة ثم يضيف الرموز المميزة إلى طلب AJAX.
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
مثال
عند معالجة الطلب استخراج الرموز المميزة من عنوان الطلب. ثم قم باستدعاء الأسلوب AntiForgery.Validate للتحقق من صحة الرموز المميزة. يطرح أسلوب التحقق استثناء إذا كانت الرموز المميزة غير صالحة.
يمكن التخفيف من هجمات CSRF في التطبيقات المستندة إلى WebForm عن طريق تعيين ViewStateUserKey على سلسلة عشوائية تختلف لكل مستخدم - معرف المستخدم أو، الأفضل من ذلك، معرف الجلسة. ولأسباب فنية واجتماعية، يعد معرف الجلسة مناسبا بشكل أفضل لأن معرف الجلسة لا يمكن التنبؤ به، وينتهى، ويختلف على أساس كل مستخدم.
مثال
إليك الرمز الذي تحتاج إلى الحصول عليه في جميع صفحاتك:
يمثل مهلة جلسة العمل الحدث الذي يحدث عندما لا يقوم المستخدم بتنفيذ أي إجراء على موقع ويب أثناء فاصل زمني (معرف بواسطة خادم ويب). يغير الحدث، على جانب الخادم، حالة جلسة عمل المستخدم إلى "غير صالح" (على سبيل المثال "لم يتم استخدامه بعد الآن") ويوجه خادم الويب لإتلافه (حذف جميع البيانات الموجودة فيه). يعيّن مثال التعليمات البرمجية التالي سمة جلسة المهلة إلى 15 دقيقة في ملف Web.config.
عندما يكون تطبيق الويب Relying Party و ADFS هو STS، يمكن تعيين عمر ملفات تعريف الارتباط للمصادقة - الرموز المميزة FedAuth - من خلال التكوين التالي في web.config:
مثال
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:15:0" />
<!-- Set requireHttps=true; -->
<wsFederation passiveRedirectEnabled="true" issuer="http://localhost:39529/" realm="https://localhost:44302/" reply="https://localhost:44302/" requireHttps="true"/>
<!--
Use the code below to enable encryption-decryption of claims received from ADFS. Thumbprint value varies based on the certificate being used.
<serviceCertificate>
<certificateReference findValue="4FBBBA33A1D11A9022A5BF3492FF83320007686A" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
</serviceCertificate>
-->
</federationConfiguration>
</system.identityModel.services>
مثال
يجب أيضاً تعيين عمر رمز مطالبة SAML الذي أصدره ADFS على 15 دقيقة، عن طريق تنفيذ أمر powerhell التالي على خادم ADFS:
قم بإجراء تسجيل الخروج الصحيح من التطبيق، عندما يضغط المستخدم على زر تسجيل الخروج. عند تسجيل الخروج، يجب أن يدمر التطبيق جلسة عمل المستخدم، كما يقوم بإعادة تعيين قيمة ملف تعريف ارتباط جلسة العمل وإبطالها، بالإضافة إلى إعادة تعيين قيمة ملف تعريف الارتباط للمصادقة وإبطالها. أيضاً، عند ربط جلسات عمل متعددة إلى هوية مستخدم واحد، يجب إنهاء بشكل جماعي على جانب الخادم في المهلة أو تسجيل الخروج. وأخيراً، تأكد من توفر وظيفة تسجيل الخروج على كل صفحة.
التخفيف من هجمات تزييف الطلبات عبر المواقع (CSRF) على واجهات برمجة تطبيقات الويب ASP.NET
العنوان
التفاصيل
المكون
واجهة API للويب
مرحلة SDL
بناء
التقنيات المعمول بها
العام
السمات
غير متاح
المراجع
غير متاح
الخطوات
تزييف طلب المواقع المشتركة (CSRF أو XSRF) هو نوع من الهجوم يمكن للمهاجم فيه تنفيذ إجراءات في سياق الأمان لجلسة مستخدم مختلفة على موقع ويب. الهدف هو تعديل أو حذف المحتوى، إذا كان الموقع المستهدف يعتمد حصرياً على ملفات تعريف الارتباط الخاصة بالجلسة لمصادقة الطلب المستلم. يمكن للمهاجم استغلال مشكلة عدم الحصانة هذه عن طريق الحصول على مستعرض مستخدم مختلف لتحميل عنوان URL بأمر من موقع ضعيف قام المستخدم بتسجيل الدخول إليه بالفعل. هناك العديد من الطرق التي يمكن للمهاجم القيام بذلك، مثل استضافة موقع ويب مختلف يقوم بتحميل مورد من الخادم الضعيف، أو جعل المستخدم ينقر فوق ارتباط. يمكن منع الهجوم إذا كان الخادم يرسل رمز مميز إضافي إلى العميل، يتطلب العميل لتضمين هذا الرمز المميز في كافة الطلبات المستقبلية، ويتحقق من أن كافة الطلبات المستقبلية تتضمن رمز مميز يتعلق بجلسة العمل الحالية، مثل باستخدام antiForgeryToken أو ViewState ASP.NET.
Anti-CSRF و AJAX: يمكن أن يمثل الرمز المميز للنموذج مشكلة لطلبات AJAX، لأن طلب AJAX قد يرسل بيانات JSON، وليس بيانات نموذج HTML. أحد الحلول هو إرسال الرموز المميزة في عنوان HTTP مخصص. التعليمات البرمجية التالية يستخدم بناء الجملة Razor لإنشاء الرموز المميزة ثم يضيف الرموز المميزة إلى طلب AJAX.
مثال
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
مثال
عند معالجة الطلب استخراج الرموز المميزة من عنوان الطلب. ثم قم باستدعاء الأسلوب AntiForgery.Validate للتحقق من صحة الرموز المميزة. يطرح أسلوب التحقق استثناء إذا كانت الرموز المميزة غير صالحة.
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
مثال
في الوقت نفسه، يمنح Html.AntiForgeryToken () للزائر ملف تعريف ارتباط يسمى __RequestVerificationToken، بنفس قيمة القيمة المخفية العشوائية الموضحة أعلاه. بعد ذلك، للتحقق من صحة منشور نموذج واردة، إضافة عامل التصفية [ValidateAntiForgeryToken] إلى أسلوب الإجراء الهدف. على سبيل المثال:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
عامل تصفية التخويل الذي يتحقق من ما يلي:
يحتوي الطلب الوارد على ملف تعريف ارتباط يسمى __RequestVerificationToken
يحتوي الطلب الوارد على Request.Form إدخال يسمى __RequestVerificationToken
تتطابق ملفات تعريف الارتباط Request.Form والقيم هذه مع افتراض أن كل شيء على ما يرام، ويمر الطلب كالمعتاد. ولكن إذا لم يكن الأمر صحيحاً، فإن فشل التخويل مع الرسالة "لم يتم توفير رمز مميز مطلوب لمكافحة التزييف أو كان غير صالح".
العنوان
التفاصيل
المكون
واجهة API للويب
مرحلة SDL
بناء
التقنيات المعمول بها
MVC5، MVC6
السمات
موفر الهوية - ADFS، موفر الهوية - معرف Microsoft Entra
إذا كانت واجهة برمجة تطبيقات الويب مؤمنة باستخدام OAuth 2.0، فإنها تتوقع رمزاً لحاملها في رأس طلب التفويض ولا تمنح حق الوصول إلى الطلب إلا إذا كان الرمز المميز صالحاً. على عكس المصادقة القائمة على ملف تعريف الارتباط، لا تقوم المتصفحات بإرفاق الرموز المميزة لحاملها بالطلبات. يحتاج العميل الطالب إلى إرفاق رمز الحامل بشكل صريح في رأس الطلب. لذلك، بالنسبة لواجهات برمجة تطبيقات الويب ASP.NET المحمية باستخدام OAuth 2.0، تعتبر الرموز المميزة لحاملها بمثابة دفاع ضد هجمات CSRF. يرجى ملاحظة أنه إذا كان جزء MVC من التطبيق يستخدم مصادقة النماذج (أي يستخدم ملفات تعريف الارتباط)، فيجب استخدام الرموز المميزة لمكافحة التزوير بواسطة تطبيق الويب MVC.
مثال
يجب إبلاغ واجهة برمجة تطبيقات الويب للاعتماد فقط على الرموز المميزة لحاملها وليس على ملفات تعريف الارتباط. يمكن أن يتم ذلك عن طريق التكوين التالي في WebApiConfig.Register الطريقة:
تقوم طريقة SuppressDefaultHostAuthentication بإخبار Web API بتجاهل أي مصادقة تحدث قبل أن يصل الطلب إلى خط أنابيب Web API، إما عن طريق IIS أو عن طريق OWIN الوسيطة. بهذه الطريقة، يمكننا تقييد واجهة برمجة تطبيقات الويب للمصادقة فقط باستخدام الرموز المميزة لحاملها.
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجع https://aka.ms/ContentUserFeedback.