كيفية كتابة كود بايثون آمن. وجبات كوشال داس

هذه هي النسخة الإنجليزية الأصلية من هذه المقابلة.

في هذا العام ، قامت شركة المتحدثين موسكو Python Conf ++ بالتقاط ما هو مطلوب (أي كيف ، التقطت - التقطت لجنة البرنامج ). ولكن من يهتم بدراسة الإنجازات ، من المثير للاهتمام أكثر ما يعتقده المتحدث حول القضايا التي تهمنا. لمعرفة ذلك ، احصل على معلومات داخلية أو نصيحة مطور أكثر خبرة ، وتحتاج إلى التواصل في المؤتمرات. لكنني استفدت من الوضع وأخذت مقابلة قصيرة من المتحدث باسمنا كوشال داس.

السمة المميزة لخطابات كوشال هي أنه ينشر بانتظام طرقًا "سرية" لكسر كود بايثون ، وعلى النقيض من ذلك ، يوضح كيفية كتابة الشفرة بحيث لا تستطيع وكالة الأمن القومي كسرها. في مؤتمرنا أكلتسيخبرك بكيفية تطوير شفرة Python ونشرها بأمان ، لذلك سألته عن الأمان.



- لقد أكلت ، من فضلك أخبرنا قليلاً عن نفسك وعن عملك مع Python وما شابه.

كوشال داس: أعيش في الهند ، وأعمل الآن كخبير تقني للمصلحة العامة في مؤسسة حرية الصحافة الأمريكية غير الربحية ، حيث أساعد في دعم مشروع SecureDrop. SecureDrop هي منصة معلومات مفتوحة المصدر. اللغة الرئيسية هنا هي Python.

بالإضافة إلى ذلك ، أنا منخرط في مشاريع أخرى مفتوحة المصدر ، بما في ذلك لغة Python نفسها. أنا أحد مطوري CPython Core وعضو في مجلس إدارة مؤسسة Python Software Foundation.

أعمل مع Python منذ عام 2005 ، وقد ارتبطت حياتي المهنية تقريبًا بهذه اللغة ، بالإضافة إلى Linux. هذان مجالان رئيسيان من اهتماماتي. أنا أيضًا عضو في الفريق الأساسي لمشروع Tor. كما يعلم الكثيرون بالفعل ، يساعد Tor في الحفاظ على خصوصيتك على الإنترنت.

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

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

ما الذي تعتقد أنه لا يزال أفضل: لتعليم رجال الأمن أو تزويدهم ببعض الأدوات؟

أكلت داس: أعتقد أن كلاهما. والواقع أن الأمن قضية معقدة. ومع ذلك ، إذا كان المبرمج المبتدئ يمر بالتدريب الأساسي أو يعمل كفريق ، فإنه يتعلم تجنب معظم المشاكل الشائعة.

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

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

مثال بسيط للغاية هو اختبارات التبعية التي يمتلكها GitHub الآن. إذا كان تطبيق Python يحتوي على أخطاء أو يستخدم بعض الإصدارات القديمة من الوحدة المستقلة ، وهناك ثغرة معينة موضحة في CVE ، يمكن لـ GitHub أن يخبرك كمطور: "مرحبًا! التحديث مطلوب هنا! " - وسيحاول البوت تلقائيًا إجراء العلاقات العامة لتحديث الوحدة.

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

- نعم ، للأسف ، هو كذلك. يعتمد تطوير البرمجيات الحديثة بشكل كبير على المستودعات المفتوحة مثل فهرس حزمة Python و node.js و npm وما إلى ذلك. على المستوى الحالي من التطور ، يحدث هذا عادة عند إضافة تثبيت النقاط أو الشعر.

برأيك ، ما مدى ارتفاع المخاطر الأمنية لمطور خلفية Python عادي في شركة متوسطة الحجم إذا كان يستخدم هذه الأدوات فقط؟ هل هذه المخاطر مقبولة ، أم يجب على المطورين حتى التفكير في نقاط ضعف تافهة؟

Kushal Das: هذا سؤال مهم حقًا ، لأنه في جميع المستودعات التي ندعمها ، حيث يمكنك تنزيل الوحدات بلغات مختلفة ، نحاول أن نجعل هذه العملية بسيطة وفي متناول المطورين.

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

