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

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

تبني عقلية أمنية

الحقيقة هي أن الأمن ليس شيئًا “تم القيام به”. إنها عملية مستمرة ، تحتاج إلى مواصلة التركيز عليها للمساعدة في الحفاظ على رمزك آمنًا وآمنًا. على الرغم من أن الأدوات الآلية هي مساعدة كبيرة ، إلا أنها ليست حلًا عالميًا ، ومصادقًا.

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

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

شرح الإجراءات حقن سير العمل

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

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

النظر في سير العمل التالي كمثال:

- name: print title
  run: echo "${{ github.event.issue.title }}"

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

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

كيفية حماية الكود الخاص بك بشكل استباقي

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

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

استخدام متغيرات البيئة

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

- name: print title
  env:
    TITLE: ${{ github.event.issue.title }}
  run: echo "$TITLE"

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

مبدأ أقل امتياز هو أفضل صديق لك

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

كن حذرا مع pull_request_target

عادة ما يكون التأثير أكثر تدميراً عند حدوث الحقن في سير العمل الذي يتم تشغيله pull_request_target من على pull_request. هناك فرق كبير بين pull_request و pull_request_target مشغلات سير العمل.

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

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

هذا يعني أنك يجب أن تستخدم pull_request الزناد ما لم تكن لديك حاجة محددة للغاية للاستخدام pull_request_target. وإذا كنت تستخدم هذا الأخير ، فأنت تريد أن تهتم بمزيد من العناية باستخدام سير العمل بالنظر إلى الأذونات الإضافية.

المشكلة ليست فقط على الرئيسية

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

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

ما هو codeql الذي يجلبه إلى الجدول

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

أحد الأسباب التي تجعل CODEQL جيدة جدًا في العثور على مكان استخدام البيانات غير الموثوقة هو بسبب تتبع taint. نحن إضافة تتبع إلى codeql للإجراءات في أواخر العام الماضي. مع تتبع taint ، يتتبع CodeQL حيث تتدفق البيانات غير الموثوقة عبر الكود وتحدد المخاطر المحتملة التي قد لا تكون واضحة مثل الأمثلة السابقة.

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

إذا كنت تستخدم بالفعل الإعداد المتقدم لـ CodeQL، يمكنك إضافة دعم لمسح مهام سير عمل الإجراءات عن طريق إضافة actions اللغة للغات المستهدفة. سيتم تنفيذ هذه عمليات المسح للمضي قدمًا والمساعدة في تحديد نقاط الضعف هذه.

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

على الرغم من أن CODEQL أداة فعالة للغاية – وهي جيدة حقًا في إيجاد هذه الثغرة الأمنية المحددة – إلا أنها لن تكون فعالة بنسبة 100 ٪. تذكر أنه لا توجد أداة مثالية ، ويجب أن تركز على الحفاظ على عقلية الأمان واتخاذ فكرة مهمة إلى الكود الخاص بك. من خلال الحفاظ على هذا في طليعة أفكارك ، ستتمكن من تطوير رمز أكثر أمانًا والمساعدة في منع هذه الثغرات الأمنية من الظهور في المقام الأول.

الخطوات المستقبلية

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

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

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

---