由于安全起见，iframe 嵌入式的第三方登陆框为了保证不是非授权第三方引用，可能需要在 form 表单的 target 里面设置为 _top 让整个页面刷新。逻辑似乎没有问题，但是在特殊环境下的 IE6 当中，就出现了一些麻烦的问题。
一、现有问题和现行办法
我们知道 javascript 对于跨域的数据安全策略是很严格的，因此我们无法通过被引用的 frame 中的 javascript 来检测引用页面的地址。
于是采取了 form 表单提交 target 设置为 _top 让整个页面刷新，保证登录成功后，显示的页面为授权页面，减少用户遇到钓鱼网站的危险。
二、偶遇 IE6 变态设置( Navigate sub-frames across different domains )
现行的方案目前在 IE7/8 以及 firefox, chrome 等浏览器当中运作良好。
但是在 IE6 中，如果安全策略当中的 跨域浏览子框架（Navigate sub-frames across different domains）被设置为 禁用(disable)，之后，提交 target 为 _top 的 form 表单时，浏览器会阻止这一行为，导致无法登陆。
三、关于“跨域浏览子框架( Navigate sub-frames across different domains )”
跨域浏览子框架为 IE6 下专门的一项设置，查看 IE6 的技术文档之后，可以了解到，在 IE6 中，除了安全级别为高时该设置为 禁用(Disable)，其他情况默认是 启用(Enable)。
我们把视线转移到 IE7/8，在这 IE8 中，这一项设置更名为 跨域浏览窗口和框架( Navigate windows and frames across different domains )，并且 IE7和 IE8 默认设置是 禁止 ( Disable )。
虽说是禁止，但是却并不影响“一”中提到的方法。但是如果碰巧 IE7 降级成 IE6 或者某些安全软件修改的话，这个“禁止”就会影响到我们正常的操作了。
解决方法：internet 选项 –> 安全 –> 自定义级别 –> 跨域浏览子框架 –> 启用
四、frame 嵌入第三方的登录框登录流程设计
核心思路：
- 技术上解决或避免跨域问题
- 引用页授权检测，防止非授权第三方引用或钓鱼
基本流程设计如下
- A,B 分别为两个不同域名，B 通过 iframe 引用 A 域名下的 A1 作为登录框；
- A1 中填写完成之后，由 A1 将用户信息发送至 A2，由 A2 进行认证；
- A2 认证通过后，通过 302 重定向方式将 frame 内的页面跳转至 B2 （没有触碰跨域问题）；
- 可以见，经过这样操作，frame 内外同域，同域的操作这里便不多说。
五、安全性分析
安全一：A 域内的数据是否会被 B 获取？
因为 frame 的跨域机制的保护，给我们带来的安全，虽然也有麻烦，但这保证了用户信息不会被第三方获取。
安全二：非第三方是否可引用 A 域登录框实现钓鱼？
1) A2 重定向至 B2 的过程由 A 控制，非授权第三方 C 将会在 A2 阶段由 A2 强制将页面刷新 A 域下的地址。
2) 如果第三方 C 伪造参数，欺骗 A2 跳转至 B2，此时，因为 B2 域与 C 域不同，B2 同样可以强制将页面刷新至 B 域下的某地址。
六、应用实例
可以参考“人人连接”的相关代码和流程。
七、总结
在网站开发的过程中，除了浏览器兼容问题以外，居然还得考虑浏览器设置问题。
通常情况我们都是基于浏览器默认设置，或许某些因素导致的浏览器参数变更都会影响到“网页应用程序”的运行。
还有呢，就是作为服务的提供方，除了保证我们自身系统的安全以外，还要一定程度上给用户提供安全保护，这些都是要注意的问题。
这样的一些问题都得靠自己去积累和总结。
站内搜索
5 Comments