如何在安全门户应用中使用 iframe 加载内部应用？

可以用 iframe 作为 Web Forms 逐步迁移到 ASP.NET Core MVC 的过渡方案。旧应用可以保留自己的页面、脚本和 postback 流程，也能避免不同版本的 jQuery 在同一个页面中发生冲突。

iframe 本身不能证明系统安全或符合 PCI DSS。安全评估需要覆盖门户、每个子应用、身份认证，以及应用之间的信任关系。HTTPS 保护传输过程，点击劫持、越权访问、XSS 和 CSRF 则需要分别防护。

先确定门户与子应用的隔离方式

iframe 有独立的文档环境，脚本的访问范围由同源策略决定。

“同源”要求协议、主机名和端口都相同。例如：

如果新旧应用的安全维护水平不同，应优先考虑跨源部署，让各应用使用自己的 Cookie。跨源 iframe 中的脚本访问受同源策略限制，应用之间需要通信时，可以使用 postMessage()。普通 iframe 页面加载不需要开放 CORS。参考：MDN iframe 文档

通过反向代理把所有应用放到同一个域名的不同路径下，会使它们成为同源页面。按路径划分应用，无法提供浏览器层面的安全隔离。

门户登录后，子应用仍必须验证权限

隐藏门户菜单中的应用入口，无法阻止用户直接访问子应用 URL。每个子应用都应在服务器端验证：

• 请求是否来自有效的登录会话。
• 当前用户是否有权使用该应用。
• 当前用户是否有权读取或修改这条具体数据。

URL 参数中的用户名、角色或 isLoggedIn=true 都不能作为身份凭据，也不能靠 Referer 判断用户是否经过门户。

ASP.NET Core Identity 可以管理门户用户和登录会话，但接入 Identity 后，旧 Web Forms 应用仍需要单独实现单点登录。具体方案取决于现有系统：

• 使用统一身份提供方，通过 OpenID Connect 等协议让各应用建立自己的会话。
• 如果旧应用使用兼容的 OWIN Cookie 认证，按 Microsoft 的方案配置共享认证 Cookie。
• 对暂时无法改造的旧应用，评估迁移适配层提供的远程认证能力。

旧式 Forms Authentication Cookie 不能直接作为 ASP.NET Core 认证 Cookie 使用。共享 Cookie 需要匹配认证配置和数据保护设置，也会扩大应用之间的信任范围，仅设置相同的 Cookie 名称还不够。参考：Microsoft 跨应用共享认证 Cookie

登录跳转应优先在顶层页面完成。许多身份提供方禁止将登录页面嵌入 iframe，因此在 iframe 内直接发起交互式登录可能失败。

用响应头防止未经授权的嵌入

点击劫持通常是在攻击者页面中放置透明或伪装的框架，诱导用户点击真实应用里的敏感操作。子应用可以允许可信门户嵌入，同时阻止其他站点嵌入。

两个 CSP 指令分别控制加载和被嵌入的范围：

门户自身通常还应设置 frame-ancestors 'none'，防止攻击者嵌入整个门户。frame-ancestors 会检查所有祖先框架，必须通过 HTTP 响应头发送，放在 <meta> 中无效，也不会继承 default-src 的限制。参考：MDN frame-ancestors

假设门户和旧应用分别部署在：

https://portal.example.com
https://legacy.example.com

门户可以返回：

Content-Security-Policy: frame-ancestors 'none'; frame-src https://legacy.example.com; object-src 'none'; base-uri 'self'
X-Frame-Options: DENY

旧应用则返回：

Content-Security-Policy: frame-ancestors https://portal.example.com

允许门户嵌入的跨源子应用，不应同时保留 X-Frame-Options: DENY 或 SAMEORIGIN，以免造成兼容性问题。SAMEORIGIN 无法表达“允许另一个指定子域名”，已废弃的 ALLOW-FROM 也不适合作为解决方案。如果必须支持不理解 frame-ancestors 的旧浏览器，需要另行评估部署方式，或让用户通过独立页面访问。参考：OWASP 点击劫持防护指南

ASP.NET Core 门户配置示例

项目已配置好 Identity 和认证流程时，可以将以下中间件放在端点映射之前：

app.Use(async (context, next) =>
{
    context.Response.Headers["Content-Security-Policy"] =
        "frame-ancestors 'none'; " +
        "frame-src https://legacy.example.com; " +
        "object-src 'none'; " +
        "base-uri 'self'";

    context.Response.Headers["X-Frame-Options"] = "DENY";

    await next();
});

这些指令只覆盖部分安全策略，无法提供完整的 XSS 防护。如果项目已有 CSP，应合并策略，避免覆盖原有的 script-src 等限制。

Web Forms 子应用需要通过自己的 IIS 或应用代码发送响应头。还应检查 IIS、代理和应用中间件是否重复添加 CSP 或 X-Frame-Options，以浏览器最终收到的响应为准。

按旧应用实际需要设置 sandbox

跨源部署时，可以从以下配置开始验证：

<iframe
    id="application-frame"
    class="application-frame"
    src="https://legacy.example.com/"
    title="内部业务应用"
    sandbox="allow-scripts allow-forms allow-same-origin"
    referrerpolicy="strict-origin-when-cross-origin">
</iframe>

.application-frame {
    display: block;
    width: 100%;
    height: 80vh;
    border: 0;
}

示例中的高度需要按实际布局调整。即使 iframe 的宽度能自适应，内部固定宽度的 Web Forms 页面也不会自动适配移动端。

sandbox 中各项许可的含义如下：

