إطار الأمان: إدارة الاستثناءات | التخفيفات

المنتج /الخدمة مقالة
WCF
API للويب
تطبيق الويب

WCF- لا تقم بتضمين عقدة serviceDebug في ملف التكوين

العنوان التفاصيل
المكون WCF
مرحلة SDL البنية
التقنيات المعمول بها عام، NET Framework 3
السمات غير متوفر
المراجع MSDN، Fortify Kingdom
‏‏الخطوات يمكن تكوين خدمات Windows Communication Framework (WCF) لعرض معلومات التصحيح. يجب عدم استخدام معلومات التصحيح في بيئات الإنتاج. تحدد العلامة <serviceDebug> ما إذا تم تمكين ميزة معلومات التصحيح لخدمة WCF. إذا تم تعيين السمة includeExceptionDetailInFaults على true، فسيتم إرجاع معلومات الاستثناء من التطبيق إلى العملاء. يمكن للمهاجمين الاستفادة من المعلومات الإضافية التي يكتسبونها من إخراج التصحيح لشن هجمات تستهدف إطار العمل أو قاعدة البيانات أو الموارد الأخرى التي يستخدمها التطبيق.

مثال

يشتمل ملف التكوين التالي على علامة <serviceDebug>:

<configuration> 
<system.serviceModel> 
<behaviors> 
<serviceBehaviors> 
<behavior name=""MyServiceBehavior""> 
<serviceDebug includeExceptionDetailInFaults=""True"" httpHelpPageEnabled=""True""/> 
... 

تعطيل معلومات التصحيح في الخدمة. يمكن تحقيق ذلك عن طريق إزالة علامة <serviceDebug> من ملف تكوين التطبيق الخاص بك.

WCF- لا تقم بتضمين عقدة serviceMetadata في ملف التكوين

العنوان التفاصيل
المكون WCF
مرحلة SDL البنية
التقنيات القابلة للتطبيق العام
السمات عام، NET Framework 3
المراجع MSDN، Fortify Kingdom
‏‏الخطوات يمكن أن يوفر الكشف العلني لمعلومات بشأن خدمة ما للمهاجمين نتائج تحليلات قيمة بشأن كيفية استغلالهم للخدمة. تمكّن العلامة <serviceMetadata> ميزة نشر بيانات التعريف. قد تحتوي بيانات التعريف للخدمة على معلومات حساسة لا ينبغي أن تكون متاحة للجمهور. كحد أدنى، اسمح فقط للمستخدمين الموثوق بهم بالوصول إلى بيانات التعريف وتأكد من عدم كشف المعلومات غير الضرورية. والأفضل من ذلك، قم بتعطيل القدرة على نشر بيانات التعريف تماماً. لن يحتوي تكوين WCF الآمن على علامة <serviceMetadata>.

تأكد من إجراء المعالجة المناسبة للاستثناءات في ASP.NET Web API

العنوان التفاصيل
المكون API للويب
مرحلة SDL البنية
التقنيات المعمول بها MVC 5، MVC 6
السمات غير متوفر
المراجع معالجة الاستثناءات في ASP.NET Web API ، التحقق من النموذج في ASP.NET Web API
‏‏الخطوات بشكل افتراضي، تتم ترجمة معظم الاستثناءات غير المعلومة في ASP.NET Web API إلى استجابة HTTP بتعليمة برمجية الحالة 500, Internal Server Error

مثال

للتحكم في تعليمة برمجية الحالة الذي تعرضه واجهة برمجة التطبيقات، يمكن استخدام HttpResponseException كما هو موضح أدناه:

public Product GetProduct(int id)
{
    Product item = repository.Get(id);
    if (item == null)
    {
        throw new HttpResponseException(HttpStatusCode.NotFound);
    }
    return item;
}

مثال

لمزيد من التحكم في استجابة الاستثناء، يمكن استخدام الفئة HttpResponseMessage كما هو موضح أدناه:

public Product GetProduct(int id)
{
    Product item = repository.Get(id);
    if (item == null)
    {
        var resp = new HttpResponseMessage(HttpStatusCode.NotFound)
        {
            Content = new StringContent(string.Format("No product with ID = {0}", id)),
            ReasonPhrase = "Product ID Not Found"
        }
        throw new HttpResponseException(resp);
    }
    return item;
}

للقبض على الاستثناءات التي لم تتم معالجتها والتي ليست من النوع HttpResponseException، يمكن استخدام عوامل تصفية الاستثناءات. تقوم عوامل تصفية الاستثناء بتنفيذ واجهة System.Web.Http.Filters.IExceptionFilter. إن أبسط طريقة لكتابة عامل تصفية الاستثناءات هي الاشتقاق من الفئة System.Web.Http.Filters.ExceptionFilterAttribute وتجاوز طريقة OnException.

