در پست قبلی ما، ما دیدیم که چگونه مسمومیت مستقیم را تشخیص داده و در برابر آن محافظت کنیم Pipeline اجرا (D-PPE). همچنین دیدیم که چگونه میتوان با استفاده از آن، آن آسیبپذیری را تشخیص داد. اسکنر Xygeniو همچنین برخی از مکانیسمهای حفاظتی.
مسموم Pipeline اعدام (PPE) زمانی تولید میشود که مهاجم بتواند تغییر دهد pipeline منطق به دو صورت:
- با تغییر فایل پیکربندی CI ( pipeline) -> تجهیزات حفاظت فردی مستقیم (D-PPE)
- با تغییر فایلهای ارجاع داده شده توسط pipeline (برای مثال: اسکریپتهایی که از درون ... ارجاع داده میشوند) pipeline فایل پیکربندی) -> تجهیزات حفاظت فردی غیرمستقیم (I-PPE)
در این پست، ما به طور عمیق به PPE غیرمستقیم خواهیم پرداخت. اما قبل از آن، و به عنوان مکمل پست قبلیام، بیایید ابتدا ببینیم که گیتهاب چگونه اجرای ... را مدیریت میکند. pipelineو مکانیسمهای محافظت در برابر D-PPE چیست؟
گیتهاب چگونه از اجرای دستور زیر محافظت میکند؟ pipelineاز روابط عمومی میاد؟
گیتهاب در مورد اجرای اصلاحشده چگونه عمل میکند؟ pipelines?
اصلاح شده pipelines میتواند از Pushes یا ... بیاید. Pull Requests (روابط عمومی). به عنوان یک روش عالی و مهم، اکیداً توصیه میشود از هرگونه «push» مستقیم به یک شاخه محافظتشده خودداری کنید و از ... استفاده کنید. Pull Requests به عنوان مکانیزمی برای اعمال برخی بررسیها قبل از پذیرش هرگونه کد ارائه شده.
Pull Requests ممکن است از دو منبع مختلف آمده باشد:
- روابط عمومی از چنگال
- روابط عمومی از شاخه ها
روابط عمومی از چنگال میتواند از هر دو ناشی شود عمومی or خصوصی مخازن
همانطور که ما با تجهیزات حفاظت فردی (مسمومیت) سر و کار داریم Pipeline (اجرا)، نکته اصلی ما «پذیرش» یک PR نیست، بلکه اجرای یک اصلاحشده است. pipeline در طول فرآیند پذیرش/تأیید روابط عمومی. در هسته یک حمله به تجهیزات حفاظت فردی، اجرای ناخواسته یک تغییر «مخرب» وجود دارد. pipeline.
در چند کلمه، مسموم Pipeline اجرا (PPE) زمانی تولید میشود که مهاجم میتواند تغییر دهد pipeline منطق.
دو وجود دارد انواع:
- تجهیزات حفاظت فردی مستقیم (دی-پیای): در یک سناریوی D-PPE، مهاجم فایل پیکربندی CI را تغییر میدهد. در مخزنی که به آن دسترسی دارند، یا با ارسال مستقیم تغییر به یک شاخه راه دور محافظت نشده در مخزن، یا با ارسال یک PR به همراه تغییر از یک شاخه یا یک فورک. از آنجایی که CI pipeline اجرا توسط دستورات موجود در فایل پیکربندی CI اصلاحشده تعریف میشود، دستورات مخرب مهاجم در نهایت پس از ساخت، در گره ساخت اجرا میشوند. pipeline تحریک می شود
- تجهیزات حفاظت فردی غیرمستقیم (I-PPE): در موارد خاص، امکان D-PPE برای دشمنی که به آن دسترسی دارد، در دسترس نیست. SCM مخزن (مثلاً اگر pipeline طوری پیکربندی شده است که فایل پیکربندی CI را از یک شاخه جداگانه و محافظتشده در همان مخزن دریافت کند). در چنین سناریویی، به جای مسموم کردن pipeline خود، یک مهاجم کد مخرب را به فایلهایی که توسط آن ارجاع داده میشوند، تزریق میکند. pipeline (برای مثال: اسکریپتهایی که از درون ... ارجاع داده میشوند) pipeline فایل پیکربندی)
در هر دو مورد ، گیتهاب، تغییرات اعمال شده را اجرا خواهد کرد. pipeline بدون نیاز به بررسی یا تایید قبلی.
روابط عمومی از چنگالها به بعد عمومی استراحت
گیتهاب امکان پیکربندی رفتار هنگام پردازش را فراهم میکند PRهایی که از فورکها در مخازن عمومی میآیند.
وقتی یک PR از یک فورک میآید، گیتهاب همیشه قبل از اجرای آن، سطحی از «تأیید» را الزامی میکند. pipeline مرتبط با روابط عمومیاین سطح از تأیید، از تأیید ضعیف به تأیید سختگیرانه تغییر میکند.
At سطح سازمانی (سازمان>>تنظیمات>>اقدامات>>عمومی)، میتوانید از بین چندین گزینه «تایید» یکی را انتخاب کنید:
سختگیرانهترین، آخرین مورد است («نیاز به تأیید همه همکاران خارجی«) زیرا گیتهاب همیشه وقتی PR از فورکهای همکاران خارجی میآید، نیاز به تأیید دارد.
اما حتی در این مورد سختگیرانه، مواردی وجود دارد تفاوت بین همکاران با مجوزهای خواندن و نوشتن.
- وقتی روابط عمومی از یک خواندن کاربر، اجرای pipeline متوقف شده است تا زمانی که تغییرات تأیید شوند. اگر تأیید خوب باشد، تغییرات اعمال میشود. pipeline اعدام شده است
- وقتی روابط عمومی از یک نوشتن کاربر، نیازی به تأیید نیست و اصلاح شده است pipeline همیشه اعدام میشه!!
در نتیجه، PRهایی که از فورکهای مخازن عمومی میآیند، در برابر PPE محافظت کمی دارند. مقداری محافظت در برابر کاربران خارجی (خواندن) وجود دارد، اما هیچ محافظتی در برابر کاربران داخلی (نوشتن) وجود ندارد.
در مورد PRهایی که از فورکهای مخازن خصوصی میآیند?
روابط عمومی از چنگالها به بعد خصوصی استراحت
در این سناریو، گیتهاب تنظیمات پیکربندی مفیدی را ارائه میدهد.
تنظیمات فوق را میتوان در هر دو مورد پیکربندی کرد عضو و یا در مخزن سطح.
چه زمانی هیچ گزینه ای تیک نخورده، گیتهاب درخواست تأیید و اصلاحشده را اجرا نخواهد کرد pipelineاین امنترین پیکربندی است!!
La ناامنترین پیکربندی زمانی است "اجرای گردشهای کاری از طریق fork pull request” بررسی شده استدر این حالت، که برای هر دو کاربر خواندن و نوشتن یکسان است، گیتهاب بهطور خودکار تغییرات اعمالشده را اجرا میکند. pipelineو این وضعیت میتواند حتی بدتر اگر "ارسال توکنهای نوشتن به گردشهای کاری از fork pull requests"و"ارسال رمزها و متغیرها به گردشهای کاری از طریق fork pull requests” بررسی شدهاند. این کار را انجام ندهید مگر اینکه به وضوح توجیه شده باشد!!
اگر "نیاز به تأیید برای فورک pull request گردش کاراگر تیک خورده باشد، وضعیت فوق تا حدودی بهبود مییابد: گیتهاب درخواست تأیید میکند و کد اصلاحشده را اجرا نمیکند. pipeline برای کاربر خواندن، اما همچنان آن را برای کاربر نوشتن اجرا خواهد کرد.
چنگالها دیده میشوند، در موردشان چطور؟ روابط عمومی از شعب?
روابط عمومی از شاخه ها
برای محافظت از این سناریو باید به موارد زیر تکیه کنید قوانین حفاظت از شعبه.
در سطح مخزن، میتوانید برای هر شاخهای قوانین محافظت از شاخه ایجاد کنید. این قوانین مواردی را اضافه میکنند محدودیتهای اصلاح شاخههای محافظتشده.
اگرچه شما یک قانون را طوری پیکربندی میکنید که «نیاز به الف pull request قبل از ادغام"و"نیاز به تاییدیه" اصلاح شده pipeline به طور خودکار پس از ایجاد PR اجرا خواهد شد«تاییدیه» فقط برای اقدام ادغام اعمال خواهد شد.
مسمومیت غیرمستقیم چطور؟ Pipeline اعدام
همانطور که در بالا دیدیم، D-PPE را میتوان با استفاده از موارد زیر کاهش داد: pull_request_target، اما آن برای I-PPE اعمال نمیشود.
اگر از pull_request_target استفاده کنید، پرداخت پیشفرض کد پایه خواهد بود. اما اگر میخواهید برخی از بررسیها را روی کد ارائه شده (کد PR) اعتبارسنجی کنید، باید کد PR را به طور صریح پرداخت کنید. بنابراین، اگر کد PR هر اسکریپت پوستهای را که توسط ... فراخوانی شده است، تغییر داده باشد، pipeline، "پایه" (ایمن) pipeline اسکریپت پوسته «اصلاحشده» را فراخوانی میکند → PPE غیرمستقیم!!
راه حل این مشکل کمی پیچیدهتر است (راه حل جادویی مانند pull_request_target وجود ندارد).
pipeline اکنون در برابر D-PPE ایمن است زیرا ما از pull_request_target استفاده میکنیم. اما هنوز در برابر I-PPE آسیبپذیر است.
در مثال آزمایشی ما، اساساً برای ساخت، نیاز به بررسی کد PR داریم، اما آزمایشها روی مصنوع تولید شده توسط ساخت اجرا میشوند.
بنابراین .. چرا هر دو کدبیس را بررسی نمیکنید؟
- کد PR را بررسی کنید، زیرا این کدی است که میخواهیم بسازیم و آزمایش کنیم.
- کد پایه پرداخت برای اجرای نسخه اصلی pipeline و اسکریپتهای ساخت/آزمایش
این کار ممکن است توسط بررسی آن کدبیسها در پوشههای مختلف: کد پایه ممکن است در پوشه ریشه و کد PR در پوشه دیگری بررسی شود. در این حالت، اسکریپت ساخت و تست را از پوشه ریشه در مقابل کدی که در پوشه جدید قرار داده شده است، اجرا میکنیم.
البته این یک راه حل آسان است!! اما، برای اهداف یادگیری، میخواهم یک نوع کاملاً جالب را معرفی کنم (…)
GitHub workflow_run رویداد ماشه
در کنار pull_request_targetگیتهاب یک رویداد محرک دیگر ارائه میدهد: workflow_runاین رویداد اجازه میدهد اجرای یک pipeline مشروط به دیگری pipelineاعدام.
workflow_run و pull_request_target تریگرها از یک جنبه مشابه هستند: هر دو در حالت ممتاز اجرا میشوند و، علیرغم اصلاحات روابط عمومی، پایگاه pipeline اعدام خواهد شد!!
حال و روزمان را ببینیم pipeline:
بخش ساخت در برابر D-PPE ایمن است، اما بخش آزمایش هنوز در برابر I-PPE آسیبپذیر است.
La pipeline به دلیل وجود D-PPE، خود آن برای این کار بیخطر است. pull_request_target اما مرحلهی تست به دلیل فراخوانی یک اسکریپت پوستهی خارجی، همچنان در برابر I-PPE آسیبپذیر است.
اجتناب از تجهیزات حفاظت فردی (I-PPE)
هدف از موارد فوق pipeline ساخت و آزمایش کد ارائه شده، با در نظر گرفتن ایمنی PPE است.
بنابراین .. چرا تقسیمش نمیکنن؟ pipeline به دو قسمت تقسیم کنیم؟ یکی برای ساخت و دیگری برای آزمایش..
- یکم pipeline (ساخت CI) می خواست کد PR را بررسی کنید (برای ساخت آن)، ساخت را انجام دهید و یک مصنوع تولید کنید.
- 2nd pipeline (تست CI) می خواست کد پایه را بررسی کنید (برای جلوگیری از اصلاح اسکریپت پوسته) و اسکریپتهای اصلی را روی مصنوع اجرا کنید.
- برای همگامسازی Test CI pipeline برای اجرا پس از ساخت CI pipeline، ما استفاده خواهیم کرد workflow_run ماشه.
به این ترتیب:
- pipeline ساخت CI is امن برای هر دو دی-پیای (به واسطه pull_request_target) و I-PPE (زیرا دیگر اسکریپت پوسته را اجرا نمیکند).
- pipeline تست CI همچنین امن برای هر دو دی-پیای (به واسطه workflow_run) و I-PPE (زیرا کد پایه را بررسی میکند تا اسکریپت پوسته اصلی را دریافت کند)
بیایید کد هر دو را ببینیم pipelineطبق این اصلاحات ...
1st pipeline (ساخت CI):
2nd pipeline (آزمون CI):
وای... راه حل خوبی بود!! اما... ما در امانیم؟ متاسفانه نه 😭
راستی، ما یک آسیبپذیری جدید معرفی کردهایم!! کدام یک؟ این موضوع پست بعدی ما خواهد بود 🙂 … منتظر باشید!!
PS: ببخشید، نمیتونم ساکت بمونم 🤐 .. چیزی در موردش شنیدی؟ مسمومیت با مصنوعات ? 😂
