مشاركة عبر

تغييرات الأمان في .NET Framework 4

  • مقالة

لقد حدث تغييران رئيسيان للأمان في .NET Framework الإصدار 4. لقد تم التخلص من السياسة على مستوى الجهاز، على الرغم من بقاء نظام الأذونات في مكانه، و أصبحت شفافية الأمان الآلية الافتراضية لفرض الأمان. لمزيد من المعلومات، راجع التعليمات البرمجية الشفافة أمنياً، المستوى 2. بالإضافة إلى ذلك، لقد تم إهمال بعض العمليات المتعلقة بالأذونات والتي كانت تؤدي إلى إحتمال وجود ثغرات أمنية.

يجب أن تكون على علم بالنقاط الأساسية التالية:

  • تقوم الشفافية بفصل التعليمات البرمجية التي يتم تشغيلها كجزء من التطبيق من التعليمات البرمجية التي يتم تشغيلها كجزء من البنية التحتية. تم تقديمها في NET Framework. الإصدار 2.0، و قد تم تحسينها لتصبح آلية فرض الأمان التي تسمى أمان الوصول إلى التعليمات البرمجية. و بخلاف سياسة الأمان، يتم تطبيق قواعد الشفافية من المستوى 2 في وقت التشغيل، و ليس في وقت تحميل التجميع. تسرى هذه القواعد دائماً، حتى بالنسبة للتجميعات التي يتم تشغيلها في وضع الثقة الكاملة بشكل افتراضي. ومع ذلك، لا تؤثر الشفافية من المستوى 2 على التعليمات البرمجية الموثوق بها ثقة تامة و التي لم يتم عمل تعليق توضيحي لها مثل تطبيقات سطح المكتب. التجميعات (بما في ذلك تجميعات سطح المكتب) و التي تم وضع علامة SecurityTransparentAttribute عليها و أساليب طلب الاستدعاء و التي تم وضع علامة SecurityCriticalAttribute تتلقي MethodAccessException. يمكنك تغيير هذا السلوك عن طريق تطبيق SecurityRulesAttribute وإعداد الخاصية SecurityRulesAttribute.RuleSet على Level1; ومع ذلك، يجب عليك القيام بهذا الإجراء فقط من أجل ‏‫التوافق مع الإصدارات السابقة. و يجب عليك بشكل صريح وضع علامة security-transparent (شفاف أمنياً) على تطبيق سطح المكتب لتطبيق قيود الشفافية عليه.

  • تتلقى التعليمات البرمجية التي تستدعي واجهات API خاصة بنهج الأمان NotSupportedException بالإضافة إلى تحذيرات برنامج التحويل البرمجي أثناء وقت التشغيل. قد يمكنك إعادة تمكين السياسة باستخدام عنصر التكوين <NetFx40_LegacySecurityPolicy> عندما تمكّن السياسة، لا تزال شفافية الأمان تسري. يتم تطبيق سياسة الأمان في وقت تحميل التجميع و ليس لها أي تأثير على الشفافية، و التي يتم فرضها بواسطة بيئة وقت التشغيل.

  • الأذونات الطلب قديمة ( RequestMinimum، RequestOptional، و RequestRefuse) ظهور تحذيرات المحول البرمجي ولا تعمل في .NET Framework 4، إلا أنها لا تؤدي باستثناء أن تم طرح. Denyيطلب السببNotSupportedExceptionأن تم طرح في وقت التشغيل.

  • لا يُعد إجراء الأمان LinkDemand مُهملاً، ولكن لا يجب استخدامه للتحقق من الأذونات. بدلاً من ذلك، استخدم SecurityCriticalAttribute للأنواع والأساليب التي تتطلب الثقة الكاملة، أو استخدم الأسلوب Demand للأنواع والأساليب التي تتطلب أذونات فردية.

  • إذا تم بناء التطبيق الخاص بك باستخدام Visual Studio 2010، يمكنك تشغيله بدون هذه التغييرات بتحديد إصدار .NET Framework مستهدف و يكون أقدم من .NET Framework 4 في إعدادات المشروع الخاصة بـ Visual Studio. ومع ذلك، لن تكون قادراً على استخدام الأنواع والأساليب الجديدة في .NET Framework 4. يمكنك أيضاً تحديد إصدار سابق من برنامج .NET Framework باستخدام عنصر <supportedRuntime> في مخطط إعدادات بدء التشغيل في ملف التكوين الخاص بالتطبيق الخاص بك.