مثال

فيما يلي عامل تصفية يحول NotImplementedException الاستثناءات إلى رمز حالة HTTP 501, Not Implemented:

namespace ProductStore.Filters
{
    using System;
    using System.Net;
    using System.Net.Http;
    using System.Web.Http.Filters;

    public class NotImplExceptionFilterAttribute : ExceptionFilterAttribute 
    {
        public override void OnException(HttpActionExecutedContext context)
        {
            if (context.Exception is NotImplementedException)
            {
                context.Response = new HttpResponseMessage(HttpStatusCode.NotImplemented);
            }
        }
    }
}

توجد عدة طرق لتسجيل عامل تصفية استثناءات واجهة برمجة تطبيقات الويب:

  • عن طريق العمل
  • بواسطة تحكم
  • عالميا

مثال

لتطبيق عامل التصفية على إجراء معين، أضف عامل التصفية كسمة للإجراء:

public class ProductsController : ApiController
{
    [NotImplExceptionFilter]
    public Contact GetContact(int id)
    {
        throw new NotImplementedException("This method is not implemented");
    }
}

مثال

لتطبيق عامل التصفية على جميع الإجراءات في controller, add the filter as an attribute to the controller:

[NotImplExceptionFilter]
public class ProductsController : ApiController
{
    // ...
}

مثال

لتطبيق عامل التصفية بشكل عام على جميع وحدات تحكم Web API، أضف مثيلاً لعامل التصفية إلى مجموعة GlobalConfiguration.Configuration.Filters. تنطبق عوامل تصفية الاستثناءات في هذه المجموعة على أي إجراء وحدة تحكم Web API.

GlobalConfiguration.Configuration.Filters.Add(
    new ProductStore.NotImplExceptionFilterAttribute());

مثال

للتحقق من صحة النموذج، يمكن تمرير حالة النموذج إلى طريقة CreateErrorResponse كما هو موضح أدناه:

public HttpResponseMessage PostProduct(Product item)
{
    if (!ModelState.IsValid)
    {
        return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
    }
    // Implementation not shown...
}

تحقق من الروابط في قسم المراجع للحصول على تفاصيل إضافية بشأن المعالجة الاستثنائية والتحقق من صحة النموذج في ASP.NET Web API

لا تكشف تفاصيل الأمان في رسائل الخطأ

العنوان التفاصيل
المكون تطبيق الويب
مرحلة SDL البنية
التقنيات القابلة للتطبيق العام
السمات غير متوفر
المراجع غير متوفر
‏‏الخطوات

يتم تقديم رسائل الخطأ العامة مباشرة إلى المستخدم دون تضمين بيانات التطبيق الحساسة. تتضمن أمثلة البيانات الحساسة ما يلي:

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

يساعد حجز جميع الأخطاء داخل التطبيق وتقديم رسائل خطأ عامة، بالإضافة إلى تمكين الأخطاء المخصصة داخل IIS على منع الكشف عن المعلومات. تعد قاعدة بيانات SQL Server ومعالجة استثناءات .NET، من بين بنيات معالجة الأخطاء الأخرى، مطولة ومفيدة للغاية للمستخدم الضار الذي يقوم بإعداد ملفات تعريف للتطبيق الخاص بك. لا تعرض محتويات فئة مشتقة من فئة .NET Exception بشكل مباشر، وتأكد من أن لديك معالجة مناسبة للاستثناء حتى لا يتم عرض استثناء غير متوقع عن غير قصد للمستخدم مباشرة.

  • قدِّم رسائل خطأ عامة مباشرةً إلى المستخدم تلخص التفاصيل المحددة الموجودة مباشرةً في رسالة الاستثناء/الخطأ
  • لا تعرض محتويات فئة استثناء .NET مباشرة للمستخدم
  • اعتراض جميع رسائل الخطأ وإبلاغ المستخدم، إذا كان ذلك مناسباً، عبر رسالة خطأ عامة يتم إرسالها إلى عميل التطبيق
  • لا تعرض محتويات فئة الاستثناء مباشرة للمستخدم، وخاصة قيمة الإرجاع من .ToString()، أو قيم خصائص الرسائل أو StackTrace. قم بتسجيل هذه المعلومات بشكل آمن وعرض رسالة غير ضارة للمستخدم

تنفيذ صفحة معالجة الأخطاء الافتراضية

