Ответ 1
W3C позаботился об этом в 1997 году, объяснив, как кадры должны быть реализованы в "Реализация HTML-фреймов":
Любой кадр, который пытается назначить в качестве своего SRC URL-адрес, используемый любым из его предков, обрабатывается так, как будто у него нет URL-адреса SRC вообще (в основном пустой кадр).
История ошибок/истории атаки Iframe
Как упоминалось в вышеупомянутом комментарии Kingdago, один браузер, который пропустил реализацию гарантии для этого, был Mozilla в 1999 году. Цитата от одного из разработчиков:
Это ошибка четности (и источник возможного embarrasment), поскольку MSIE5 не имеет проблем с этими типами страниц.
Я решил еще кое-что рассказать об этом, и оказалось, что в 2004 году это произошло снова. Однако на этот раз было задействовано JavaScript:
Это код, что его вызывает: < iframe name= "productcatalog" id = "productcatalog" src= "page2.htm" > </iframe> , за которым следуют a script с этим в нем: frames.productcatalog.location.replace(frames.productcatalog.location + location.hash);
...
Фактические результаты: родительское окно рекурсивно загружается в iframe, что иногда приводит к сбою.
Ожидаемые результаты: просто покажите это как в Internet Explorer.
Затем снова в 2008 году с Firefox 2 (это также связано с JavaScript).
И снова в 2009 году. Интересная часть здесь заключается в том, что эта ошибка все еще открыта, и это приложение: https://bugzilla.mozilla.org/attachment.cgi?id=414035
(вы ограничьте свое любопытство?) все равно будет разбивать/замораживать ваш Firefox (я только что протестировал его, и я почти разбил весь Ubuntu). В Chrome он просто загружается бесконечно (возможно, потому, что каждая вкладка живет в отдельном процессе).
Что касается других браузеров:
- В 2005 году Konqueror была обнаружена ошибка в том, что позволило отображать iframes один внутри другого (но кажется, что каким-то образом это не замерзло/сбой всего приложения).
- IE6, Opera 7.54 и Firefox 0.9.3 также сообщили, чтобы быть восприимчивыми к атак на основе рекурсии iframe.