防止iframe安全问题

时间:2012-05-06 23:23:37

标签: javascript security

如此处所述http://blogs.gartner.com/avivah-litan/2010/04/22/watch-out-transaction-signing-is-being-socially-engineered/

  

受到妥协的交易签名的方式是这样的   一旦网上银行用户发起付款请求,   银行要求用户在专用上签署他/她的交易   带有用户EMV芯片卡的带外EMV CAP读卡器。该   要求用户在阅读器上输入某些代码和值   确认要转移的货币金额和帐户   转移到。

     

骗子知道交易签署何时开始   并简单地将iframe放在更改的用户浏览器之上   要输入的值,以便用户最终输入   欺诈者的银行帐户作为目的地帐户而不是   一个他们想要的。

     

在交易签名方面需要考虑的事情 -   证明需要将整个过程保持在PC之外(在此   案例)和完全在另一个渠道。

您能解释一下如何“在用户的浏览器上放置iframe”以及如何在技术上防止这种欺诈行为?

2 个答案:

答案 0 :(得分:2)

引用并不清楚,但听起来他们正在谈论消费者端点妥协。用户已经选择了一个银行家木马,因此他们的PC已成为一个不受信任的设备,可以显示误导性信息。在这种情况下,木马运营商更改了显示的目的地帐号,以便资金流向与用户认为他们信用的一方不同的一方。

重点是用于做出安全决策的完整用户界面必须驻留在可信设备上。从PC到安全设备的信息输入使用户有机会检查信息是否正确,以及屏幕上显示信息被授权的设备。

但是有一个缺失的部分是,消费者通常不知道他们输入的帐号真正是他们想要信用的一方的帐号。除非他们之前与该方进行过多次交易,否则他们可以记住帐号并在错误时发现它(即使那样也不一定会引发标记)。

要纠正此问题,帐户ID必须是可识别的东西,例如控制其发布的域名,而不是任意数字。这会给你必须输入信息的任何独立设备带来问题,因为它需要一个全尺寸的键盘。您可以使用仅显示设备,例如德国的TAN生成器,从屏幕上读取信息,或者您可以使用非常长的帐号进行解码,解码为可读的内容,签名以防止未经授权的更改。

一旦整个决策发生在安全设备上,包括转移金额和用户可验证的目的地,就会解决不受信任的中间人(你的PC作为中间人)的问题并且交易是安全的。

虽然该信息不包含交易的目的,但您仍然可以想象一个经销商更改了您在特定商店购买的实际商品的攻击,而不会改变成本!

答案 1 :(得分:1)

这是XSS(跨站点脚本)攻击的示例。

比如说,之前有很多XSS“漏洞”的Friendster,尤其是在个人资料页面中。我可以在我的个人资料页面中注入一个脚本,并使我的页面看起来像一个登录页面。

一旦其他用户查看我的个人资料,它就像是一个Friendster登录页面!然后用户输入他的用户名和密码不知道它是欺诈页面。输入的值将路由到我的服务器进行存储,同时用户将被重定向到实际页面。

实际上,用户从未注销过。 让用户相信这是一个合法的页面,并且是为了揭示帐户详细信息。


为防止这种情况发生,您不应允许任意HTML和脚本通过您的网站。攻击有很多入口点,通常是没有彻底验证的输入框。如果页面上存在注入的脚本,则事件SSL的站点不安全。