بالإضافة إلى ذلك ، عند تثبيت أي حزمة باستخدام النقطة ، يمكنك حقًا التحقق منها والتأكد من أن هذا هو ما تحتاجه ، بالإضافة إلى التحقق من أمان التنزيل. على سبيل المثال ، هناك PEP 458 ، الذي ينصحك بحماية التنزيلات بتوقيع حزم PyPI.

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

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

— , , - , , , .

, , node.js npm, npm install something.

يتحقق NPM من أمان البيانات ويظهر النتائج. على سبيل المثال ، يعرض الرسالة: "من بين الحزم التي قمت بتثبيتها للتو ، هناك حزمتان تنطويان على مخاطر أمنية عالية وعشرة مع مخاطر متوسطة. يمكنك تنفيذ الأوامر التالية لإصلاحها أو تحديثها ، أو رفض التثبيت. " هذا مشابه للأدوات المدمجة. ما رأيك في هذه الحلول ، وهل يمكنك توقع شيء مشابه لـ PyPI؟

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

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

أما بالنسبة للخطط المستقبلية لتطوير Python و pip ، فلا يمكنني التعليق عليها ؛ فهي غير معروفة بالنسبة لي. ومع ذلك ، أعتقد ، أو بالأحرى ، أتمنى أن يكون شخص ما قد قدم بالفعل طلبًا لوظيفة مماثلة بحيث يمكن لمؤلفي النقاط أخذها بعين الاعتبار في خططهم. أصبح فريق الدعم الآن أكبر قليلاً مما كان عليه من قبل - حوالي سبعة أشخاص لديهم الحق في قبول الالتزامات.

- شكرًا لك ، آمل أن يفكر الناس بمرور الوقت في المزيد من الأمان وأن يبنوا المزيد من عمليات الفحص في نظامنا البيئي. لنتحدث قليلاً عن أدائك القادم في Moscow Python Conf ++. وهي مبنية حول أمن الاعتماد المدمج والتغليف.

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

لقد ناقشنا بالفعل كيفية تأمين معالجة وحزم التبعية. ما الذي يحتاج إلى التحقق من المطور العادي؟ ما الذي يجب أن أبحث عنه؟

أكلت داس: أعتقد أن إحدى النقاط الرئيسية يجب أن تكون التحديثات. تأكد من أن لديك طلبًا بذلك على الأقل ، وأن كل شيء تعتمد عليه يتم تحديثه ، بما في ذلك نظام التشغيل ، سواء كان Linux أو Mac أو Windows أو حتى iOS. بدلاً من ذلك ، تأكد من أن تقوم على الأقل بوضع نماذج للعمليات لفهم الأخطاء الأخرى التي قد تحدث.

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

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

من وجهة نظر البرمجة ، أعتقد أن هاتين النقطتان الرئيسيتان ينساه الكثير من الناس.

- نعم ، هناك أشياء كثيرة ينسها الناس ، والآن أعتقد أن السؤال الأخير. بناءً على تجربتك الشخصية ، ما نوع الأخطاء الأمنية التي غالبًا ما يرتكبها مطورو الواجهة الخلفية في المستوى المتوسط ​​لـ Python؟ إدخال المستخدم؟ إدمان؟ تغليف تطبيق آمن؟ ما هو أكثر شيوعا؟

Eaten Das: المشاكل التي رأيتها كانت بسبب الدخول غير الصحيح.

في عام 2011 ، كنت أقوم بتطوير أداة لمشروع فيدورا ونسيت تنظيف ملفاتي المؤقتة. في هذه الحالة بالذات ، كانت هذه مقالب ، وغيابها في البيئة الجديدة تسبب في مشاكل غير متوقعة للبنية التحتية - لقد سقطت بسبب رمزي ، بعبارة ملطفة ، سيئة.

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

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

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

سيقدم Kushal Das في موسكو Python Conf ++ . اضطررنا إلى تأجيل مؤتمر كبير غير متصل بالإنترنت للخريف ، ولكن في 27 مارس عقدنا مؤتمرًا صغيرًا عبر الإنترنت ، سنشارك فيه المواد قريبًا ، على اتصال.