Найкращі практики безпеки iframe для вебзастосунків

Зміст

1. Що таке iframe у веббезпеці?
2. Які ризики безпеки створюють елементи iframe?
   1. Клікджекінг
   2. Шкідливий або скомпрометований сторонній контент
   3. Небезпечний міждоменний обмін повідомленнями
   4. Розкриття конфіденційних даних
   5. Надмірні дозволи браузера
3. Чому реалізації iframe зазнають невдачі?
4. Найкращі практики безпеки iframe
   1. Використання атрибута sandbox
   2. Обмеження дозволів iframe
   3. Контроль джерел iframe за допомогою CSP
   4. Запобігання несанкціонованому фреймінгу за допомогою frame-ancestors
   5. Валідація джерел та даних postMessage()
   6. Дозвіл лише для надійних джерел iframe
   7. Запобігання розміщенню конфіденційних даних в адресах URL елементів iframe
   8. Застосування глибокого ешелонованого захисту до конфіденційних дій
   9. Тестування поведінки iframe під час змін у застосунку
5. Приклад безпечного iframe
6. Як тестування безпеки застосунків допомагає виявляти ризики iframe
7. Чекліст безпеки iframe
8. Висновок: безпечне використання iframe вимагає явної довіри
   1. Запит на безкоштовне тестування Invicti

Елементи iframe полегшують вбудовування стороннього контенту та сервісів, проте водночас створюють нові межі довіри та ризики на рівні браузера. У цій статті розглядаються способи захисту реалізацій iframe за допомогою ізоляції (sandboxing), політики захисту контенту (Content Security Policy), обмежень фреймінгу, безпечнішого обміну повідомленнями між різними джерелами (cross-origin) і тестування безпеки застосунків.

Елементи iframe широко використовуються для вбудовування відео, платіжних форм, аналітичних панелей, процесів автентифікації та інших сторонніх сервісів у вебзастосунках. Вони забезпечують зручний спосіб інтеграції контенту без необхідності розробки кожного компонента безпосередньо в батьківській сторінці.

Така зручність створює додаткові межі довіри. Застосунок має враховувати взаємозв’язок між батьківською сторінкою, вбудованим документом, джерелом цього документа та механізмами контролю браузера, які регулюють їхню взаємодію.

Небезпечні реалізації iframe можуть сприяти клікджекінгу, небезпечному міждоменному обміну повідомленнями (cross-origin messaging), розкриттю даних та іншим браузерним ризикам. Безпечна реалізація вимагає більшого, ніж просто довіра до постачальника контенту. Командам необхідно обмежувати можливості iframe, контролювати джерела для завантаження, запобігати несанкціонованому фреймінгу, перевіряти повідомлення та тестувати кінцеву поведінку застосунку.

Що таке iframe у веббезпеці?

Елемент iframe – це HTML-елемент, який вбудовує одну вебсторінку всередину іншої:

<iframe src="https://example.com"></iframe>

Вбудована сторінка виконується в окремому контексті перегляду. Коли батьківська сторінка та вміст iframe походять із різних джерел, політика однакового джерела браузера зазвичай забороняє обом документам безпосередньо звертатися до DOM, файлів cookie або стану JavaScript одне одного. Така ізоляція є важливою, але вона не становить повноцінної межі безпеки. Елемент iframe усе ще може:

• Виконувати скрипти в межах свого власного джерела.
• Надсилати форми або відкривати нові контексти перегляду.
• Надсилати запити на доступ до визначених функцій браузера.
• Обмінюватися повідомленнями з іншими вікнами за допомогою postMessage().
• Відображати оманливий або шкідливий контент.
• Використовуватися іншим сайтом для вбудовування сторінки з конфіденційними даними.

Точні можливості залежать від конфігурації iframe, вбудованого застосунку, джерела контенту та політик безпеки браузера.

Які ризики безпеки створюють елементи iframe?

Елементи iframe не є небезпечними за своєю суттю. Ризик виникає тоді, коли застосунки вбудовують ненадійний контент, надають непотрібні можливості, приймають повідомлення без валідації або дозволяють несанкціонованим сайтам вбудовувати у фрейми сторінки з конфіденційними даними.

Клікджекінг

Клікджекінг – це атака на інтерфейс користувача, під час якої зловмисник завантажує справжню сторінку всередині прихованого або прозорого iframe та розміщує поверх неї оманливі елементи керування. Користувач вважає, що натискає на один елемент, але насправді взаємодіє із фреймованим застосунком. Залежно від цільового робочого процесу, це може ініціювати:

