javascript - 防止 iframe 安全问题

Question

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

The way the transaction signing that was compromised works is that once a payment request has been initiated by an online banking user, the bank asks the user to sign his/her transaction on a dedicated out-of-band EMV CAP reader with the user’s EMV Chip card inserted. The user is asked to enter certain codes and values on the reader confirming the currency amount to be transferred and the account it is to be transferred to.

Well the crooks knew when the transaction signing was being initiated and simply put an iframe up on top of the user’s browser that changed the values to be entered so that the users ended up typing in the fraudster’s bank account as the destination account rather than the one they intended.

Something to think about when it comes to transaction signatures – demonstrating the need to keep the entire process off the PC (in this case) and on another channel entirely.

您能否解释一下如何“将 iframe 置于用户浏览器之上”以及如何从技术上防止此类欺诈？

Answer 1

从引文中尚不清楚，但听起来他们正在谈论消费者端点妥协。用户感染了银行特洛伊木马，因此他们的 PC 已成为不受信任的设备，可以显示误导性信息。在这种情况下，特洛伊木马操作者更改了显示的目标帐号，以便资金流向与用户认为的贷方不同的一方。

要点是，用于做出安全决策的完整用户界面必须驻留在受信任的设备上。从 PC 向安全设备输入信息使用户有机会检查信息是否正确，屏幕上显示已授权信息的设备也是如此。

但有一个缺失的部分是，消费者通常不知道他们输入的帐号确实是他们想要贷记的一方的帐号。除非他们之前与该方进行过多次交易，这样他们就可以记住帐号并在错误时发现它(即使这样也不一定会引起注意)。

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

一旦整个决策在安全设备上做出，包括转账金额和用户可验证目的地，不可信中介(您的电脑作为中间人)的问题就解决了并且交易是安全的。

尽管该信息不包括交易的目的，因此您仍然可以想象经销商更改您在特定商店购买的实际商品而不改变成本的攻击!