تناقش المقاطع التالية ذلك و أيضاً التغييرات الأخرى في .NET Framework 4: 

  • تبسيط سياسة الأمان

  • شفافية الأمان من المستوى 2

  • طلبات الأذونات المُهملة

  • APTCA الشرطية

  • كائنات الدليل

  • مجموعات الدليل

تبسيط سياسة الأمان

بدءاً من .NET Framework 4، تبتعد بيئة وقت تشغيل اللغة العامة (CLR) عن توفير سياسة الأمان لأجهزة الكمبيوتر. من الناحية التاريخية، لقد قامت .NET Framework بتوفير سياسة أمان الوصول إلى التعليمات البرمجية (CAS) كآلية للتحكم بشكل قوي وتكوين قدرات التعليمات البرمجية المُدارة. على الرغم من فعالية سياسة CAS، يمكنها أن تكون مُعقدة و شديدة التقييد. وعلاوة على ذلك، لا يتم تطبيق سياسة CAS على التطبيقات الأصلية، و لذلك فإن ضمانات الأمان الخاصة بها محدودة. يجب على مسؤولو النظام النظر إلى الحلول على مستوى نظام التشغيل مثل سياسات تقييد البرامج الخاصة بـ Windows (SRP) أو AppLocker على أنظمة Windows 7 و Windows Server 2008 R2 كبديل لسياية CAS. توفر سياسات SRP و AppLocker آليات بسيطة للثقة و التي تُطبّق على التعليمات البرمجية المُدارة والتعليمات البرمجية الأصلية. عند استخدامها كحلول لسياسة الامان، تُعد SRP و AppLocker أبسط وتوفر ضمانات أمنية أفضل من CAS.

في .NET Framework 4، يتم إيقاف تشغيل سياسة الأمان على مستوى الجهاز بشكل افتراضي. التطبيقات التي لا يتم استضافتها (أي، التطبيقات التي يتم تنفيذها من خلال مستكشف Windows أو من خلال موجه الأوامر) يتم تشغيلها بوضع الثقة الكاملة. يتضمن ذلك كل التطبيقات الموجودة على مجلدات المشاركات على الشبكة المحلية. التطبيقات التي تتم استضافتها أو تلك التي تعمل ضمن ‏‫آلية تحديد الصلاحيات‬ تستمر في استخدام سياسات الثقة و التي يتم تقريرها من قِبل المًضيفين (على سبيل المثال، بواسطة Internet Explorer، أو ClickOnce، أو ASP.NET). التطبيقات أو عناصر التحكم التي تعمل ضمن ‏‫آلية تحديد الصلاحيات تُعتبر موثوق بها جزئيًا.

ولتبسيط سياسة الأمان، تم تطبيق نموذج الشفافية على .NET Framework. عناصر التحكم التي يتم تشغيلها في المضيف أو آلية تحديد الصلاحيات بمجموعة أذونات محدودة تم منحها بواسطة آلية تحديد الصلاحيات تُعتبر شفافة. تعني الشفافية أنه لا يجب عليك القلق حول التحقق من سياسة CAS عندما تشغل تطبيقات موثوق بها جزئيًا. تعمل التطبيقات الشفافة باستخدام مجموعة الأذونات الممنوحة الخاصة بهم. و كمبرمج، يجب أن يكون اهتمامك الأساسي هو أن تعمل التطبيقات الخاصة بك باستخدام مجموعة الأذونات الممنوحة لآلية تحديد الصلاحيات الخاصة بها ومن أنها لا تقوم بطلب استدعاء تعليمات برمجية تتطلب الثقة الكاملة (تعليمات برمجية حرجة أمنياً).

ملاحظة هامةهام

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

يمكنك تجنب التحذيرات والأخطاء باستخدامعنصر التكوين <NetFx40_LegacySecurityPolicy في مخطط إعدادات بيئة وقت التشغيل للرجوع إلى سلوك سياسة CAS المُهملة.ومع ذلك، عند تحديد استخدام سياسة الأمان القديمة لا يتضمن ذلك أي سياسة CAS مخصصة لهذا الإصدار ما لم يتم نقلها إلى .NET Framework 4.