• Зміну налаштувань облікового запису або дозволів.
• Надсилання форми.
• Здійснення покупки або переказу.
• Надання критично важливого для безпеки підтвердження.
• Іншу дію, що виконується через автентифіковану сесію користувача.

Клікджекінг не вимагає від зловмисника виконання коду в цільовому застосунку. Цей метод експлуатує особливості відображення застосунку та способи взаємодії користувачів із ним.

Шкідливий або скомпрометований сторонній контент

Вбудовування сторонньої сторінки створює залежність від безпеки та поведінки постачальника. Навіть якщо ізоляція між різними джерелами запобігає прямому доступу до DOM, шкідливий фреймований контент усе ще може відображати фішингові інтерфейси, ініціювати небажану навігацію, надсилати запити на дозволи або намагатися ввести користувачів в оману.

Надійний постачальник також може з часом змінювати свої скрипти, домени або вимоги до інтеграції. Якщо постачальника буде скомпрометовано, фреймований контент може стати шкідливим без жодних змін у батьківському застосунку.

Тому кожне вбудоване джерело необхідно розглядати як частину моделі зовнішніх залежностей та довіри застосунку.

Небезпечний міждоменний обмін повідомленнями

Батьківські сторінки та елементи iframe часто обмінюються даними за допомогою API window.postMessage().

Цей механізм призначений для контрольованої комунікації між різними джерелами, проте він стає небезпечним, коли будь-яка зі сторін приймає повідомлення надто широко.

До поширених помилок належать:

• Надсилання повідомлень із символом * як цільовим джерелом.
• Відсутність перевірки event.origin.
• Припущення про те, що дані повідомлення є надійними.
• Вставлення даних повідомлення в DOM без належної безпечної обробки.
• Надання дозволу повідомленням ініціювати конфіденційні дії без перевірок авторизації.

Небезпечна обробка повідомлень може призвести до витоку даних або створити вектор вводу для міжсайтового скриптингу (XSS) та інших вразливостей логіки застосунку.

Розкриття конфіденційних даних

Застосунки іноді передають дані до вбудованого контенту через параметри запиту, фрагменти, повідомлення або спільний стан застосунку.

Конфіденційну інформацію не слід розміщувати в адресах URL елементів iframe, оскільки адреси URL можуть зберігатися в історії браузера, журналах серверів, аналітичних системах або даних реферера. Токени автентифікації, ідентифікатори сесій, особиста інформація та фінансові дані потребують особливої обережності.

Дані також можуть бути розкриті, коли застосунок надсилає більше інформації, ніж потрібно вбудованому сервісу, або не перевіряє отримувача перед надсиланням повідомлення.

Надмірні дозволи браузера

Вбудований контент може запитувати доступ до таких можливостей браузера, як камера, мікрофон, геолокація, повноекранний режим або функції оплати.

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

У застосунках необхідно дозволяти лише ті функції, які вимагаються для конкретної інтеграції.

Чому реалізації iframe зазнають невдачі?

Більшість збоїв у безпеці iframe виникає через надмірну довіру або надто широку конфігурацію. Розробники можуть припускати, що відомий сторонній постачальник завжди є безпечним, покладатися лише на політику однакового джерела (same-origin policy) або активувати одразу кілька можливостей iframe задля пришвидшення інтеграції.

Як наслідок, засоби контролю безпеки залишаються занадто дозвільними після початкового впровадження.

До поширених причин належать:

• Пропуск атрибута sandbox.
• Додавання непотрібних винятків для пісочниці.
• Надання користувачам можливості контролювати джерела для iframe.
• Використання широких виразів для джерел у політиці Content Security Policy (CSP).
• Відсутність обмежень щодо того, які сайти можуть вбудовувати сторінки з конфіденційними даними.
• Приймання подій postMessage() від будь-якого джерела.
• Передавання конфіденційних даних через адреси URL.
• Збереження невикористовуваних сторонніх вбудовувань у середовищі продакшн.

Безпечне використання iframe вимагає чітких рішень щодо того, що саме вбудований контент може завантажувати, до чого отримувати доступ і як здійснювати комунікацію.

Найкращі практики безпеки iframe

Використання атрибута sandbox

Атрибут sandbox обмежує можливості фреймованого контенту. Порожній атрибут застосовує широкий набір обмежень:

