Пользовательский iframe на странице

0

Безопасно ли разрешить пользователю определять контент 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>
  • 0
    Не ясно......
  • 0
    Что такое #document ? Я не могу работать, является ли это фактическая наценка или вы имеете в виду ли это src документа , на который ссылается iframe ?
Теги:
security
iframe

3 ответа

3
Лучший ответ
<iframe>
    user-defined content here
</iframe>

Во-первых, это на самом деле не работает. Содержимое <iframe> отображается только как резервное копирование для старых браузеров, которые не поддерживают iframe, вы не можете включать туда контент тела. Чтобы вставлять контент в iframe с родительской страницы, вам нужно либо:

  • закодировать его в URL-адрес data: (не будет работать в IE)
  • поместите его в атрибут iframe srcdoc (недавняя версия HTML5, не поддерживается)
  • напишите содержимое документа iframe из JavaScript на родительской странице.

Если вы выполните одно из этих действий или если у вас есть пользовательский контент, обслуживаемый с другого URL-адреса под тем же именем хоста, то контент имеет тот же исходный код JavaScript, что и ваш сайт, и любой скрипт злоумышленника в iframe будет иметь доступ ко всем в сеанс пользователя на вашем сайте. Обтекание содержимого одного и того же происхождения в одном только iframe не дает вам какой-либо границы безопасности.

Обычно это будет представлять собой атаку межсайтового скриптинга (XSS) и не будет считаться приемлемым. Возможно, у вас может быть необычная пользовательская модель, в которой XSS не вызывает проблемы, но если у вас есть что-то вроде авторизации доступа на основе зарегистрированного пользователя или защищенных паролем учетных записей, тогда XSS нарушит эти меры.

Если вы хотите разрешить произвольный контент HTML без нарушения контроля доступа, вы должны либо:

  • удалите возможности сценариев, дезактивируя входные данные с помощью белого списка известных хороших тегов и атрибутов (это не так просто, поэтому посмотрите на проверенные и проверенные библиотеки, чтобы сделать это для вас, например htmlpurifier, если вы используете PHP);

  • в будущем iframe sandbox также может удалить скрипты из содержимого iframe, но недостаточно надежно поддерживается;

  • если вы должны разрешить сценарий, то, как предложил Квентин, обслуживать пользовательский контент из другого домена.

(Есть вещи, о которых стоит беспокоиться о том, когда вы включаете произвольный контент HTML в iframe, например, атаки на фишинг и обратный клик, но ничего плохого, как XSS.)

Поделиться
  • 0
    О, я пропустил раздел #document в iframe. Я исправлю это в данный момент. Похоже, iframe sandbox - это то, что мне нужно. Является ли удаление сценариев решением проблемы безопасности? @Quentin рассказал мне о CSRF-атаках, похоже, что для этого типа атаки не требуется JS.
  • 1
    Я не уверен, что вы пытаетесь достичь, добавив строку #document , это ничего не делает. iframe sandbox - это что-то для будущего, вы не можете использовать ее сегодня, потому что есть еще много браузеров, которые не поддерживают ее для пользователей тех браузеров, что ваш сайт будет уязвим. Удаление сценариев предотвращает атаки XSS, оно не помогает вам против всего, что у вас может быть. CSRF - это проблема, которую вам нужно решить для любого приложения, ее чуть проще использовать, чем обычно, если вы разрешаете отправленный пользователем HTML-код, который может содержать формы контента.
2

Есть три вещи, которые могут пойти не так:

  • Атака CSRF. Реализуйте обычную защиту против них.
  • Пользователь отправляет разбитые данные. Это обычно не проблема.
  • Пользователь обманывает передачу вредоносных данных через социальную инженерию (атака самосинхронизации XSS).

Изолируйте iframe таким образом, чтобы код не касался вашего основного сайта. Поместите код, который генерирует содержимое для iframe в другом домене для кода, который загружает фрейм.

Поделиться
  • 0
    Спасибо за информацию о CSRF. >> Поместите код, который генерирует содержимое для iframe, в другой домен, чем код, который загружает фрейм. Не уверен, что это поможет. Сгенерированные материалы для ввода в iframe при генерации страницы. Таким образом, весь код страницы будет из одного домена.
1

Обычно небезопасно, так как вы оставите свой сайт открытым для XSS.

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

Это позволит вам отключить скрипты на этой странице, поэтому, если пользователь вводит теги <script> или использует атрибуты, которые обычно запускают клиентский скрипт, они будут игнорироваться браузером.

Это реализовано через заголовок ответа HTTP. например

Content-Security-Policy: script-src 'self' https://apis.google.com

Этот заголовок позволяет запускать скрипты с https://apis.google.com и сценарии из локального домена для выполнения, но это предотвратит встроенные скрипты в HTML. Эти параметры настраиваются, чтобы делать все, что вам нужно.

Поделиться
  • 0
    Вау, спасибо! Это очень важная информация.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню