CODEWITHSUNDEEP
javascriptsecurity
user310291
user310291

Reputation: 38190

preventing iframe security issue

As described here 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.

Can you explain how it is possible to "put an iframe up on top of the user’s browser" and how to prevent that kind of fraud technically ?

Upvotes: 0

Views: 251

Answers (2)

bobince
bobince

Reputation: 536379

It's not clear from the quote, but it sounds like they are talking about consumer endpoint compromise. The user has picked up a banker trojan so their PC has become an untrusted device which can display misleading information. In this case the trojan operators changed the displayed destination account number so that funds would flow to a different party than the one the user thought they were crediting.

The point is that a complete user interface for making secure decisions must reside on the trusted device. Typing information from the PC to the secure device gives the user a chance to check the information is correct, as does a device with an on-screen display of information being authorised.

But there is a missing piece in that the consumer doesn't usually know that the account number they are typing is genuinely that of the party they mean to credit. Unless they've done many transactions with that party before such that they can remember the account number and spot it when it's wrong (and even then that wouldn't necessarily raise flags).

To correct this, the account ID would have to be something recognisable, something like a domain name whose issuance is controlled, rather than an arbitrary number. That would cause problems for any standalone device where you had to type the information, though, as it would then need a full-size keyboard. You could do it with a display-only device, something like Germany's TAN generators that read information off the screen, or you could do it with a very long account number that decoded to something readable, signed to prevent unauthorised changes.

Once the entire decision takes place on the secure device, including amount to transfer and the user-verifiable destination, the problem of the untrusted intermediary (your PC as a man in the middle) is solved and transaction is safe.

Although that information doesn't include the purpose of the transaction, so you could still imagine an attack where a reseller changed the actual items you were purchasing at a particular store, without changing the cost!

Upvotes: 2

Joseph
Joseph

Reputation: 119847

This is a sample of an XSS (Cross-site script) attack.

Say for example, Friendster, which had a lot of XSS "holes" before, particularly in the profile page. I can inject a script in my profile page, and make my page look like a login page.

Once another user looks at my profile, it looks like a Friendster login page! Then the user types his username and password not knowing that it was a fraud page. The entered values would be routed to the my server for storage, while the user gets redirected to the actual page.

In reality, the user was never logged out. The user was made to believe that it was a legit page and was made to reveal the account details.

To prevent this, you should not allow arbitrary HTML as well as scripts to get through your site. There are a lot of entry points for attack, usually input boxes that don't have thorough validation. Event SSL'ed sites are not safe if an injected script exists on the page.

Upvotes: 1

Related Questions