Что такое изолированный iframe?

Iframe в песочнице — это встроенный документ браузера, к которому атрибут sandbox применяет дополнительные ограничения. При пустом значении sandbox браузер вводит строгие ограничения; отдельные токены allow-* возвращают только необходимые встроенному содержимому возможности. Безопасный и полезный предварительный просмотр HTML основан не на доверии к коду, а на отдельной границе изоляции, минимальных разрешениях и отсутствии секретов в эксперименте.

Что меняется, когда iframe помещается в песочницу?

Обычный iframe создает вложенный контекст просмотра. Политика одного источника, политика разрешений, политика безопасности содержимого и собственные заголовки встроенного сайта по-прежнему действуют, но фрейм не лишается автоматически всех возможностей браузера.

Добавление sandbox задает браузеру дополнительные ограничения. Стандарт HTML WHATWG определяет атрибут как неупорядоченный набор токенов, разделенных пробелами. Отсутствие токена сохраняет соответствующее ограничение, а добавление снимает определенное ограничение.

Это направление легко неверно истолковать:

<iframe sandbox srcdoc="<p>Static preview</p>"></iframe>

Это ограничительная форма. Это не означает, что «опции песочницы не выбраны». Это означает, что песочница активна и ни одна из ее дополнительных возможностей не была восстановлена.

<iframe
  sandbox="allow-scripts allow-forms"
  srcdoc="<button type='button'>Run</button>">
</iframe>

Этот вариант разрешает скрипты и работу форм, оставляя остальные ограничения. Безопасность по-прежнему зависит от источника содержимого и возможностей, предоставленных окружающим приложением.

Какие ограничения применяются по умолчанию?

Полный стандарт содержит больше деталей, чем один контрольный список, но эти категории объясняют большую часть поведения предварительной версии.

Справочник MDN по iframe перечисляет действующие токены и объясняет, какие возможности каждый возвращает. Проверяйте справочник, а не копируйте старый список токенов в долгосрочную настройку безопасности.

Какие возможности возвращают распространенные разрешающие токены?

Рассматривайте каждый токен как решение о возможностях, а не как удобный переключатель.

Некоторые токены взаимодействуют. Рассмотрение их по одному необходимо, но недостаточно. Происхождение документа в рамке, независимо от того, является ли оно srcdoc или удаленный URL-адрес, политика безопасности контента хоста и любой мост сообщений между фреймом и родительским элементом — все это влияет на границу.

Схема описывает границу разрешений. Она не утверждает, что любой набор токенов делает произвольный код безвредным.

Почему важен непрозрачный источник?

Без allow-same-originсодержимое изолированной программной среды рассматривается как поступающее из особого источника, который не проходит обычные проверки того же источника. Разработчики часто называют это непрозрачным или уникальным происхождением.

Для встроенного srcdoc Предварительный просмотр показывает, что разделение имеет ценность. Предварительный просмотр может отображать документ, не рассматривая его как источник того же приложения, что и страница редактора. Он не может просто получить доступ к родительскому DOM или прочитать хранилище того же происхождения, как если бы это был другой компонент хоста.

Непрозрачный источник не означает работу без сети. Если скрипты разрешены, код предварительного просмотра может отправлять сетевые запросы, допускаемые политиками браузера и получателем. Он может использовать процессор и память, менять собственный DOM и общаться через каналы, которые основная страница предоставляет явно. Граница ограничивает полномочия, но не сертифицирует код.

MDN особо предупреждает о сочетании allow-scripts и allow-same-origin, когда встроенное содержимое имеет тот же источник и может удалить собственный атрибут песочницы. Важен контекст: не возвращайте обе возможности только потому, что без них пример не работает.

Как настроена песочница предварительного просмотра ClockTools?

Действующий HTML-редактор ClockTools в реальном времени создает предварительный просмотр с помощью srcdoc. При включенном JavaScript атрибут sandbox его iframe имеет значение:

allow-scripts allow-forms allow-modals

Реализация намеренно опускает allow-same-origin, allow-popups, разрешения на верхнюю навигацию и разрешение на загрузку. Интерфейс помечает предварительный просмотр как песочницу с непрозрачным источником, явно показывая решение об источнике, а не скрывая его в коде.

Такая конфигурация поддерживает обычные учебные примеры: скрипты обновляют предварительный просмотр, формы используют браузерную проверку и отправку, модальные диалоги могут выполняться. Она не делает неизвестный код доверенным. Поэтому редактор советует не вводить секреты и проверять незнакомые скрипты.

