כלי אוטומציה שנבנה על Safari MCP סגר את לשונית לוח הבקרה (dashboard) של המפתח בזמן שהיא נקראה. התקרית חשפה פגם נסתר במנגנון ההגנה (guard) שאמור היה למנוע מסוכנים מבוססי AI לגעת בכל לשונית שאינה שייכת להם, והיא מדגימה מדוע קטגוריות של "בטוח כברירת מחדל" (safe-by-default) יכולות להוות סיכון.
מנגנון ההגנה שעבד — עד שהוא לא
הכלי מתייג כל לשונית שהוא יוצר באמצעות מזהה פנימי. לפני שהסוכן (agent) מנפיק פקודה כלשהי, מנגנון ההגנה בודק את קיומו של הסימון; אם הסימון חסר, המנגנון מסרב לפעול. בפועל, מנגנון ההגנה מנע מהסוכן לקרוא דף שהוא לא פתח — בדיוק כפי שתוכנן לעשות.
בזמן מילוי טופס, הדף הופנה (redirect) לדומיין אחר. ההפניה הסירה את הסימון, מה שהותיר את הלשונית ללא תווית. מנגנון ההגנה זיהה שהסימון חסר ודיווח: "איני יכול לאמת בעלות, לכן לא אקרא את הלשונית הזו". בשלב זה, בדיקת הבטיחות פעלה כמצופה.
קוד הניקוי שחצה את הגבול
לאחר מכן הגיע תהליך ניקוי ידני שנועד לסגור לשוניות יתומות (orphaned tabs) — אלו ללא סימון. התהליך ביקש מהכלי "לסגור לשונית" מבלי לאמת בעלות תחילה. מכיוון שמנגנון ההגנה לא יכול היה להוכיח שהלשונית שייכת לו, הכלי חזר לפעולת ברירת מחדל: "סגור את הלשונית הנוכחית". הלשונית הנוכחית הייתה לוח הבקרה שהמפתח קרא, ולא לשונית יתומה.
התוצאה הייתה פעולה הרסנית שהופעלה על ידי נתיב בטיחות שהיה אמור להיות מבוי סתם.
שלוש שכבות שהתייחסו ל"חוסר בעלות" כלהיתר
- סיווג פקודות – הרשימה שקיבצה את הפקודות הציבה את
close_tabתחת קטגוריה רחבה של "ניהול לשוניות" (tab management). המפתח הניח שכל מה שנמצא בקטגוריה זו אינו מזיק, מכיוון שפקודות אחרות (כמו "list tabs") רק קוראות מידע. לא היה סימון מפורש שמתריע על כך ש-close_tabהיא פקודה הרסנית, ולכן היא ירשה את תחושת הבטיחות של השכנות שלה. - מדיניות ברמת התוסף – תוסף ה-Safari שניהל את כל פעולות הדפדפן אפשר כל פעולה כאשר לסשן (session) לא הייתה בעלות על דבר. הכלל הזה עובד עבור פעולות של "קריאה בלבד", אך הוא גם פתח את הדלת לביצוע
close_tabללא בדיקת מקור (provenance check). - חוסר התאמה לוגי – תהליך הניקוי בדק את דגל הבעלות בלשונית אחת, אך לאחר מכן קרא לפונקציית הסגירה על הלשונית שהדפדפן דיווח עליה כ"נוכחית". חוסר ההתאמה אפשר לכך שכישלון מנגנון ההגנה במציאת הסימון יעקוף את פקודת הסגירה וינתב אותה ליעד הלא נכון.
כל שכבה הניחה ש"לא נרשמה בעלות" פירושו "בטוח לפעול", ויחד הן יצרו פקודת סגירת לשונית שרצה ללא כל הוכחה ללגיטימיות.
הפתרון: הוכחת בעלות היא חובה עבור פעולות הרסניות
הלוגיקה המעודכנת מפרידה בין נתיבים של קריאה בלבד לבין נתיבים הרסניים. כעת, לפני שפקודת close_tab יכולה להתבצע, על הכלי להציג סימון תקף עבור הלשונית המיועדת. אם הסימון חסר, הפקודה מניפה שגיאה במקום לחזור לפעולת ברירת מחדל על הלשונית הנוכחית. מנגנון ההגנה כבר לא חוזר לענף כללי של "בצע משהו".
שינוי זה מסיר את המצב המעורפל שבו סימון חסר יכול להתפרש כ"אין מה לעשות" או כ"המשך ופעל". על ידי כפיית כישלון מפורש, הכלי מגן על עבודת המשתמש מפני אובדן מקרי.
מה על מפתחים לשים לב אליו
- אל תתנו לשם קטגוריה להכתיב את רמת הבטיחות – תווית כמו "ניהול לשוניות" אינה אומרת דבר על ההשפעה של כל פקודה בתוכה. רשמו את ה"מחיר" של כל פעולה (קריאה לעומת הרס) לצד הפקודה עצמה.
- תנאי ההגנה חייבים להתאים לחומרת הפעולה – בדיקה המספיקה לבקשת קריאה אינה מספיקה עבור פקודה שעלולה למחוק נתונים. בנו תהליכי אימות (validation pipelines) נפרדים לכל סוג של השפעה.
- הימנעו מברירות מחדל משתמעות – כאשר מנגנון הגנה אינו יכול לאמת בעלות, התגובה הבטוחה ביותר היא לבטל את הפעולה, ולא לבחור יעד ברירת מחדל. פעולות ברירת מחדל הן מקור נפוץ לבאגים של הסלמת הרשאות (privilege-escalation).
- בחנו הנחות של סמיכות – עברו על כל רשימה או תפריט שבהם פקודות מופיעות זו לצד זו. פקודה תמימה עלולה לרשת את האמון המוענק לשכנותיה אם הקוד אינו מעריך מחדש את הבטיחות באופן מפורש.
שורה תחתונה
היעדר מנגנון הגנה על בעלות אינו באג; הוא פער בתכנון. התייחסו לכל פקודה הרסנית כאל תחום אבטחה נפרד הדורש הוכחה מפורשת של סמכות, ואל תתנו לעולם לפרש "אין סימון" כ"המשך ופעל". רק אז כלי אוטומציה יוכלו להגן על הלשוניות עצמן שהם אמורים לנהל.