页面上用户定义的iframe

时间:2014-04-28 09:47:29

标签: html security iframe

是否可以安全地允许用户定义iframe内容,该内容将在页面上显示?

例如。有提交一些html标记文本的表单。此文本将显示在iframe的某个页面上。

UPD:另一个尝试解释: 有一个页面包含下一个内容:

<html>
<head>...</head>
<body>
  ...
  <iframe>
     #document
     user-defined content here
  </iframe>
  ...
</body>
</html>

“用户定义的内容”在哪里是用户定义的内容。用户可以编写一些html-markup,将在此页面显示。 如果用户定义的内容是这样的:

<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>

3 个答案:

答案 0 :(得分:3)

<iframe>
    user-defined content here
</iframe>

首先,这实际上并不起作用。对于不支持iframe的古代浏览器,<iframe>标记的内容仅显示为后备,您不能在其中包含正文内容。要将内容从父页面注入iframe,您必须:

  • 将其编码为data:网址(在IE中不起作用)
  • 将其置于iframe srcdoc属性(最近的HTML5版本,不受支持)
  • 在父页面中编写来自JavaScript的iframe文档内容。

如果您执行其中一项操作,或者您在同一主机名下使用其他网址提供用户内容,则内容与您的网站具有相同的JavaScript Origin,iframe中的任何攻击者脚本都可以访问和控制您网站上用户会话中的所有内容。仅在iframe中包含同源内容并不能为您提供任何安全边界。

通常这会构成跨站点脚本(XSS)攻击,不会被视为可接受。可以想象您可能有一个不寻常的用户模型,其中XSS不会导致问题,但如果您有基于登录用户或密码保护帐户的访问授权,那么XSS将破坏这些措施。

如果要在不破坏访问控制的情况下允许任意HTML内容,则必须:

  • 通过针对已知良好标签和属性的白名单清理输入来删除脚本功能(这不是直截了当的,因此请寻找经过验证的库来为您执行此操作,例如,如果您使用PHP,请使用htmlpurifier );

  • 将来,iframe sandbox也可以从iframe内容中删除脚本,但这还不够可靠;

  • 如果您必须允许脚本,那么就像Quentin建议的那样,提供来自其他域的用户内容。

(在iframe中包含任意HTML内容时仍然需要担心,例如网上诱骗和反向点击劫持攻击,但没有XSS那么糟糕。)

答案 1 :(得分:2)

基本上有三件事可能出错:

  • A CSRF attack。对他们实施the usual defences
  • 用户提交损坏的数据。这通常不是问题。
  • 用户被欺骗通过社交工程(自我XSS攻击)提交有害数据。

隔离iframe,因此其中的代码无法触及您的主网站。将生成iframe内容的代码放在不同的域上,加载到加载框架的代码中。

答案 2 :(得分:1)

通常不安全,因为您将网站打开XSS

但是,您可以为输出Iframe的页面实现Content Security Policy

这将有效地允许您在该页面上禁用脚本,因此如果用户输入任何<script>标签或使用通常导致客户端脚本运行的属性,浏览器将忽略它们。

这是通过HTTP响应头实现的。 e.g。

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

上面的标题将允许来自https://apis.google.com的脚本执行,并允许来自本地域的脚本执行,但它会阻止HTML中的内联脚本。这些选项可配置为执行您需要的任何操作。