Безопасность встроенных iFrame: Лучшие практики для веб-разработчиков (RU)

Используйте "песочницу" для iFrameВсегда используйте атрибут sandbox для ограничения возможностей iFrame, предотвращая выполнение скриптов ненадежным контентом, доступ к локальному хранилищу или отправку форм.

Внедрите надежную CSPИспользуйте заголовки Content Security Policy (CSP) для контроля ресурсов, которые ваша страница может загружать и выполнять, специально нацеливаясь на iFrame для предотвращения проблем со смешанным контентом и внедрения скриптов.

Используйте X-Frame-Options и CSP Frame-AncestorsЗащитите свой сайт от кликджекинга, установив X-Frame-Options в DENY или SAMEORIGIN, а для современных браузеров используйте более гранулярную директиву frame-ancestors в вашем CSP.

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

iFrame: Палка о двух концах — удобство против безопасности

iFrame (Inline Frames) являются неотъемлемой частью современной веб-разработки, позволяя разработчикам беспрепятственно встраивать контент из других источников на свои веб-страницы. Будь то видео с YouTube, платежный шлюз, виджет социальной сети или процесс верификации личности, iFrame предлагают беспрецедентную гибкость. Однако эта мощь сопряжена со значительным риском безопасности. Без надлежащих мер предосторожности iFrame могут стать векторами для различных атак, включая кликджекинг, межсайтовый скриптинг (XSS) и утечку данных. По мере того как веб-приложения становятся все более сложными и взаимосвязанными, понимание и внедрение лучших практик безопасности iFrame становится не просто желательным, а необходимым.

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

Основные меры безопасности iFrame: "Песочница" и CSP

1. Атрибут sandbox: Ваша первая линия обороны

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

Хотя по умолчанию "песочница" очень безопасна, она может быть слишком ограничительной для многих случаев использования. Вы можете выборочно снимать ограничения, предоставляя конкретные ключевые слова в качестве значений атрибута sandbox:

• allow-forms: Разрешает отправку форм.
• allow-modals: Разрешает iFrame открывать модальные окна (например, alert(), confirm(), prompt()).
• allow-popups: Разрешает всплывающие окна (например, window.open()).
• allow-popups-to-escape-sandbox: Разрешает документам в "песочнице" открывать новые окна без наследования ограничений "песочницы".
• allow-pointer-lock: Разрешает API блокировки указателя.
• allow-same-origin: Разрешает рассматривать содержимое iFrame как исходящее из того же источника, что и родительский документ, что часто необходимо для правильной работы встроенного контента (например, доступ к cookies, локальному хранилищу). Используйте с крайней осторожностью.
• allow-scripts: Разрешает выполнение JavaScript. Это мощное разрешение, и его следует предоставлять только доверенным источникам.
• allow-top-navigation: Разрешает iFrame навигировать по контексту просмотра верхнего уровня (т.е. изменять URL родительского окна).

Лучшая практика: Всегда используйте атрибут sandbox. Начните с значений по умолчанию (без значений) и добавляйте только минимально необходимые разрешения. Например, если вы встраиваете платежную форму, вам могут понадобиться allow-forms allow-scripts, но вам определенно не понадобится allow-same-origin, если это абсолютно не необходимо и тщательно не проверено.

<iframe src="https://trusted-payment-gateway.com/form" sandbox="allow-forms allow-scripts"></iframe>

2. Content Security Policy (CSP): Контроль загрузки контента

Content Security Policy (CSP) — это мощный механизм безопасности, который помогает смягчать различные типы атак, включая XSS и внедрение данных. Определяя CSP через заголовок HTTP (Content-Security-Policy) или тег <meta>, вы можете указать, какие источники контента разрешено загружать и выполнять браузеру.

Для безопасности iFrame CSP имеет решающее значение в двух основных аспектах:

• Защита родителя от iFrame: Надежный CSP на вашей родительской странице может предотвратить загрузку вредоносных скриптов или контента в ваше основное приложение со стороны скомпрометированного iFrame.
• Защита iFrame от родителя (и наоборот): Директива frame-src специально контролирует допустимые источники для iFrame. Директива frame-ancestors определяет, каким источникам разрешено встраивать текущий ресурс (вашу страницу) в iFrame, предотвращая кликджекинг.

Пример заголовка CSP:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; frame-src 'self' https://trusted-iframe-source.com; frame-ancestors 'self';

Этот CSP разрешает скрипты только из вашего собственного источника и trusted-cdn.com, а также разрешает iFrame только из вашего собственного источника и trusted-iframe-source.com. Важно отметить, что frame-ancestors 'self' гарантирует, что ваша страница может быть встроена только самой собой, эффективно предотвращая кликджекинг.

Защита от кликджекинга: X-Frame-Options и frame-ancestors

Кликджекинг (UI redressing) — это атака, при которой вредоносный веб-сайт накладывает прозрачный iFrame вашего сайта поверх своего собственного, обманывая пользователей, заставляя их нажимать на элементы вашего сайта, в то время как они думают, что взаимодействуют с вредоносным сайтом. Это может привести к несанкционированным действиям, таким как совершение покупок, изменение настроек или раскрытие конфиденциальной информации.

