如這裏所描述http://blogs.gartner.com/avivah-litan/2010/04/22/watch-out-transaction-signing-is-being-socially-engineered/防止iframe的安全問題
是 一次支付請求已經由網上銀行用戶發起， 銀行要求用戶籤的方式，被攻破的作品交易簽署是他/她的交易通過專用的 帶外EMV CAP閱讀器插入用戶的EMV芯片卡。要求 用戶在讀者 上輸入某些代碼和值，以確認要轉帳的貨幣金額以及要轉賬的賬戶爲 。
那麼騙子們知道什麼時候該交易簽署儀式正在發起 和簡單地把一個iframe了對用戶的瀏覽器的頂部，改變 值中輸入，使用戶最終在 欺詐者的銀行賬戶類型爲目的地帳戶，而不是他們打算的 。
談到交易簽名時需要思考的問題 - 表明需要將整個流程從PC上（在此 的情況下）和另一個渠道完全保留。
您能否解釋如何「將iframe放在用戶的瀏覽器之上」以及如何從技術上防止這種欺詐？
從引用中不清楚，但它聽起來像是在談論消費者端點的妥協。用戶已經拿起了一個銀行家木馬，所以他們的PC已經變成了一個不可信的設備，可以顯示誤導性的信息。在這種情況下，木馬操作員更改了顯示的目標帳號，以便資金流向與用戶認爲他們計入的資金不同的一方。
問題是，用於進行安全決策的完整用戶界面必須駐留在可信設備上。從個人電腦向安全設備輸入信息，使用戶有機會檢查信息是否正確，以及授權信息的屏幕顯示設備。
但是有一個缺失的部分，消費者通常不知道他們輸入的賬號真的是他們所稱的一方的賬號。除非他們在與該方進行了多次交易之後才能記住賬號並在錯誤時發現（即使這樣也不一定會擡高標誌）。
要糾正這種情況，帳戶ID必須是可識別的內容，例如發行受控的域名，而不是任意數字。這將導致任何需要輸入信息的獨立設備出現問題，因爲它需要全尺寸鍵盤。您可以使用僅支持顯示功能的設備來執行此操作，例如德國的TAN生成器，用於從屏幕讀取信息，或者您可以使用一個非常長的帳戶號碼進行解碼，並將其解碼爲可讀的內容，並進行簽名以防止未經授權的更改。
一旦整個決策需要在安全設備上的地方，其中包括轉讓金額和用戶可驗證目的地，不信任中介的問題（你的PC在中間的那個人）在解決和交易是安全的。
儘管該信息不包括交易的目的，所以您仍然可以想象經銷商更改了您在特定商店購買的實際商品而不改變成本的攻擊！
非常感謝你對我的看法:) – user310291
想了想我不明白的事情：銀行通常會根據金額和銀行卡號計算一次OTP，所以如果黑客更改這些銀行的號碼和金額，爲什麼銀行不能檢測有什麼不對？ – user310291
@ user310291：在將消息傳遞到銀行的服務器之前，消費者端點*處的帳號會發生變化，因此銀行將不知道用戶在其桌面上看到其他一系列導致該付款的步驟。這種欺騙行爲的依據是用戶沒有注意到他們看到的賬號與他們想要匯款的一方的賬號不一樣。這個數額，更容易引起注意的是，沒有改變。 – bobince
這是一個XSS（跨站點腳本）攻擊的示例。
例如說，Friendster，之前有很多XSS「漏洞」，特別是在配置文件頁面中。我可以在我的個人資料頁面中注入一個腳本，並使我的頁面看起來像一個登錄頁面。
一旦其他用戶查看我的個人資料，它看起來像一個Friendster登錄頁面！然後用戶輸入他的用戶名和密碼不知道這是一個欺詐頁面。輸入的值將被路由到我的服務器進行存儲，而用戶被重定向到實際頁面。
實際上，用戶從未註銷。 用戶被認爲是相信它是一個合法的網頁，並被披露帳戶的詳細信息。
爲了防止出現這種情況，您不應該允許任意的HTML以及腳本通過您的網站。攻擊有很多入口點，通常是沒有徹底驗證的輸入框。如果頁面上存在注入的腳本，則事件SSL的站點不安全。
這句話幾乎相當於說，因爲有些銀行允許任何人在支票上寫下數字，然後才能兌現，我們不應該有銀行。如果用戶的電腦受到威脅，當然騙子可以控制一切。如果銀行的網站設計得不好以至於存在XSS漏洞，那麼騙子當然可以控制一切。如果用戶被欺騙地認爲假銀行網站是真正的銀行網站（沒有雙因素驗證，沒有唯一的「你好，鮑勃，你的祕密詞是____」問候），那麼用戶和銀行當然會陷入困境。 – ninjagecko