New Paypal gateway UI susceptible to spoofing
homakov.blogspot.com
homakov.blogspot.com
There is always a level of trust involved with entering these kinds of credentials on-line. This is why some of the 3-D Secure systems make you (the customer) give them a greeting of your own choice to incorporate in the prompt for your confirmation code.
However, it seems that for many vendors the losses due to a higher rate of aborted checkouts make such systems undesirable. Apparently most customers don't share the author's concern here, presumably either unaware of the potential security issues or just trusting that if anything does go wrong then some protection or guarantee from their payment service/card issuer will get it fixed.
I suspect the author here would argue that it would be better for on-line payments to be push transactions rather than pull, so users always actively send money via a trusted party such as their bank without ever handing over their bank-issued credentials to anyone else. No doubt many of us would agree with that; pull-based payment models are fundamentally insecure and absurdly vulnerable to fraud. But again, that goes for a lot more than just PayPal.
The major advantage for merchants of using these schemes is that liability for various types of card fraud is shifted elsewhere, instead of the merchant getting dumped with the cost of fraudulent transactions even if they did nothing wrong except trust the payment services to do their job.
Much of this is likely to change again early next year, because there are SEPA-wide rules coming in that require strong authentication for Internet payments. Even the giant payment services can't ignore them, because liability for fraud on their networks is (finally) going to land on them whether they like it or not after the new rules take effect.
Sure, you could overlay an element on top of the bar with JS/CSS, and some thought would have to be put in to avoid that type of forgery.
> The iframe itself should have its own non-editable URL address bar
This would definitely be good for security, but I feel like it would probably be overkill for many other iframe use cases. Think about every YouTube embed having an address bar. And what about the "hidden" iframes that are only 1x1, do you still show an address bar? Do you set a minimum size for iframes?
As far as the 1x1 and minimum frame size, I don't know. 1x1 iframes are usually hidden (is there any point to having them visible?). I don't think it's a specification's place to enforce minimum size limits for elements (frames or otherwise). Perhaps the user agent could display a button that the user could interact with if the iframe size were smaller than a certain size.
The certificate verification UI in browsers only works because it's outside of the area that a website could display a fake one in. You'd need some kind of indicator tied to the iframe from outside the web view, otherwise they'll end up like the ads that looks like popup windows to trick you into clicking the close button.
Even if you require the iframe to have some specific styling and make it so the parent DOM cannot edit it, we're talking about spoofing.
With html, js, and css you can reproduce absolutely any iframe styling by simply not using an iframe and pretending you are.
If you were to put the iframe's true url in the location bar e.g. having url: https://github.com/fragement | selected: https://paypal.com/fragment then that could sovle the problem however.
Browsers cannot edit domains in the location bar so this could work, but your suggestion absolutely doesn't.
Furthermore, I don't think the idea I outline above is a good idea because it requires users to learn something more. I'd rather just have the "redirect to and redirect back when done" solution since people have already learned to check "am I on paypal, does my address bar say paypal, is my ssl cert thingy green" and relearning to check "is my selected url paypal even though I'm on github" is not something that would happen quick enough in my mind.
This sounds even scarier - the user should be in control and able to inspect the page without the page knowing, since as he mentions, the attacker could otherwise deploy countermeasures to evade.
There isn't a way to solve this issue without hurting the user experience. For some websites, that's a fair trade off.
Maybe a browser could put in a "Verify iframes" button that would show you the payment form is actually coming from PayPal.
[1]: https://www.paypal.com/us/webapps/mpp/paypal-safety-and-secu... @ Who you are is how you pay
Google Wallet for Digital Goods (which Google is retiring soon) does this, and I think it is the best payment user experience that has been made, so far.
clickjacking
Hands-up - I'm guilty of doing this. I hadn't really considered the issue before, but I agree it is a security concern.
One of the reasons developers switch to using an iframe rather than a separate window is due to popup blocking. Retrieving the url for a payment system usually requires making a server side call, so it's impossible to then launch a popup directly from the user action. The solution would be to require a second user action after having retrieved the url.
A complete redirect isn't always the best case for single page web apps, either. Thankfully, we're a bit smarter about deep-linking these days, so that should no longer be an issue.
Shameless plug - i have an article on paypal's oauth which is similar to oauth1 but hasn't fixed it's token fixation bug yet: http://homakov.blogspot.com/2014/01/token-fixation-in-paypal...
Yes, I know about classic integration options. But it's not about what was possible (any kind of phishing is always possible) it's about what Paypal suggests by default and what websites actually use.
> Retrieving the url for a payment system usually requires making a server side call
window.open('site.com/get-url-for-paypal-then-redirect')?
Has anyone seen anything in a spec or recommendation that addresses a browser-UI solution to verifying the authenticity of iframes or other embedded objects?
Their is only solution today to verify if the iframe is legitimate or not and that is to include a link in the iframe that the user can click on (With the text: Is this a legitimate login form?). This links opens up a new browser tab and in that tab PayPal checks the referrer. If the referrer comes from PayPal (the iframe) we know that this iframe is not a fake one and can present that information to the user.
It can be a smart proxy: while you type they type for you in another browser, and log it.
>which then automatically logs into paypal without reentering password..
Doesn't work with Paypal gateway, you always have to login.
Similarly, Google's "No CAPTCHA" (https://news.ycombinator.com/item?id=8693767) lets Google offer a better experience than a traditional CAPTHCA. I'm somewhat surprised that better fraud detection leads to better UX, but it's pretty neat.
(Yes, that's pretty nasty - but is putting a poorly-secured "startup" online really any better?)