<iframe src="https://widgets.example.com" sandbox></iframe>

Після цього застосунки можуть вибірково відновлювати необхідні можливості за допомогою токенів пісочниці:

<iframe 
  src="https://widgets.example.com" 
  sandbox="allow-scripts allow-forms">
</iframe>

Доступні обмеження та винятки охоплюють такі дії, як:

• Виконання скриптів.
• Надсилання форм.
• Завантаження.
• Спливаючі вікна.
• Навігація верхнього рівня.
• Обробка в межах одного джерела.

Розпочинати необхідно з найбільш суворої конфігурації, додаючи дозволи лише тоді, коли інтеграція не може функціонувати без них. Особливої обережності вимагає поєднання allow-scripts та allow-same-origin. Якщо контент із того самого джерела отримує обидва дозволи, він може видалити атрибут sandbox та уникнути встановлених обмежень. За можливості ненадійний фреймований контент слід надавати з окремого джерела та уникати надання такої комбінації дозволів.

Обмеження дозволів iframe

Для контролю доступу до функцій браузера необхідно використовувати атрибут allow елемента iframe та заголовок Permissions Policy.

Наприклад:

<iframe
  src="https://widgets.example.com"
  sandbox="allow-scripts allow-forms"
  allow="camera 'none'; microphone 'none'; geolocation 'none'">
</iframe>

Не слід надавати доступ до таких можливостей, як камера, мікрофон, геолокація, функції оплати або буфер обміну, за винятком випадків, коли вони є необхідними для вбудованого робочого процесу.

Контроль джерел iframe за допомогою CSP

Політика Content Security Policy може обмежувати джерела, з яких застосунок має змогу завантажувати контент у фрейми.

Директива frame-src контролює джерела iframe:

Content-Security-Policy: frame-src 'self' https://widgets.example.com;

Ця політика дозволяє сторінці вбудовувати контент із власного джерела та від указаного постачальника. Необхідно уникати широких виразів, таких як *, якщо немає задокументованої та невідворотної вимоги.

Слід підтримувати конкретний список дозволених схвалених джерел і переглядати його в разі зміни сторонніх інтеграцій. Варто зазначити, що frame-src контролює те, що саме може вбудовувати поточна сторінка. Ця директива не контролює тих, хто може вбудовувати поточну сторінку.

Запобігання несанкціонованому фреймінгу за допомогою frame-ancestors

Для того щоб визначити, які сайти можуть розміщувати сторінку всередині iframe, необхідно використовувати директиву CSP frame-ancestors.

Щоб запобігти будь-якому фреймінгу:

Content-Security-Policy: frame-ancestors 'none';

Щоб дозволити фреймінг лише з того самого джерела:

Content-Security-Policy: frame-ancestors 'self';

Щоб дозволити конкретне довірене батьківське джерело:

Content-Security-Policy: frame-ancestors 'self' https://portal.example.com;

Директива frame-ancestors є основним сучасним засобом контролю для захисту від клікджекінгу, оскільки вона підтримує кілька явно вказаних джерел та гнучкі політики.

Старіший заголовок X-Frame-Options може забезпечити додаткову сумісність:

X-Frame-Options: DENY

або:

X-Frame-Options: SAMEORIGIN

Не слід покладатися на застаріле значення ALLOW-FROM. Варто також зазначити, що заголовок X-Frame-Options ігнорується, якщо в браузерах, які підтримують цю функцію, присутня директива frame-ancestors.

Сторінки з конфіденційними даними, такі як екрани автентифікації, робочі процеси оплати, налаштування облікового запису та адміністративні інтерфейси, не повинні підлягати фреймінгу, якщо тільки вбудовування не є навмисною вимогою.

Валідація джерел та даних postMessage()

Під час надсилання повідомлення необхідно зазначати точне очікуване цільове джерело замість *:

const frame = document.querySelector("#payment-frame");

frame.contentWindow.postMessage(
  { action: "start-payment", orderId: "12345" },
  "https://payments.example.com"
);

Під час отримання повідомлень перед обробкою даних потрібно перевіряти джерело відправника:

window.addEventListener("message", (event) => {
  if (event.origin !== "https://payments.example.com") {
    return;
  }

  if (
    typeof event.data !== "object" ||
    event.data === null ||
    event.data.type !== "payment-status"
  ) {
    return;
  }

  // Validate status against expected values in production use
  updatePaymentStatus(event.data.status);
});