يمكنك أيضاً تمكين سياسة CAS القديمة بواسطة ضبط إصدار .NET Framework لمشروع Visual Studio الخاص بك على إصدار سابق للإصدار .NET Framework 4. يمكّن ذلك سياسة CAS القديمة ويتضمن أي سياسات CAS مخصصة تم تحديدها لهذا الإصدارومع ذلك، لن تكون قادراً على استخدام الأنواع والأساليب الجديدة في .NET Framework 4.يمكنك أيضاً تحديد إصدار سابق من .NET Framework باستخدام عنصر < supportedRuntime > في مخطط إعدادات بدء التشغيل.

العودة إلى الأعلى

شفافية الأمان من المستوى 2

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

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

يتم تشغيل تطبيقات سطح المكتب في وضع الثقة الكاملة; ولذلك، لا تتأثر بنموذج الشفافية. للمزيد من المعلومات حول التغييرات في الشفافية الأمنية، راجع التعليمات البرمجية الشفافة أمنياً، المستوى 2.

العودة إلى الأعلى

طلبات الأذونات المُهملة

في Deny، تم إزالة الدعم وقت التشغيل من أجل فرض طلبات الإذن RequestMinimum، و RequestOptional ، و RequestRefuse. بشكل عام، لم يتم فهم هذه الطلبات جيداً و أصبحت تقدم احتمال لوجود ثغرات أمنية عندما لا يتم استخدامها بشكل صحيح:

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

  • لا يمكن استخدام RequestMinimum بفاعلية خارج نطاق التطبيق. إذا ظهر RequestMinimum على ملف قابل للتنفيذ (.exe) و لم تتم موافاة مجموعة الأذونات الممنوحة، تلقى مستخدمو الملف استثناءاً لم تتم معالجته FileLoadException والذي لم يحتوِ على معلومات حول كيفية تصحيح المشكلة. لم تتمكن من استخدام مجموعة طلبات واحدة للحد الأدنى للمكتبات (ملفات dll.)، لأن الأنواع و الأعضاء المختلفة في التجميع بشكل عام لها متطلبات مختلفة للأذونات.

  • لقد كان RequestOptional مُحيراً وكان يُستخدم غالباً بشكل غير صحيح مع نتائج غير متوقعة. قد يقوم المطورون بحذف الأذونات من القائمة بسهولة دون إدراك أن القيام بذلك ضمنيًا يؤدي إلى رفض الأذونات التي تم حذفها.

  • لم يوفر RequestRefuse نموذجاً فعالاً للامتياز الأقل، وذلك لأنه كان يتطلب منك أن تعرّف بشكل صريح الأذونات التي لم تريدها بدلاً من تعريف الأذونات التي تحتاجها. بالإضافة إلى ذلك، إذا أصبحت أذونات جديدة متوفرة، لن يتم تضمينها في القائمة. و علاوة على ذلك، لم يكن الرفض منطقياً لكافة الأذونات. على سبيل المثال، يمكنك رفض قيمة ما للخاصية UserQuota في IsolatedStoragePermission.

    وأخيراً، فقد أدى تحديد الأذونات التي لا تريدها فقط إلى إيجاد ثغرات أمنية محتملة إذا فشلت في تحديد كافة الأذونات التي من المحتمل أن تكون ضارة.

  • RequestOptional وRequestRefuse أدى إلى تمكين المطورين من فصل المجالات المتجانسة عن طريق إنشاء عدة مجموعات للأذونات داخل المجال الواحد.

.NET Framework 4 يُزيل الفرض من بيئة وقت التشغيل لقيم قائمة التعداد هذه. التجميعات التي تحتوي على السمات التي تستخدم قيم SecurityAction هذه ستستمر في التحميل; ومع ذلك، لن تقوم CLR برفض تحميل التجميع المُشار إليه أو تعديل مجموعة الأذونات الممنوحة لها استناداً إلى مجموعات الأذونات.

العودة إلى الأعلى

APTCA الشرطية

