Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

So I was making a virtual credit card from entropay.com and when I decided to Top up it up with my existing debit card. It opened up the 'Verified by Visa' page(A page in which you have to enter a password to authorize payment through your debit card. It is added as an additional security measure to check against card fraud if your card gets stolen) in an iframe. Normally when I have used the Debit Card, merchants open up the page in a new tab/window and there I enter the password and then it takes me to the payment confirmation page. Now when I enter a password in a different window/tab, other tabs can't access my keystrokes, so they can't know my password but I am not sure if this is true for an iframe. If I enter data in an iframe as the parent window is still on focus, will it be able to record my keystrokes/clipboard data?

I apologize if this wasn't the right place to ask this question. In that case, can you point me to a place where this would be more suitable.

share|improve this question
    
Nevermind. I opened up the iframe in a separate window by tracing the generating url in the page source. –  Kam Aug 7 '13 at 13:11
add comment

2 Answers

Well IFrames won't help much. This is because keyloggers typically work at the hardware, kernel, or API level. At the API level for instance, there are functions like GetAsyncKeyState which will tell you at any time whether a key is pressed or not. There are many techniques, this is just one example.

share|improve this answer
    
wht about malicious js at merchant site? i think that is the scary part as you are still on their site. –  tgkprog Sep 8 '13 at 12:03
add comment

If I enter data in an iframe as the parent window is still on focus, will it be able to record my keystrokes

Sort of. The parent window can't interfere with the key events in the iframe itself due to the Same Origin Policy, but there are various clickjacking attacks that allow it to subvert that interface. An obvious one is that it could overlay its own input box on top of the iframe interface at the same place where the real VbV password box would be.

On a more basic level, the parent window could completely spoof the contents of the frame—either coming up with its own phishing interface from scratch, or doing a man-in-the-middle with content from the Issuer's authentication server (ACS). Since there is no browser indicator to tell you what site an iframe comes from, you have no way to tell that you're really talking to your bank.

The consequence of this is that in the iframe-based 3-D Secure model, you absolutely must trust the merchant. Malicious merchants and those whose sites are compromised (eg by XSS) are not part of the threat model that 3-D Secure is attempting to protect against.

It's pretty uncommon to see 3-D Secure opened in a new page or pop-up window these days; the pop-up model was deprecated by Visa years ago and the redirect model is not favoured by merchants due to the way it takes the user out of the merchant's UI.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.