Валідація джерела – це лише перший крок. Тіло повідомлення слід розглядати як ненадійні вхідні дані та перевіряти його тип, структуру, дозволені значення, а також зв’язок із поточним користувачем або транзакцією.

Не слід вставляти дані повідомлення в DOM, використовуючи небезпечні API, такі як innerHTML. Не можна дозволяти одному лише повідомленню ініціювати виконання чутливих дій.

Дозвіл лише для надійних джерел iframe

У застосунках не слід конструювати значення src для iframe безпосередньо з ненадійних вхідних даних. Адреса URL фрейма, що контролюється користувачем, може завантажити фішинговий контент, шкідливі сторінки або неочікувані джерела всередині інтерфейсу надійного застосунку.

Необхідно використовувати фіксований набір схвалених адрес URL або зіставляти відомі ідентифікатори із заздалегідь визначеними джерелами на сервері.

Для сторонніх постачальників:

• Необхідно перевіряти їхні практики безпеки та документацію з інтеграції.
• Потрібно підтверджувати точні домени, яких вимагає інтеграція.
• Слід здійснювати моніторинг змін у доменах і скриптах.
• Необхідно видаляти інтеграції, які більше не використовуються.
• Варто повторно оцінювати постачальника в разі зміни його власника або сервісу.

Довіра має бути явною, обмеженою та регулярно переглядатися.

Запобігання розміщенню конфіденційних даних в адресах URL елементів iframe

Не слід розміщувати токени доступу, ідентифікатори сесій, персональні дані або інші секрети в адресі URL атрибута src елемента iframe. Необхідно використовувати відповідний механізм автентифікованого обміну та надсилати лише ту інформацію, яка вимагається для вбудованого робочого процесу.

У випадках, коли міждоменні повідомлення є необхідними, варто перевіряти як відправника, так і отримувача, а також уникати розкриття довгострокових облікових даних.

Слід враховувати атрибут referrerpolicy елемента iframe, коли фреймованому сайту не потрібна повна батьківська адреса URL:

<iframe
  src="https://widgets.example.com"
  sandbox="allow-scripts"
  referrerpolicy="strict-origin-when-cross-origin">
</iframe>

Вибір відповідної політики залежить від інтеграції та вимог застосунку щодо конфіденційності.

Застосування глибокого ешелонованого захисту до конфіденційних дій

Обмеження фреймінгу є важливими для запобігання клікджекінгу, проте конфіденційні серверні операції також повинні вимагати належного захисту. Залежно від робочого процесу, елементи контролю можуть охоплювати:

• Перевірки авторизації для кожної дії.
• Засоби захисту від підробки міжсайтових запитів (CSRF).
• Повторну автентифікацію для змін із високим рівнем ризику.
• Явне підтвердження важливих транзакцій.
• Сесійні файли cookie з атрибутом SameSite.
• Елементи контролю ідемпотентності та захисту від повторного відтворення.

Запит браузера не слід вважати безпечним лише через те, що він надходить з автентифікованої сесії.

Тестування поведінки iframe під час змін у застосунку

Безпека iframe може погіршуватися, коли команди додають нового постачальника, послаблюють правило CSP, модифікують обробник повідомлень або змінюють процес автентифікації.

Перевірки безпеки мають охоплювати:

• Сторінки, які можуть бути вбудовані у фрейми зовнішніми сайтами.
• Політики frame-src та frame-ancestors у CSP.
• Поведінку X-Frame-Options у випадках використання.
• Токени пісочниці (sandbox) та дозволи браузера.
• Адреси URL елементів iframe, що контролюються користувачами.
• Валідацію відправника та даних у postMessage().
• Конфіденційну інформацію, яка передається до вбудованого контенту.
• Сторонні інтеграції, що більше не вимагаються.

Тестування повинно охоплювати як перевірку статичної конфігурації, так і поведінку під час виконання. Деякі проблеми стають помітними лише тоді, коли застосунок завантажується, автентифікує користувачів або обмінюється даними з фреймованим сервісом.

Приклад безпечного iframe

Універсальної конфігурації iframe не існує, оскільки необхідні можливості різняться залежно від варіанта використання. Наведений нижче приклад демонструє жорстку початкову конфігурацію для надійної форми від стороннього постачальника:

<iframe
  id="support-form"
  src="https://support.example.com/embedded-form"
  sandbox="allow-scripts allow-forms"
  allow="camera 'none'; microphone 'none'; geolocation 'none'"
  referrerpolicy="strict-origin-when-cross-origin"
  loading="lazy"
  title="Customer support form">