الاستخدام الشرطي للسمة AllowPartiallyTrustedCallersAttribute (APTCA) يمكّن المضيفين من تعريف أي التجميعات يرغبوا في كشفها لطالبي الاستدعاء الموثوق بهم ثقة جزئية الذي يتم تحميلهم ضمن سياق المضيف. يجب أن تكون التجميعات المرشحة مصممة بالفعل للثقة الجزئية; وهذا يعني أنها يجب أن تكون APTCA (حرجة من ناحية السلامة الأمنية في نموذج الشفافية) أو شفافة بالكامل. إن دالة إنشائية جديدة لـ AllowPartiallyTrustedCallersAttribute تمكّن المضيف من تحديد مستوى الرؤية الخاص بتجميع APTCA باستخدام قائمة التعداد PartialTrustVisibilityLevel في طلب استدعاء الدالة الإنشائية.

العودة إلى الأعلى

كائنات الدليل

قبل .NET Framework 4، كان يمكن استخدام أي كائن ككائن دليل إذا أرادت التعليمات البرمجية التي تتم إستضافتها أن تطبقها كدليل. على سبيل المثال، كانت تتعرف بيئة .NET Framework على كائنات System.Uri على أنها دليل. كانت تعتبر بيئة وقت التشغيل كائنات الدليل على أنها إشارات مرجعية System.Object و لم تطبق تأمين النوع لهم.

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

و لتمكين القيود على أنواع الكائنات التي يمكن استخدامها كدليل و لتوفير إمكانية إضافة ميزات و متطلبات جديدة لكافة كائنات الدليل، تقدم .NET Framework 4 فئة أساسية جديدة، System.Security.Policy.EvidenceBase، والتي يجب أن تُشتق كافة كائنات الدليل منها. تضمن الفئة EvidenceBase عند إنشاء مثيل لها، أن كائن الدليل قابل للتسلسل. و بالإضافة إلى ذلك، يمكن إنشاء متطلبات جديدة للدليل في المستقبل بواسطة إضافة تطبيقات افتراضية جديدة للفئة الأساسية.

التوافق مع الإصدارات السابقة

تم تحديث كافة الأنواع المستخدمة بواسطة CLR ككائنات دليل في .NET Framework 4 لتشتق من EvidenceBase. و على الرغم من ذلك، فإن كائنات الدليل المخصصة و المستخدمة بواسطة تطبيقات من جهة خارجية ليست معروفة ولا يمكن تحديثها. ولذلك، لا يمكن استخدام أنواع الدليل هذه مع الأعضاء الجديدة والتي تتوقع أن يكون الدليل مُشتقاً من EvidenceBase. 

العودة إلى الأعلى

مجموعات الدليل

قبل .NET Framework 4 كانت تقوم CLR بإنشاء مجموعة كاملة من كائنات الدليل و التي كانت تطبق على تجميع ما عند تحميل التجميع. و كانت تخزّن هذه الكائنات في قائمة، و يقوم المستهلكون بالمرور بشكل متكرر خلالها للبحث عن كائن محدد. ولذلك، كان يتم توفير كافة الأدلة، سواء تم استخدامها أو لا. و بالنسبة لمعظم كائنات الدليل، لم يكن هذا السلوك مشكلة; ومع ذلك، بالنسبة لكائنات الدليل مثل System.Security.Policy.Publisher (والتي كانت تتطلب عملية التحقق من رمز المصادقة) ، لم يكن هذا السلوك فعّالاً.

و لتحسين هذا السلوك، تمت إعادة تصميم عملية التفاعل مع مجموعة الدليل في .NET Framework 4. و أصبح سلوك مجموعة الدليل الآن مثل القاموس بدلاً من القائمة. و بدلاً من المرور بشكل متكرر من خلال مجموعة الدليل لرؤية ما إذا كان يوجد كائن الدليل المطلوب، يمكن للمستهلكين الأن طلب نوع معين من الدليل و تقوم المجموعة بإرجاع الدليل إذا عُثر عليه. على سبيل المثال، يقوم طلب الاستدعاء StrongName name = evidence.GetHostEvidence<StrongName>();  بإرجاع كائن StrongName إذا كان موجوداً; وبخلاف ذلك، يقوم بإرجاع قيمة خالية null.

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

العودة إلى الأعلى

راجع أيضًا:

المبادئ

التعليمات البرمجية الشفافة أمنياً، المستوى 2

موارد أخرى

التعليمات البرمجية الشفافة أمنياً

التوافق مع سياسة أمان الوصول إلى التعليمات البرمجية و الإنتقال