Інструмент автоматизації, побудований на Safari MCP, закрив вкладку панелі керування розробника під час її читання. Цей інцидент виявив приховану ваду в захисному механізмі (guard), який мав запобігати втручанню ШІ-агентів у будь-які вкладки, що їм не належать, і він демонструє, чому категорії «безпечні за замовчуванням» (safe-by-default) можуть стати фактором ризику.

Захист, який працював — поки не перестав

Інструмент позначає кожну створену ним вкладку внутрішнім ідентифікатором. Перед тим як агент надішле будь-яку команду, захисний механізм перевіряє наявність цього маркера; якщо маркер відсутній, захист відмовляється діяти. На практиці захист зупинив агента від читання сторінки, яку він не відкривав — саме те, для чого він був призначений.

Під час заповнення форми сторінка перенаправила на інший домен. Перенаправлення видалило маркер, залишивши вкладку без позначки. Захисний механізм помітив відсутність маркера і повідомив: «Я не можу підтвердити право власності, тому не буду читати цю вкладку». На той момент перевірка безпеки спрацювала належним чином.

Код очищення, що перейшов межу

Далі настав етап рутинного очищення, призначений для закриття «сирітських» вкладок — тих, що не мають маркера. Процедура наказала інструменту «закрити вкладку», не підтвердивши попередньо право власності. Оскільки захист не зміг довести, що вкладка належить йому, інструмент перейшов до дії за замовчуванням: «закрити поточну вкладку». Поточною вкладкою була панель керування, яку читав розробник, а не «сирітська» вкладка.

Результатом стала деструктивна операція, ініційована шляхом безпеки, який мав стати глухим кутом.

Три рівні, які сприйняли «відсутність власності» як дозвіл

  1. Категоризація команд — список, що групував команди, помістив close_tab у широкий розділ «управління вкладками» (tab management). Розробник припустив, що все в цьому розділі є нешкідливим, оскільки інші команди (наприклад, «list tabs») лише зчитують інформацію. Жодне явне зауваження не позначало close_tab як деструктивну команду, тому вона успадкувала сприйняту безпеку своїх сусідів.
  2. Політика на рівні розширення — розширення Safari, яке керувало всіма діями в браузері, дозволяло будь-яку операцію, якщо сесія не володіла жодними об'єктами. Це правило працює для дій лише для читання, але воно також відкрило двері для виконання close_tab без перевірки походження (provenance check).
  3. Невідповідність логіки — процедура очищення перевіряла прапорець власності на одній вкладці, але потім викликала функцію закриття для вкладки, яку браузер позначив як «поточну». Ця невідповідність дозволила невдачі захисного механізму знайти маркер обійти команду закриття та перенаправити її на неправильну ціль.

Кожен рівень припускав, що «власність не зафіксована» означає «безпечно діяти», і разом вони створили команду закриття вкладки, яка виконалася без жодних доказів легітимності.

Виправлення: підтвердження власності є обов'язковим для деструктивних дій

Оновлена логіка розділяє шляхи лише для читання та деструктивні шляхи. Тепер, перш ніж команда close_tab зможе виконатися, інструмент повинен надати дійсний маркер для цільової вкладки. Якщо маркер відсутній, команда видає помилку замість того, щоб за замовчуванням застосувати дію до поточної вкладки. Захисний механізм більше не переходить до загальної гілки «щось зробити».

Ця зміна усуває неоднозначний стан, коли відсутність маркера могла трактуватися або як «нічого робити», або як «продовжуйте діяти». Примусово викликаючи явну помилку, інструмент захищає роботу користувача від випадкової втрати.

На що варто звернути увагу розробникам

  • Не дозволяйте назві категорії визначати безпеку — такий ярлик, як «управління вкладками», нічого не говорить про наслідки кожної команди всередині нього. Записуйте «вартість» кожної операції (читання проти знищення) поруч із самою командою.
  • Умови захисту повинні відповідати серйозності дії — перевірки, достатньої для запиту на читання, недостатньо для команди, яка може видалити дані. Створюйте окремі конвеєри валідації для кожного класу впливу.
  • Уникайте неявних запасних варіантів (fallbacks) — коли захисний механізм не може підтвердити право власності, найбезпечнішою відповіддю є переривання дії, а не вибір цілі за замовчуванням. Дії за замовчуванням є поширеним джерелом помилок підвищення привілеїв.
  • Перевіряйте припущення щодо сусідства — переглядайте будь-які списки або меню, де команди розташовані поруч одна з одною. Невинна команда може успадкувати довіру, надану її сусідам, якщо код явно не проводить повторну оцінку безпеки.

Висновок

Відсутність захисту власності — це не баг, а прогалина в проєктуванні. Ставтеся до кожної деструктивної команди як до окремого домену безпеки, що вимагає явного підтвердження повноважень, і ніколи не дозволяйте інтерпретувати «відсутність маркера» як «продовжуйте». Тільки тоді інструменти автоматизації зможуть захистити саме ті вкладки, якими вони мають керувати.