</iframe>

Відповідна політика CSP може обмежувати як джерела для вбудовування, так і несанкціонований фреймінг:

Content-Security-Policy: frame-src https://support.example.com; frame-ancestors 'self';

Перед використанням цього налаштування необхідно переконатися, що інтеграція не вимагає додаткових дозволів для пісочниці (sandbox). Не слід додавати токени заздалегідь.

Як тестування безпеки застосунків допомагає виявляти ризики iframe

Тестування безпеки застосунків може допомогти командам знайти слабкі місця безпеки, пов’язані з поведінкою фреймінгу, політиками браузера, вхідними даними застосунку та взаємодією під час виконання. Динамічне тестування безпеки застосунків (DAST) перевіряє запущений застосунок ззовні, використовуючи ті самі інтерфейси, які доступні користувачам та зловмисникам.

Це робить DAST корисним для виявлення вебвразливостей та неправильних конфігурацій, які проявляються під час роботи застосунку.

Тестування може виявити такі проблеми, як:

• Сторінки, вразливі до клікджекінгу.
• Відсутні або слабкі заголовки безпеки.
• Вразливості міжсайтового скриптингу (XSS) під час обробки повідомлень або вхідних даних.
• Джерела контенту, що контролюються користувачами.
• Вразлива поведінка застосунку, доступна через браузер.
• Засоби контролю безпеки, які відрізняються в середовищах розробки та продакшн.

Автоматизоване тестування повинно доповнювати перевірку коду, моделювання загроз, перевірку конфігурації та ручне тестування. Жоден окремий метод не може оцінити кожен аспект довіри до iframe та поведінки браузера.

Чекліст безпеки iframe

Перед розгортанням або затвердженням інтеграції iframe необхідно підтвердити, що:

• Iframe завантажує контент лише зі схваленого джерела.
• Атрибут sandbox має початкові налаштування з мінімально необхідними дозволами.
• Функції браузера обмежені за допомогою атрибута allow або політики Permissions Policy.
• Директива CSP frame-src обмежує, який саме контент може вбудовувати застосунок.
• Директива CSP frame-ancestors запобігає вбудовуванню сторінок із конфіденційними даними несанкціонованими сайтами.
• Заголовок X-Frame-Options встановлено там, де це виправдано вимогами до сумісності.
• Механізм postMessage() використовує точні цільові джерела.
• Одержувачі повідомлень перевіряють параметр event.origin та дані повідомлення.
• Конфіденційна інформація не розміщується в адресах URL елементів iframe.
• Введені користувачами дані не можуть безпосередньо контролювати джерело iframe.
• Авторизація на боці сервера захищає конфіденційні дії.
• Інтеграція включена до процесів регулярного тестування та перевірок безпеки.

Висновок: безпечне використання iframe вимагає явної довіри

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

Найбезпечнішим підходом є використання найбільш суворої початкової конфігурації, надання дозволів лише схваленим джерелам, забезпечення мінімально необхідних можливостей та запобігання фреймінгу сторінок із конфіденційними даними без авторизації. Командам також слід розглядати міждоменні повідомлення як ненадійні вхідні дані та повторно тестувати поведінку iframe щоразу, коли змінюються застосунки, політики браузера або сторонні інтеграції.

Ці елементи контролю знижують специфічні для iframe ризики, проте вони є лише однією зі складових захисту сучасного середовища застосунків. Команди з безпеки також потребують послідовного способу виявлення активів, тестування запущених застосунків та API, централізації результатів і пріоритизації процесів усунення недоліків протягом усього життєвого циклу програмного забезпечення.

Платформа Invicti об’єднує ці можливості, причому DAST і сканування на основі доказів забезпечують критично важливе уявлення під час виконання про те, що насправді є вразливим, а для багатьох вразливостей прямого впливу – що має докази можливості експлуатації. Поєднуючи високонадійне динамічне тестування з ширшою видимістю безпеки застосунків (AppSec), кореляцією та управлінням робочими процесами, Invicti допомагає командам зосередитися на найважливіших вразливостях.

Оформлення запиту на демонстрацію дає змогу дізнатися, як платформа безпеки застосунків із пріоритетом DAST допомагає знаходити, перевіряти, пріоритизувати та управляти ризиками у вебзастосунках та API.

Запит на безкоштовне тестування Invicti

Я погоджуюсь з політикою конфіденційності