Как избежать предупреждений безопасности на https для пользовательской веб-почты с использованием iframe?

У меня есть базовый клиент веб-почты, который я пишу. Сервер построен на основе базового http-сервера node.js. Страницы обслуживаются через https с использованием действительного сертификата от Let's Encrypt. Тело сообщения загружается в изолированный iframe с помощью атрибута .srcdoc.

Я думал, что загрузка сообщения в изолированный iframe смягчит предупреждения безопасности о смешанном и междоменном содержимом. К сожалению, когда контент загружается в iframe, зеленый замок все равно исчезает и заменяется предупреждением безопасности.

Подробности: серверная часть использует модуль imap-simple node.js для извлечения содержимого почты с сервера imap и возвращает данные электронной почты в виде объекта json, который затем анализируется в массив объектов-конвертов, содержащих from/to/cc/bcc/ дата/тема/текст/html записи. Текстовые электронные письма не являются проблемой, но электронные письма в формате html должны отображаться как html (если, конечно, пользователь не выберет не-html).

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

Кроме того, он отлично работает с изолированными фреймами. Куки-файлы из содержимого сообщений на других сайтах, как и куки-файлы с моего сайта, хорошо разделены по своим собственным доменам. Кажется, что он хорошо отделяет сторонние данные от данных моих собственных сайтов, скрипты отключены и т. Д. От запуска в песочницах. Если включено для тестирования, сценарий, запускаемый из песочницы, действительно не имеет доступа к объектам за пределами песочницы.

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

Как мне обойти это, чтобы избежать предупреждений безопасности? Как это делают другие клиенты веб-почты? Настоящая проблема заключается в том, что мой сайт выглядит небезопасным для людей, которые не читают фактическое предупреждение или не понимают, что оно означает (т.е. большинство обычных пользователей).

У меня сложилось впечатление, что размещение сообщения в песочнице предотвратит появление предупреждения на содержащей его странице.

Некоторый псевдокод для иллюстрации базовой структуры страницы:

<html>
  <iframe id=mainpage>
    #docuement
      <iframe sandbox id=envelope0>
        #document
          <div>  ...email body with off-site content here  </div>
      </iframe>
  </iframe>
  <script>  //foo to get/generate html from the message(s)  </script>
</html>

person jdmayfield    schedule 29.05.2018    source источник
comment
Обновление: я смотрю на Roundcube, и у него та же проблема. У меня сложилось впечатление, что спецификация песочницы смягчит это. Это потому, что контент генерируется скриптом со страницы веб-почты, поступающей с моего сайта? Раньше я этого не замечал, но теперь это очень заметно. Я использую Chrome в основном. Это связано с одним из последних обновлений безопасности? Есть ли обходной путь? У Gmail, похоже, нет этой проблемы, и они просто загружают его в div из того, на что я смотрю. Интересно, что я не получаю таких предупреждений в Firefox ни для одного из них.   -  person jdmayfield    schedule 29.05.2018
comment
Gmail может проксировать содержимое за пределами сайта.   -  person Max    schedule 29.05.2018


Ответы (1)


Это фича, а не баг.

Междоменные фреймы не будут отображаться как безопасные.

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

Вы можете доставить его со своего сайта, а не с какого-либо другого сайта. Это исправит предупреждение SSL, но не сделает ничего «безопасным». Если контент был опасен, он останется опасным.

person Terry Carmen    schedule 29.05.2018
comment
Да, это правда. Я заметил, что веб-почта RoundCube делает то же самое. Ни в одном из них нет этой проблемы в Firefox, но в Chrome они есть. Однако в Gmail такой проблемы нет. Gmail не использует iframe, только div. Как они держат зеленый замок? Я думаю, что контент все еще находится за пределами Gmail. Я предполагаю, что веб-почта Outlook такая же, но сегодня нет времени проверить ее. - person jdmayfield; 29.05.2018
comment
Нет, я не говорю, что это ошибка. Я понимаю соглашение о перекрестном происхождении, но как другие сайты избегают предупреждения? Может быть, есть что-то еще, что мне не хватает. - person jdmayfield; 29.05.2018
comment
Я не уверен, что вы имеете в виду о gmail. Весь контент, который обслуживает gmail, исходит из их домена (ов), поэтому он действителен и получает висячий замок. - person Terry Carmen; 29.05.2018
comment
Ах. Перекопав около сотни вложенных div, я вижу, что изображения по крайней мере в почте на gmail действительно проксируются. Потрясающий. Вот мой ответ, Терри. Благодарю вас! Надеялся на способ с песочницей, но проксирование изображений не займет много времени. Очевидно, придется предупредить пользователя и сделать возможность показывать или скрывать изображения и т. д. В любом случае нужно собрать приличное дезинфицирующее средство, так что, возможно, я просто убью двух зайцев одним выстрелом. - person jdmayfield; 30.05.2018
comment
Рад, что ты нашел это! Что касается изображений, возможно, вы захотите узнать о фактическом изучении изображений на наличие уязвимостей. Я не помню подробностей, но на самом деле можно заразить или скомпрометировать некоторые версии непропатченной Windows с помощью специально разработанных образов. Это была (есть ли?) какая-то уязвимость GDI. - person Terry Carmen; 30.05.2018
comment
Да. Насколько я понимаю, в изображениях .jpg можно было скрыть код (я не слышал о других типах файлов с этой уязвимостью), который каким-то образом выполнялся бы в более старых версиях IE. Это затронуло системы на базе Windows 98, возможно, более ранние версии XP. К сожалению, все еще есть люди, цепляющиеся за старые коробки XP. Хотя мне было бы интересно узнать, как работает механика. SVG, возможно, вызывают некоторую озабоченность, поскольку они могут содержать и запускать сценарии, но по умолчанию они помещаются в песочницу, если импортируются как обычное изображение (а не как встроенный код), если явно не разрешено иное. - person jdmayfield; 30.05.2018
comment
По крайней мере, так должно быть... на самом деле никто ничего не знает, пока кто-нибудь не найдет эксплойт и либо не сообщит о нем, либо не создаст проблемы с ним. С какой стати им делать исполняемый файл jpg? Вероятно, это связано с переполнением буфера. Буферы невероятно важны, но кто-то всегда найдет способ получить доступ к частям памяти через них, даже недавно. Например, Node.js пришлось отказаться от старых буферов и придумать новые методы доступа к ним по тем же причинам. Это классическая атака, но она все еще находит новые способы самовыражения. - person jdmayfield; 30.05.2018