Guidelines for Writing Secure Code

توفير الإرشادات التالية أساليب عديدة لكتابة تعليمات برمجية آمنة.

ضروري

• استخدام تعليمات برمجية أدوات التحليل.

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

  • Analyzing تعليمات برمجية مُدارة Quality by Using Code Analysis

  • ‏‏يتم الآن التحليل? جودة رمز C/C + + بواسطة ‏‏يتم الآن التحليل? تعليمات برمجية باستخدام

  • ‏‏يتم الآن التحليل? قاعدة بيانات تعليمات برمجية إلى تحسين جودة تعليمات برمجية

• مراجعة الأمان.

  وهدف من كل مراجعة الأمان أما إلى تحسين أمان المنتجات التي تم مسبقاً إصدارها، من خلال توفير تحديثات، أو إلى التأكد من أن المنتجات الجديدة لا تصدر حتى تكون آمنة قدر الإمكان.

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

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

  تقييد مراجعة الأمان كـ تعيين جزء من استقرار لكل مرحلة رئيسية، وضغط خط إنتاج بقعة صغيرة بالإدارة.

• استخدام تعليمات برمجية قائمة مراجعة الأمان.

  بغض النظر عن دورك في فريق تطوير البرامج، فإنه هو مفيدة لجعل checklهوt أن تتبع للتأكد من أن تعليمات برمجية وتصميم تفي بأدنى شريط.

• التحقق من صحة إدخال مستخدم الجميع.

  إذا قمت بالسماح تطبيق الخاص بك لقبول إدخال مستخدم، بشكل مباشر أو غير مباشر، يجب أن التحقق من صحة الإدخال قبل أن تقوم باستخدامه. سيحاول المستخدمين المؤذيين إلى جعل تطبيق الخاص بك الفشل بواسطة tweaking إدخال إلى تمثل بيانات غير صحيحة. قاعدة الأولى من إدخال مستخدم هو: إدخال الجميع هو غير صحيح حتى يتم تجاوز otherwهوe.

  كن حذراً عند استخدام تعابير عادية للتحقق من صحة إدخال مستخدم. للتعبيرات المعقدة مثل عناوين e-بريد، فإنه هو تعتقد بأنك تقوم إكمال عملية التحقق من صحة عندما لم تكن سهلة. أن النظائر مراجعة الجميع التعابير النظامية.

• التحقق من صحة الجميع المعلمات التي تم تصديرها والعامة شدة تطبيق برمجة واجهات (API).

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

• استخدم APIs التشفير Windows.

  بدلاً من كتابة برامج التشفير الخاص بك، قم باستخدام API Microsoft Office 2010 Suite التشفير التي هو متوفر بالفعل. باستخدام واجهة برمجة تطبيقات "crypإلىgraphic من Microsoft Office 2010 Suite، المطورين حرية إلى التركيز تشغيل إنشاء تطبيقات. تذكر أن يحل تشفير مربع متوسط التعيين من مشاكل في شكل جيد جداً والمستخدمة بشكل متكرر بطرق لا تم تصميمه ل. ل المزيد من المعلومات، راجع المرجع تشفير في مكتبة MSDN.

تجنب

• عمليات تجاوز احتياطي.

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

• وضع إلى التحقق من إدخال خارجي.

  وضع لا يتم التحويل البرمجي في البنيات البيع بالتجزئة. لا تستخدم وضع إلى التحقق من إدخالات خارجي. الجميع المعلمات للدالات التي تم تصديرها وأساليب إدخال المستخدم الجميع والجميع ملف ومآخذ توصيل بيانات يجب عناية التحقق من صحة ورفض إذا فيه خلل.

• تعليمات برمجية مضمّنة زوج المعرف وكلمة مرور مستخدم.

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

• استخدام تشفير إلى حل الجميع المشاكل المتعلقة بالأمان.

  تشفير التعيين صغيرة من مشاكل حل جيد جداً و هو المستخدمة بشكل متكرر بطرق لا تم تصميمه ل.

• المتعارف عليه ملف مسارات و محددات مواقع المعلومات.

  تجنب المواقف حيث الموقع ملف أو محدد الموقع معلومات هو الهامة. استخدام قوائم التحكم بالوصول لنظام الملفات بدلاً من القواعد المستندة إلى تشغيل canتشغيلical أسماء الملفات.

مستحسن

• قم بمراجعة الجميع القديم عيوب الأمان في تطبيق الخاص بك.

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

• مراجعة الجميع خطأ المسارات.

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

غير مستحسن

• امتيازات Administraإلىr الخاص بتطبيق إلى تشغيل.

  يجب أن يتم تشغيل تطبيقات مع أقل المزايا اللازمة للحصول على العمل المنجز. لمستخدم ضار بالعثور على مشكلة عدم حصانة الأمان و injects التعليمات البرمجية في العملية، سيتم تشغيل تعليمات برمجية ضارة بنفس امتيازات كـ عملية مضيف. في حالة تشغيل العملية كمسؤول، يتم تشغيل تعليمات برمجية ضارة كمسؤول. للحصول على مزيد من المعلومات، راجع تطوير البرامج في ‏‫Visual Studio .NET مع "امتيازات" إدارية بدون في مكتبة MSDN.

معلومات إضافية