مطورو المكونات الإضافية والقوالب: هذا ما يمكنك تعلمه من ثغرة أمنية في SDK

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

في يوم الاثنين ، 25 فبراير 2019 ، تلقينا بريدًا إلكترونيًا للدعم من مطور مفيد واجه مشكلة في GitHub في مستودع WooCommerce. تم إنشاء المشكلة بواسطة ممثل شركة استضافة صغيرة لاحظت نشاطًا مشبوهًا على خوادمها. قام الممثل بتضمين سجلات الأنشطة ذات الصلة التي أشارت إلى هجومين محتملين ، وكان أحدهما يستهدف مكونًا إضافيًا يقوم بتشغيل Freemius SDK.

نظرًا لأننا نتعامل مع الأمان بجدية بالغة ، فقد أجرينا على الفور تحقيقًا شاملاً وأكدنا أن الثغرة الأمنية كانت موجودة بالفعل في SDK الخاص بنا.

نظرًا لخطورة الثغرة الأمنية ، بدأنا العمل على الإصلاح على الفور. بعد بضع ساعات فقط ، أصدرنا علامة مصححة ، وأبلغنا جميع المطورين الذين كانوا يستخدمون إصدارًا ضعيفًا من SDK لتحديث SDK عبر جميع منتجاتهم في أسرع وقت ممكن. قمنا أيضًا بتحديث مشكلة GitHub الأصلية للسماح لفريق WooCommerce بمعرفة ذلك (مشكلة GH التي أزلناها بعد بضع ساعات لتقليل التعرض).

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

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

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

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

1. لم يتلق العديد من المطورين رسالة التنبيه الإلكترونية الخاصة بنا لأنهم سجلوا في Freemius بعنوان بريد إلكتروني لم يتحققوا منه.
2. عمدًا ، لم نضع علامة على علامة GitHub المصححة كإصدار رسمي لتجنب لفت الانتباه. ومع ذلك ، علمنا أن المطورين الذين كانوا يستخدمون Composer لتحديث مكتباتهم لم يحصلوا على آخر تحديث لأن Packgist يجلب الإصدارات فقط ، ما لم يتم تحديد علامة بشكل صريح.

للتغلب على تلك المشكلات:

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

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

الأخطاء التي ارتكبناها وماذا يمكن أن تتعلم منها

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

انتقل إلى الوضع الصامت وقم بتنبيه أولئك الذين يحتاجون إلى المعرفة فقط

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

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

لا تضيعوا طاقتكم على "المتصيدون الأمنيون"

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

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

الوضع الحالي للحادث

أكثر من 60٪ من المطورين الذين يستخدمون SDK قاموا بالفعل بالترقية إلى الإصدار المصحح. بالإضافة إلى ذلك ، تأتي SDK بآلية خاصة تسمح للعديد من المكونات الإضافية أو السمات المدعومة من Freemius والمثبتة على نفس موقع WordPress على الويب باستخدام أحدث إصدار من SDK إذا تم تحديث أحد المنتجات بالفعل. لذلك هذا جيد.

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

كيف تقلل من مخاطر الأمان في البرنامج المساعد / القالب الخاص بـ WordPress؟

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

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

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

خلاصة

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

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

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