Безопасно ли разрешить пользователю определять контент iframe, который будет отображаться на странице?
Например. Существует форма отправки некоторого текста разметки html. Этот текст будет показан на одной странице в iframe.
UPD: Еще одна попытка объяснить: есть страница со следующим контентом:
<html>
<head>...</head>
<body>
...
<iframe>
#document
user-defined content here
</iframe>
...
</body>
</html>
Где "пользовательский контент" является пользовательским контентом. Пользователи могут написать некоторые html-разметки, которые будут показаны на этой странице. Если пользовательский контент будет выглядеть примерно так:
<head>...</head>
<body>
<p>I am awesome user!</p>
</body>
Затем будет отображаться содержимое страницы:
<html>
<head>...</head>
<body>
...
<iframe>
#document
<head>...</head>
<body>
<p>I am awesome user!</p>
</body>
</iframe>
...
</body>
</html>
<iframe>
user-defined content here
</iframe>
Во-первых, это на самом деле не работает. Содержимое <iframe>
отображается только как резервное копирование для старых браузеров, которые не поддерживают iframe, вы не можете включать туда контент тела. Чтобы вставлять контент в iframe с родительской страницы, вам нужно либо:
data:
(не будет работать в IE)iframe srcdoc
(недавняя версия HTML5, не поддерживается)Если вы выполните одно из этих действий или если у вас есть пользовательский контент, обслуживаемый с другого URL-адреса под тем же именем хоста, то контент имеет тот же исходный код JavaScript, что и ваш сайт, и любой скрипт злоумышленника в iframe будет иметь доступ ко всем в сеанс пользователя на вашем сайте. Обтекание содержимого одного и того же происхождения в одном только iframe не дает вам какой-либо границы безопасности.
Обычно это будет представлять собой атаку межсайтового скриптинга (XSS) и не будет считаться приемлемым. Возможно, у вас может быть необычная пользовательская модель, в которой XSS не вызывает проблемы, но если у вас есть что-то вроде авторизации доступа на основе зарегистрированного пользователя или защищенных паролем учетных записей, тогда XSS нарушит эти меры.
Если вы хотите разрешить произвольный контент HTML без нарушения контроля доступа, вы должны либо:
удалите возможности сценариев, дезактивируя входные данные с помощью белого списка известных хороших тегов и атрибутов (это не так просто, поэтому посмотрите на проверенные и проверенные библиотеки, чтобы сделать это для вас, например htmlpurifier, если вы используете PHP);
в будущем iframe sandbox
также может удалить скрипты из содержимого iframe, но недостаточно надежно поддерживается;
если вы должны разрешить сценарий, то, как предложил Квентин, обслуживать пользовательский контент из другого домена.
(Есть вещи, о которых стоит беспокоиться о том, когда вы включаете произвольный контент HTML в iframe, например, атаки на фишинг и обратный клик, но ничего плохого, как XSS.)
#document
в iframe. Я исправлю это в данный момент. Похоже, iframe sandbox
- это то, что мне нужно. Является ли удаление сценариев решением проблемы безопасности? @Quentin рассказал мне о CSRF-атаках, похоже, что для этого типа атаки не требуется JS.
#document
, это ничего не делает. iframe sandbox
- это что-то для будущего, вы не можете использовать ее сегодня, потому что есть еще много браузеров, которые не поддерживают ее для пользователей тех браузеров, что ваш сайт будет уязвим. Удаление сценариев предотвращает атаки XSS, оно не помогает вам против всего, что у вас может быть. CSRF - это проблема, которую вам нужно решить для любого приложения, ее чуть проще использовать, чем обычно, если вы разрешаете отправленный пользователем HTML-код, который может содержать формы контента.
Есть три вещи, которые могут пойти не так:
Изолируйте iframe таким образом, чтобы код не касался вашего основного сайта. Поместите код, который генерирует содержимое для iframe в другом домене для кода, который загружает фрейм.
Обычно небезопасно, так как вы оставите свой сайт открытым для XSS.
Однако вы можете внедрить политику безопасности контента для страницы, которая выводит Iframe.
Это позволит вам отключить скрипты на этой странице, поэтому, если пользователь вводит теги <script>
или использует атрибуты, которые обычно запускают клиентский скрипт, они будут игнорироваться браузером.
Это реализовано через заголовок ответа HTTP. например
Content-Security-Policy: script-src 'self' https://apis.google.com
Этот заголовок позволяет запускать скрипты с https://apis.google.com
и сценарии из локального домена для выполнения, но это предотвратит встроенные скрипты в HTML. Эти параметры настраиваются, чтобы делать все, что вам нужно.
#document
? Я не могу работать, является ли это фактическая наценка или вы имеете в виду ли этоsrc
документа , на который ссылаетсяiframe
?