1. Заголовок HTTP X-Frame-Options

Заголовок HTTP X-Frame-Options — это традиционный способ предотвращения кликджекинга. Он сообщает браузерам, может ли страница быть отображена в <frame>, <iframe>, <embed> или <object>.

• X-Frame-Options: DENY: Страница не может быть отображена во фрейме, независимо от сайта, пытающегося это сделать. Это самый безопасный вариант.
• X-Frame-Options: SAMEORIGIN: Страница может быть отображена во фрейме только на том же источнике, что и сама страница.

Лучшая практика: Если вам не нужно явно встраивать вашу страницу на другие сайты (и если это так, используйте frame-ancestors осторожно), установите X-Frame-Options: DENY для всех страниц, обрабатывающих конфиденциальные действия пользователя.

2. Директива CSP frame-ancestors

Директива frame-ancestors в рамках Content Security Policy является более современной и гибкой альтернативой X-Frame-Options. Она позволяет указывать несколько источников, которым разрешено встраивать ваш контент.

Пример:

Content-Security-Policy: frame-ancestors 'self' https://partner-site.com;

Это позволяет встраивать вашу страницу самой собой и сайтом partner-site.com. Если присутствуют и X-Frame-Options, и frame-ancestors, то frame-ancestors обычно имеет приоритет в современных браузерах. Хорошей практикой является использование обоих для более широкой совместимости с браузерами.

Ответственная обработка данных и связь

Когда iFrame необходимо обмениваться данными со своим родительским окном (или наоборот), прямой доступ JavaScript обычно блокируется политикой Same-Origin. Рекомендуемый безопасный метод междоменной связи — window.postMessage().

Безопасное использование window.postMessage()

window.postMessage() позволяет окнам безопасно обмениваться данными между различными источниками. Однако крайне важно использовать его правильно, чтобы избежать уязвимостей.

• Всегда проверяйте источник отправителя: При получении сообщения всегда проверяйте свойство event.origin, чтобы убедиться, что сообщение пришло из ожидаемого источника.
• Указывайте целевой источник: При отправке сообщения указывайте точный целевой источник (например, iframeWindow.postMessage('hello', 'https://expected-origin.com');) вместо '*'. Использование '*' означает, что любое окно потенциально может получить ваше сообщение, что является риском безопасности.
• Очищайте полученные данные: Рассматривайте любые данные, полученные через postMessage(), как недоверенный ввод и очищайте их перед использованием для предотвращения XSS.

Пример (родитель отправляет в iFrame):

const iframe = document.getElementById('myIframe');
iframe.contentWindow.postMessage('Hello from parent!', 'https://trusted-iframe-source.com');

Пример (iFrame получает от родителя):

window.addEventListener('message', (event) => {
  if (event.origin !== 'https://parent-domain.com') {
    // Сообщение не из ожидаемого источника, игнорировать или записывать в журнал.
    return;
  }
  console.log('Сообщение от родителя:', event.data);
  // Обработать данные, но сначала очистить их!
});

Как Didit помогает с безопасными встраиваемыми рабочими процессами

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

• Размещенные ссылки для верификации: Didit генерирует безопасные, уникальные URL-адреса для каждой сессии верификации. Эти ссылки перенаправляют пользователей в изолированную среду, размещенную Didit, полностью отделяя чувствительный процесс верификации от домена вашего приложения. Это устраняет необходимость в сложной "песочнице" iFrame с вашей стороны для основной верификации.
• Веб-SDK с сильной изоляцией: Для сценариев, требующих встраивания в контекст, веб-SDK Didit разработан для работы в безопасном iFrame, используя самые строгие необходимые атрибуты sandbox. Мы управляем сложностями безопасной междоменной связи с использованием postMessage(), гарантируя, что между iFrame и вашим приложением обмениваются только необходимые, очищенные данные.
• Соответствие и сертификации: Didit сертифицирован SOC 2 Type II и ISO 27001, а также соответствует GDPR. Наша инфраструктура и процессы построены для безопасной обработки чувствительных данных идентификации, снижая вашу нагрузку на соответствие и риски.
• Минимальное раскрытие данных: Архитектура Didit основана на конфиденциальности по умолчанию. Для биометрической верификации селфи обрабатываются в памяти и удаляются, а ваше приложение получает булевы значения (например, 'verified'), а не необработанные биометрические данные. Это минимизирует количество чувствительной информации, обрабатываемой в любом встраиваемом компоненте.

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

Готовы начать?

Обеспечение безопасности ваших iFrame является критически важным шагом в создании устойчивого и надежного веб-приложения. Тщательно применяя "песочницу", CSP, X-Frame-Options и безопасные практики postMessage(), вы можете использовать всю мощь встроенного контента, не подвергая своих пользователей или свое приложение ненужным рискам. Изучите безопасные решения Didit для верификации личности, чтобы увидеть, как легко интегрировать надежную безопасность в ваши рабочие процессы.

Посмотреть цены Didit | Изучить документацию Didit | Попробовать демо