框架钓鱼漏洞

框架钓鱼（Frame Phishing）不是框架新东西，但最近两年它换了一张皮，钓鱼骗术精度高到连老手都可能翻车。漏洞我亲眼见过一个案例：某公司财务总监收到一封“税务稽查通知”，框架点开链接后浏览器里弹出一个和国税局官网一模一样的钓鱼页面，地址栏甚至显示着https开头的漏洞正规域名。他输入了企业税号和密码，框架三分钟后公司账户被转走47万。钓鱼

这事的漏洞核心漏洞不在技术，而在人的框架认知惯性。我们总以为“https+锁图标”就等于安全，钓鱼但框架钓鱼恰恰利用了这个信任锚点。漏洞攻击者用iframe标签把真正的框架银行页面嵌在自己的恶意网页里，用户看到的钓鱼地址栏确实是银行官网，可键盘输入的漏洞信息却被底层脚本截获。更阴的是，有些变种会先加载真实页面，等用户输入密码的瞬间用JavaScript把整个框架替换成伪造界面——你甚至来不及察觉页面闪了一下。

有个细节很多人忽略：框架钓鱼的检测难度比普通钓鱼高一个量级。普通钓鱼网站的HTML源码里能找到可疑域名，但框架钓鱼的源码里只有一串iframe地址，指向的却是合法网站。安全软件扫描时看到的是正规页面，自然放行。攻击者唯一要做的，是在自己服务器上搭一个透明代理，把目标网站的流量转发给用户，同时篡改表单提交逻辑。这种中间人手法，连双因素认证都能绕——用户收到的验证码被实时转发到攻击者后台，他们同步输入，整个过程不超过两秒。

我测试过几个主流浏览器的防护机制，Chrome的Safe Browsing能拦截大部分已知钓鱼域名，但对框架钓鱼几乎无效。因为它检测的是URL黑名单，而攻击者用的是全新域名，甚至直接购买过期域名。Firefox的ETP（增强跟踪保护）稍微好点，能识别部分跨域iframe，但误报率也高——很多正规网站用第三方支付组件时也会触发警告，用户看多了就麻木了。

真正有效的防御其实很笨：手动检查页面内嵌元素。按F12打开开发者工具，看Elements面板里有没有iframe标签指向其他域名。如果页面地址是bank.com，但iframe里嵌着bank.com.evil.net，那基本可以断定是框架钓鱼。这招对非技术用户不友好，但至少能救回一部分人。另一个实用技巧是故意输错密码——如果页面提示“密码错误”，说明服务器确实验证了你的输入；如果直接跳转或空白，八成是伪造页面。

企业级防护倒是有了新思路。一些EDR产品开始监控浏览器进程的内存访问模式，因为框架钓鱼必须调用底层API来读取用户输入，这种操作在正常页面浏览中很少出现。但部署成本高，中小企业基本用不起。更现实的做法是给财务、人事等高风险岗位装独立浏览器，跟日常上网环境隔离，哪怕中招了也拿不到其他系统的Cookie。

说到底，框架钓鱼利用的是我们和浏览器之间的信任契约。浏览器承诺显示真实地址，攻击者却用合法页面当掩护。只要有人还相信“看到锁图标就安全”，这类攻击就不会消失。下次登录网银前，不妨先随便敲几个字符——如果页面没报错，那就要多留个心眼了。

很赞哦!（183）