Почему фреймы считаются опасными и представляют угрозу безопасности?
125
Почему фреймы считаются опасными и представляют угрозу безопасности? Может кто-нибудь описать пример случая, когда это может быть использовано злонамеренно?
@Samich - Нет, это касается наилучшей практики, а не конкретных проблем безопасности (и единственная проблема безопасности, о которой я могу думать, возникает от третьих лиц, использующих фреймы)
Как ни странно, почти десять лет спустя появилась статья, в которой предполагается, что размещение всего, что содержит форму, в iframe, изолированном от всего вашего стороннего javascript и т. Д., Возможно, необходимо для защиты форм от сбора. hackernoon.com/…
GordonM 09
Ответы:
84
Как только вы показываете контент из другого домена, вы в основном доверяете этому домену не обслуживать вредоносное ПО.
В самих фреймах нет ничего плохого. Если вы контролируете содержимое iframe, они совершенно безопасны.
Как только вы ссылаетесь на контент из другого домена и т. Д.… В этом нет ничего специфичного для 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) может заразить вашего пользователя
«Опасно» и «Риск безопасности» - не первое, что приходит на ум, когда люди упоминают фреймы… но их можно использовать в атаках с использованием кликджекинга .
Ответы:
Как только вы показываете контент из другого домена, вы в основном доверяете этому домену не обслуживать вредоносное ПО.
В самих фреймах нет ничего плохого. Если вы контролируете содержимое iframe, они совершенно безопасны.
источник
<iframe>элемент) имеет подходящий стиль и намекает, что iframe содержит ненадежный контент, проблем нет. Конечно, по модулю реальных уязвимостей в браузере. Короче говоря,<iframe>примерно так же безопасно, как<a href>.<iframe>из того же домена может вызвать угрозу безопасности, если злоумышленник может изменить содержимое скрытого iframe. Это позволит злоумышленнику распространить атаку XSS внутри скрытого<iframe>на любую страницу вашего сайта, которая ссылается на указанный<iframe>d-контент. Подробнее см. Stackoverflow.com/a/9428051/334451 .Этот
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?<iframe>на странице, она позволяет распространить уязвимость с содержимого в iframe на хост-документ. Вопрос был в том,<iframe>что это опасно, и если основной документ имеет XSS-уязвимость, вам действительно не нужен этот<iframe>элемент.Я предполагаю междоменный iFrame, поскольку, по-видимому, риск был бы ниже, если бы вы контролировали его самостоятельно.
источник
«Опасно» и «Риск безопасности» - не первое, что приходит на ум, когда люди упоминают фреймы… но их можно использовать в атаках с использованием кликджекинга .
источник
iframe также уязвим для кросс-фреймовых скриптов:
источник