• allow-scripts：允许运行脚本，许多 Web Forms 控件依赖它。
• allow-forms：允许表单提交，postback 通常需要它。
• allow-same-origin：保留子页面原本的源，使其不被当作不透明源处理。它不会把两个不同域名变成同源。

文件下载、打印、弹窗和离开页面确认等功能，可能需要其他许可。应确认业务需要后再逐项增加，避免一开始就开放所有能力。

如果父子页面同源，又同时允许 allow-scripts 和 allow-same-origin，子页面可能移除 iframe 的 sandbox 限制。因此，不能依靠这种组合隔离同源旧应用与门户。参考：MDN sandbox 说明

iframe 的 src 应从受控的应用列表中选取，不能直接使用用户输入的地址。

区分跨源与跨站，避免登录循环

不同子域名可以跨源，同时仍属于同站。是否设置 SameSite=None，应根据 Cookie 是否需要在跨站 iframe 中发送来判断，不能因为使用 iframe 就统一修改所有认证 Cookie。

确实需要在跨站 iframe 中发送的 Cookie，通常需要以下设置：

Set-Cookie: AppSession=...; Path=/; Secure; HttpOnly; SameSite=None

SameSite=None 需要配合 Secure 使用。不过，即使这样设置，浏览器或企业策略仍可能阻止第三方 Cookie，导致 iframe 内反复跳转登录。参考：Microsoft SameSite 文档、MDN 第三方 Cookie

实际部署时应：

• 尽量采用同站部署，减少对第三方 Cookie 的依赖。
• 为非共享会话使用不同的 Cookie 名称，避免设置过宽的 Domain。
• 分别检查认证 Cookie、会话 Cookie 和防伪 Cookie，避免全局放宽 SameSite。
• 明确门户退出登录后，各子应用的会话如何失效；移除 iframe 不会清除子应用会话。

同站子域之间仍可能发出携带 Cookie 的请求，因此跨源隔离不能替代 CSRF 防护。

子应用原有的漏洞仍然需要修复

门户和所有子应用都应使用 HTTPS，页面中的脚本、接口和其他资源也应如此。内部托管会改变应用的可访问范围，但应用漏洞仍然存在。

迁移期间至少应做好以下工作：

• 为所有修改状态的操作实施 CSRF 防护。ASP.NET Core MVC 可以使用防伪令牌；Web Forms 则需要核查现有实现，不能仅凭存在 ViewState 就认定已有防护。
• 修复 XSS、SQL 注入、越权和不安全文件上传问题，继续更新旧应用依赖。iframe 能缓解 jQuery 版本冲突，无法修补旧版 jQuery 的漏洞。
• 使用安全的 Cookie 设置和合理的会话期限，根据风险要求为敏感操作增加重新认证。
• 记录登录、权限拒绝和敏感操作，避免将凭据、令牌及敏感业务数据写入 URL 或日志。

在基于 Cookie 认证的应用中，浏览器会自动附带 Cookie，这是需要防范 CSRF 的原因之一。参考：Microsoft ASP.NET Core 防伪请求指南

如果门户通过 postMessage() 接收子应用的高度、导航等消息，应同时校验 event.origin、event.source 和消息结构；发送消息时，应指定准确的 targetOrigin。不能根据任意消息执行脚本或跳转到任意 URL。

PCI DSS 应如何判断

判断 PCI DSS 是否适用，首先要确认门户和子应用是否处理持卡人数据，或能否影响持卡人数据环境的安全。使用 iframe 本身不能作为合规证据。如果涉及支付，评估应覆盖数据流、页面控制权、脚本来源、网络边界，以及当前适用的评估要求。

PCI SSC 对使用第三方嵌入式支付表单的 SAQ A 场景有专门说明，其中仍包含防范影响支付页面的脚本攻击的要求。这些条件针对特定的支付外包场景，不能直接套用到自行托管的内部应用。参考：PCI SSC FAQ 1588

如果项目确实进入 PCI DSS 范围，应将架构图、数据流图和认证流程交给合规负责人或 QSA 确认。HTTPS、Identity 和 iframe 都只是实现的一部分，无法单独得出合规结论。

有哪些替代方案

直接将完整的 .aspx 页面放进 div，通常需要处理表单、脚本全局变量、资源路径和 postback 等问题。div 没有独立的文档环境，无法提供 iframe 那样的脚本隔离，jQuery 版本冲突也只是其中一个障碍。

如果迁移按月推进，可以先选一个有代表性的旧应用接入 iframe，验证认证和权限边界，再逐个接入其他应用。Web Forms 仍需运行在支持它的 .NET Framework 环境中，迁移到 ASP.NET Core 时需要重写相应页面，仅更换宿主无法完成迁移。参考：Microsoft ASP.NET 迁移说明

上线前验证哪些行为

首页能正常显示之后，还应检查：

• 未登录直接访问子应用，或使用无权限账号访问具体记录时，服务器是否正确拒绝请求。
• 门户能否嵌入子应用，其他站点是否无法嵌入门户和子应用。
• 会话过期、重新登录、退出登录及多标签页操作是否符合预期。
• postback、文件上传下载、打印、弹窗、浏览器返回和深层链接是否正常。
• 手机上的滚动、键盘遮挡和焦点切换是否影响使用。
• 禁用第三方 Cookie 后的行为，以及浏览器最终收到的 CSP、X-Frame-Options 和 Cookie 属性是否正确。

跨源 iframe 如果需要根据内容自动调整高度，应由子应用主动上报尺寸，门户验证消息后再调整高度。旧页面本身的移动端布局仍需单独改造。

备注：内容仅供参考。