Почему фреймы считаются опасными и представляют угрозу безопасности?

125

Почему фреймы считаются опасными и представляют угрозу безопасности? Может кто-нибудь описать пример случая, когда это может быть использовано злонамеренно?

html  security  iframe 
— Дэниел Т.
источник
5
Это похоже на сказку старых жен. Окно вашего браузера - это просто один большой iframe.
— Билл Крисвелл,
1
Его уже спрашивали в stackoverflow
— Самич
1
@Samich - Нет, это касается наилучшей практики, а не конкретных проблем безопасности (и единственная проблема безопасности, о которой я могу думать, возникает от третьих лиц, использующих фреймы)
— Квентин
Не столько безопасность, сколько не считается лучшей практикой, см. Stackoverflow.com/questions/1081315/why-developers-hate-iframes. Они были намного популярнее, когда люди проектировали также таблицы, divs почти исключают необходимость в iframe.
— RandomUs1r
Как ни странно, почти десять лет спустя появилась статья, в которой предполагается, что размещение всего, что содержит форму, в iframe, изолированном от всего вашего стороннего javascript и т. Д., Возможно, необходимо для защиты форм от сбора. hackernoon.com/…
— GordonM 09

Ответы:

84

Как только вы показываете контент из другого домена, вы в основном доверяете этому домену не обслуживать вредоносное ПО.

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

— Диодей - Джеймс Макфарлейн
источник
19
Как только вы ссылаетесь на контент из другого домена и т. Д.… В этом нет ничего специфичного для iframe.
— Quentin
5
Правильно реализованные браузеры (также известные как пользовательский агент) не допустят утечки содержимого iframe за пределы iframe. Если основной документ (содержащий <iframe>элемент) имеет подходящий стиль и намекает, что iframe содержит ненадежный контент, проблем нет. Конечно, по модулю реальных уязвимостей в браузере. Короче говоря, <iframe>примерно так же безопасно, как <a href>.
— Микко Ранталайнен
2
А как насчет скрытого iframe, принадлежащего тому же домену? Это абсолютно безопасно?
— Кьяран Галлахер
2
Скрытие <iframe>из того же домена может вызвать угрозу безопасности, если злоумышленник может изменить содержимое скрытого iframe. Это позволит злоумышленнику распространить атаку XSS внутри скрытого <iframe>на любую страницу вашего сайта, которая ссылается на указанный <iframe>d-контент. Подробнее см. Stackoverflow.com/a/9428051/334451 .
— Mikko Rantalainen 07
Интересно, что iFrame действительно может быть полезной защитой от обратного случая. Если на вашем сайте много сторонних скриптов, вам необходимо изолировать от них формы. Один из предлагаемых способов сделать это - разместить форму на отдельной минимальной странице без стороннего javascript и отобразить ее в iframe на главной странице. hackernoon.com/…
— GordonM 09
140

Этот IFRAMEэлемент может представлять угрозу безопасности, если ваш сайт встроен IFRAMEво враждебный сайт . Google "кликджекинг" для более подробной информации. Учтите, что не имеет значения , используете вы<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-плеер. Ни один браузер не поддерживает одновременное использование плагинов и запрет навигации верхнего уровня.

Обратите внимание, что это 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

«Опасно» и «Риск безопасности» - не первое, что приходит на ум, когда люди упоминают фреймы… но их можно использовать в атаках с использованием кликджекинга .

— Quentin
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.