العنوان التفاصيل
المكون تطبيق الويب
مرحلة SDL البنية
التقنيات القابلة للتطبيق العام
السمات غير متوفر
المراجع مربع الحوار تحرير إعدادات صفحات خطأ ASP.NET
‏‏الخطوات

عندما يفشل تطبيق ASP.NET ويتسبب في حدوث خطأ داخلي في الخادم HTTP/1.x 500، أو يمنع تكوين ميزة (مثل تصفية الطلب) صفحة من العرض، سيتم إنشاء رسالة خطأ. يمكن للمسؤولين اختيار ما إذا كان يجب على التطبيق عرض رسالة ودية للعميل أم لا، أو رسالة خطأ مفصلة إلى العميل، أو رسالة خطأ مفصلة إلى المضيف المحلي فقط. للعلامة <customErrors> الموجودة في web.config ثلاثة أوضاع:

  • تشغيل: يحدد تمكين الأخطاء المخصصة. إذا لم يتم تحديد سمة defaultRedirect، فسيرى المستخدمون خطأً عاماً. تظهر الأخطاء المخصصة للعملاء البعيدين والمضيف المحلي
  • إيقاف: يحدد أن الأخطاء المخصصة معطلة. تظهر أخطاء ASP.NET المفصلة للعملاء البعيدين والمضيف المحلي
  • RemoteOnly: يحدد عرض الأخطاء المخصصة للعملاء البعيدين فقط، وأن أخطاء ASP.NET تظهر للمضيف المحلي. هذه هي القيمة الافتراضية

افتح ملف web.config file for the application/site and ensure that the tag has either <customErrors mode="RemoteOnly" /> أو <customErrors mode="On" />.

تعيين أسلوب التوزيع للبيع بالتجزئة في IIS

العنوان التفاصيل
المكون تطبيق الويب
مرحلة SDL توزيع
التقنيات القابلة للتطبيق العام
السمات غير متوفر
المراجع عنصر التوزيع (مخطط إعدادات ASP.NET)
‏‏الخطوات

تم تصميم رمز التبديل <deployment retail> للاستخدام بواسطة خوادم IIS الإنتاجية. يتم استخدام رمز التبديل هذا لمساعدة التطبيقات على العمل بأفضل أداء ممكن وأقل تسرب ممكن لمعلومات الأمان عن طريق تعطيل قدرة التطبيق على إنشاء مخرجات التتبع على الصفحة، وتعطيل القدرة على عرض رسائل خطأ مفصلة للمستخدمين النهائيين، وتعطيل مفتاح تصحيح الأخطاء.

في كثير من الأحيان، يتم تمكين المفاتيح والخيارات التي تركز على المطورين، مثل تتبع الطلبات الفاشلة وتصحيح الأخطاء، أثناء التطوير النشط. من المستحسن أن يتم تعيين طريقة التوزيع على أي خادم إنتاج إلى البيع بالتجزئة. افتح ملف machine.config وتأكد من أن <deployment retail="true" /> يظل مضبوطاً على "صحيح".

يجب أن تفشل الاستثناءات بأمان

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

مثال

        public static bool ValidateDomain(string pathToValidate, Uri currentUrl)
        {
            try
            {
                if (!string.IsNullOrWhiteSpace(pathToValidate))
                {
                    var domain = RetrieveDomain(currentUrl);
                    var replyPath = new Uri(pathToValidate);
                    var replyDomain = RetrieveDomain(replyPath);

                    if (string.Compare(domain, replyDomain, StringComparison.OrdinalIgnoreCase) != 0)
                    {
                        //// Adding additional check to enable CMS urls if they are not hosted on same domain.
                        if (!string.IsNullOrWhiteSpace(Utilities.CmsBase))
                        {
                            var cmsDomain = RetrieveDomain(new Uri(Utilities.Base.Trim()));
                            if (string.Compare(cmDomain, replyDomain, StringComparison.OrdinalIgnoreCase) != 0)
                            {
                                return false;
                            }
                            else
                            {
                                return true;
                            }
                        }

                        return false;
                    }
                }

                return true;
            }
            catch (UriFormatException ex)
            {
                LogHelper.LogException("Utilities:ValidateDomain", ex);
                return true;
            }
        }

ستعيد الطريقة أعلاه دائماً True، في حالة حدوث بعض الاستثناءات. إذا قدم المستخدم عنوان URL مشوهاً، يحترمه المتصفح، ولكن Uri() لا يفعل ذلك، فسيؤدي ذلك إلى استثناء، وسيتم نقل الضحية إلى عنوان URL صالح ولكنه غير صحيح.