Страница также записывает сообщения консоли и показывает панель проверки документа. Это средства наблюдения, а не разрешения песочницы. Консоль помогает объяснить сбой, но не предотвращает запрос. Проверка структуры может отметить отсутствие метки, но не заменяет полный аудит безопасности.

Что показала проверка работоспособности?

Я проверил визуализированный элемент предварительного просмотра в интерактивном рабочем пространстве ClockTools, а не полагался только на маркетинговый текст.

Заголовок iframe был «Живой предварительный просмотр HTML», что также дает вспомогательным технологиям метку цели для встроенного документа.

Эта проверка подтверждает настроенную на данный момент границу. Это не доказывает, что все возможные сценарии безопасны, и не заменяет проверку моста сообщений, обработки внешних ресурсов, политики безопасности контента или будущих изменений кода.

Какие комбинации токенов заслуживают особой осторожности?

Используйте проверку на основе угроз вместо универсального рецепта токена.

allow-scripts плюс allow-same-origin

Это сочетание может серьезно ослабить изоляцию, если встроенный документ имеет тот же источник и способен менять условия своего встраивания. Если нужны обе возможности, размещайте недоверенное содержимое на заведомо отдельном источнике и анализируйте пути выхода, не считая атрибут единственной границей.

Формы плюс доступ к сети

allow-forms разрешает отправку форм, но скрипты и обычные элементы HTML могут отправлять запросы и другими способами. Никогда не помещайте учетные данные, личные данные клиентов или токены предъявителя в недоверенный предварительный просмотр в расчете на то, что песочница удержит их внутри.

Всплывающие окна и выход из песочницы

allow-popups позволяет фрейму открыть новый контекст просмотра. allow-popups-to-escape-sandbox освобождает этот контекст от унаследованных ограничений песочницы. Это может быть полезно для намеренно изолированной рекламы или внешней ссылки, но расширяет область проверки.

Навигация страницы верхнего уровня

Разрешения навигации верхнего уровня позволяют фрейму заменять основную страницу при определенных условиях. Среде экспериментов с кодом это редко нужно. Если навигация входит в урок, рассмотрите перехват и показ адреса назначения, не отдавая предварительному просмотру управление основной страницей.

Что не может защитить песочница?

Песочница — это один из механизмов браузера, а не полноценная платформа для вредоносного кода.

• Это не мешает пользователю открывать тот же контент непосредственно за пределами фрейма.
• Это не гарантирует, что разрешенные сценарии будут быстрыми, вежливыми или свободными от бесконечных циклов.
• Она не блокирует автоматически каждый сетевой запрос.
• Она не очищает HTML и не доказывает безопасность URL.
• Она не защищает секреты, уже помещенные в предварительный просмотр.
• Она не заменяет серверную проверку настоящих форм.
• Она не проверяет доступность, семантику или работу в разных браузерах.
• Она не защищает другие службы, принимающие запросы от предварительного просмотра.

Граница также меняется со временем по мере развития браузеров и стандартов. Поведение функций следует тестировать в браузерах, которые фактически использует аудитория, а список токенов следует проверять на соответствие текущим спецификациям.

Как спроектировать предварительный просмотр кода в браузере?

Начни с пустого sandbox атрибут, затем добавляйте по одной возможности за раз. Для каждого дополнения создайте небольшой приемочный тест и соответствующий тест на злоупотребление.

Ограничивайте протокол сообщений между основной страницей и фреймом. Проверяйте отправителя, структуру сообщения и допустимые команды. Не принимайте произвольный код или команды навигации через общее сообщение «выполнить», если только именно такой явно изолированный продукт не является вашей целью.

Предусмотрите режим без JavaScript для статической проверки. Добавьте остановку, сброс или перезагрузку для примеров, вышедших из-под контроля. Показывайте ошибки консоли, не копируя во фрейм конфиденциальные данные родителя. Рассматривайте внешние стили и скрипты как сетевые зависимости, чьи серверы и будущее содержимое редактор не контролирует.

Для целенаправленного эксперимента HTML-редактор реального времени предоставляет адаптивную ширину, захват консоли, проверки и непрозрачное состояние песочницы. Для работы по выпуску, включающей пакеты, серверы, учетные данные, тесты или развертывание, переместите код в локальный репозиторий и используйте более полный рабочий процесс разработки и проверки безопасности.