Чому iframe вважаються небезпечними та загрожують безпеці?

124

Чому iframe вважаються небезпечними та загрожують безпеці? Чи може хтось описати приклад випадку, коли його можна зловмисно використовувати?

html  security  iframe 
— Даніель Т.
джерело
5
Це звучить як стара казка про дружин. Вікно вашого веб-переглядача - це лише один великий кадр.
— Білл Крісвелл
1
Про це вже запитували в
— stackoverflow
1
@Samich - Ні, це стосується найкращої практики, а не конкретних питань безпеки (і єдиний питання безпеки, про який я можу придумати, виникає у третіх сторін за допомогою iframes)
— Квентін,
Не так багато , як безпека його не рахується найкращою практикою, см: stackoverflow.com/questions/1081315/why-developers-hate-iframes Вони були набагато більш популярним , коли люди , розроблені з таблицями також, діви все , але усунути необхідність фреймів.
— RandomUs1r
Досить смішно, що майже десятиліття пізніше з’явилася стаття, яка дозволяє припустити, що розміщення всього, що містить форму, у iframe, ізольованому від усіх сторонніх javascript тощо, можливо, необхідне для захисту форм від збирання. hackernoon.com/…
— GordonM

Відповіді:

83

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

Немає нічого поганого в iframes per se. Якщо ви контролюєте вміст iframe, вони абсолютно безпечні.

— Діодей - Джеймс Макфарлейн
джерело
19
Як тільки ви посилаєтесь на вміст з іншого домену тощо тощо ... Тут немає нічого конкретного рамки.
— Квентін
5
Правильно реалізовані браузери (він же User Agent) не дозволять вмісту iframe витікати за межі iframe. Якщо хост-документ (той, що містить <iframe>елемент) має відповідний стиль та натякає, що iframe містить недовірений вміст, проблем немає. Модульна реальна вразливість у браузері, звичайно. Коротше кажучи, an <iframe>настільки ж безпечний, як <a href>.
— Мікко Ранталайнен
2
А як щодо прихованого iframe, що належить до одного домену? Це цілком безпечно?
— Ciaran Gallagher
2
Прихований <iframe>з того ж домену може спричинити загрозу безпеці, якщо зловмисник змінить вміст всередині прихованого iframe. Це дозволить зловмиснику поширити атаку XSS всередині прихованої <iframe>на будь-яку сторінку на вашому сайті, яка посилається на вказаний <iframe>вміст d. Докладніше див. У розділі stackoverflow.com/a/9428051/334451 .
— Мікко Ранталайнен
Цікаво, що iFrame може бути корисним захистом від зворотного випадку. Якщо у вас на сайті багато скриптів, вам потрібно ізолювати форми від них. Один із запропонованих способів зробити це - розмістити форму на власній мінімальній сторінці без сторонніх javascript та відобразити її у iframe на головній сторінці. hackernoon.com/…
— GordonM
140

Цей IFRAMEелемент може становити загрозу безпеці, якщо ваш сайт вбудований у IFRAMEворожий сайт . Google "clickjacking" для отримання детальної інформації. Зверніть увагу, що це не має значення, використовуєте ви це<iframe> чи ні. Єдиний реальний захист від цієї атаки - додавання заголовка HTTP X-Frame-Options: DENYта сподівання, що браузер знає свою роботу.

Крім того, елемент IFRAME може становити загрозу безпеці, якщо будь-яка сторінка на вашому сайті містить вразливість XSS, яку можна використовувати . У такому випадку зловмисник може розширити атаку XSS на будь-яку сторінку в межах одного домену, яку можна переконати завантажити в межах <iframe>сторінки зі вразливістю XSS. Це тому, що вмісту з того самого походження (того самого домену) дозволено отримувати доступ до батьківського вмісту DOM (практично виконувати JavaScript у документі "хост"). Єдині реальні способи захисту від цієї атаки - додавати HTTP-заголовок X-Frame-Options: DENYта / або завжди правильно кодувати всі представлені користувачем дані (тобто ніколи не мати вразливість XSS на своєму сайті - простіше сказати, ніж зробити).

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

Якщо хтось стверджує, що використання <iframe>елемента на вашому веб-сайті небезпечно і створює ризик для безпеки, він не розуміє, що <iframe>робить елемент, або він говорить про можливість <iframe>пов'язаних з цим вразливих місць у браузерах. Захищеність <iframe src="...">тегу дорівнює <img src="..."або <a href="...">доки в браузері немає вразливостей. І якщо є відповідна вразливість, це може бути можливим , щоб викликати його , навіть без використання <iframe>, <img>або <a>елемента, так що не варто розглядати цю проблему.

Однак слід попередити, що вміст із сайту <iframe>може запускати навігацію верхнього рівня за замовчуванням . Тобто вмісту в межах <iframe>дозволено автоматично відкривати посилання над поточним розташуванням сторінки (нове розташування буде видно в адресному рядку). Єдиний спосіб уникнути цього - додати sandboxатрибут без значення allow-top-navigation. Наприклад, <iframe sandbox="allow-forms allow-scripts" ...>. На жаль, пісочниця також завжди відключає всі плагіни. Наприклад, вміст Youtube не може бути пісочницею, оскільки для перегляду всього вмісту Youtube все ще потрібен Flash Player. Жоден браузер не підтримує використання плагінів та забороняє навігацію верхнього рівня одночасно.

Зверніть увагу, що X-Frame-Options: DENYтакож захищає від атаки бічних каналів продуктивності, яка може читати вміст перехресного походження (також відомий як " Pixel perfect Timing Attacks ").

— Мікко Ранталайнен
джерело
Добре, але чи не "This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."слід перефразовувати у бік (батьківського) документа, що містить вразливість XSS до (дочірнього) документа в iframe?
— Шучжен
@Shuzheng вразливість відбувається обома способами, і якщо ви використовуєте <iframe>на сторінці, це дозволяє розширити вразливість із вмісту в iframe для розміщення документа. Питання полягало в тому, щоб <iframe>бути небезпечним, і якщо хост-документ має вразливість XSS, <iframe>елемент вам дійсно не потрібен .
— Мікко Ранталайнен
13

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

  • Clickjacking - це проблема, якщо ваш сайт включений у рамку iframe
  • Компрометований iFrame може відображати шкідливий вміст (уявіть, що iFrame відображає поле для входу замість реклами)
  • Включений iframe може здійснювати певні дзвінки JS, такі як попередження та підказки, які можуть дратувати вашого користувача
  • Включений iframe може переспрямовувати через location.href (виходить, уявіть, що 3p кадр перенаправляє клієнта з bankofamerica.com на bankofamerica.fake.com)
  • Зловмисне програмне забезпечення в рамці 3p (java / flash / activeX) може заразити вашого користувача
— Джо Зак
джерело
2

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

— Квентін
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.