הבאג בסורק הסודות שלנו שהקנריות לא הצליחו למצוא

משלוח

לפני שכל ערכת אוטומציה שאנחנו מוכרים נדחסת לקובץ, שער סורק אותה כדי למצוא את הערכים בפועל של הסודות שלנו. כל סריקה מתחילה בהשתלת קנריות, אחת מכל סוג, וסירובה לרוץ אם לא תופסת את כולן. הן תמיד נתפסו. ובכל זאת היה שם באג.

איך השער קורא סודות

השער לא מחפש רק דברים שנראים כמו מפתחות. הוא קורא את הקבצים שבהם הסודות שלנו חיים (קבצי env, קונפיגורציות JSON, קבצי מפתחות), לוקח כל ערך שהשם שלו מעיד שהוא סודי, ואז מחפש במה שאנחנו עומדים לשלוח את הערכים המדויקים האלה, כפי שהם נכתבו ומוצפנים ב-base64.

הבאג

עבור שורה כמו זו:

DB_PASSWORD='Tr0ub4dor-and-3'  # הוחלף במאי

הקורא הוריד את המרכאות המקיפות רק כאשר הערך גם התחיל וגם הסתיים בתו מרכאות. עם הערה אחרי הערך, השורה מסתיימת באות, ולכן המרכאות נשארו. ההערה נחתכה בהמשך, והשער המשיך לחפש את 'Tr0ub4dor-and-3', כולל המרכאות. ערכת אוטומציה שהכילה את הסיסמה ללא המרכאות האלה הייתה עוברת.

למה הקנריות מעולם לא שמו לב

קנרית בודקת רשת: משתילים ערך שהסורק כבר מכיר, ובודקים שהוא נמצא. ערכי הקנריות שלנו הועברו ישירות לסורק, ולכן הם מעולם לא עברו דרך הקוד שקורא שורת קונפיגורציה. כל רשת נבדקה, אבל המפרץ שלפניהן לא.

איך מצאנו את זה

הפכנו את השער למוצר בפני עצמו, וכתבנו בדיקה שהזינה לו קובץ קונפיגורציה בצורות שאנשים באמת כותבים: export, מרכאות, הערות בסוף. הבדיקה נכשלה בשורה עם מרכאות והערה. התיקון קורא ערך במרכאות עד למרכאות הסוגרת ומתעלם מכל מה שבא אחריו.

האם זה היה משנה?

בדקנו לפני ששינינו משהו. במכונת הבנייה שלנו השער קורא 133 ערכים סודיים מתוך 59 הקבצים שמוגשים לו, ובמכונה שנייה 499; לאף אחד מהם לא היה הצורה הזו. לא השתנה אף פסיקה קודמת: כל ערכת אוטומציה ששחררנו נסרקה עבור אותם ערכים שהיא תיסרק עבורם עכשיו. בכל זאת תיקנו את השער בכל שלוש המכונות.

המסקנה

אם סורק חולץ את מה שהוא מחפש, בדקו את החילוץ עם קלט ריאליסטי, ולא רק את החיפוש עם ערכים מושתלים. קנריון מוכיח שהרשת עובדת; הוא לא אומר דבר על כך שהדגים הנכונים מגיעים אליה. הבדיקות של Secret Gate מכסות כעת את שניהם, ולפני ההשקה בדקנו שהיא קוראת בדיוק את אותם 133 ערכים כמו שער הבנייה שלנו.

עודכן: