
New Paypal gateway UI susceptible to spoofing - dsr12
http://homakov.blogspot.com/2014/12/new-paypal-gateway-ui-is-disaster.html
======
Silhouette
Doesn't this weakness potentially exist with any integrated payment page on
any site using any payment platform, though?

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.

~~~
MichaelGG
If 3D is anything like the silly Verified by Visa, it's atrocious. Some
strange domain that sounds like a generic phishing attempt. Random password
with supposedly a secure phrase to indicate they know me... But anyone with my
card details can look that up and show it for me. I see no value in such
systems, and they must murder conversion rates.

~~~
Silhouette
3-D Secure is the umbrella term for schemes like Verified by Visa, and yes,
there has been a lot of criticism of both the added security (or not) and the
disruption to the payment process and consequent hit on conversion rates.

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.

------
spartas
In cases like this, asking users for information, especially for payment
details, for a different site than the user is visiting (e.g. PayPal) should
be done using separate windows or iframes. Period. Additionally, the
specification for visible iframes should make it clear to the user the
iframe’s document URL. The iframe itself should have its own non-editable URL
address bar, including an interactable area to allow the user to request
information about the security details of the framed page for pages requested
over SSL/TLS.

~~~
idbehold
The method PayPal is using right now, the one mentioned in the article,
utilizes iframes.

> 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?

~~~
spartas
Obviously there would need some additional thought put into this. It might be
a net-positive for every YouTube embedded video to have an address bar (copy
from the iframe url and paste the embed URL into the browser's address bar,
YouTube could detect that it's not being loaded into a frame and take the user
to the standard video page).

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.

------
userbinator
_But as long as the attacker can detect when the user opens devtools all your
efforts are futile._

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.

~~~
DiThi
Looking at the code it looks pretty easy to circumvent: don't use firebug,
have the devtools open when loading the page or have them open undocked by
default. The detection method for non-firebug devtools is pretty silly: it
checks the window size.

~~~
scott_karana
Even so, I'd appreciate it if the browser vendors took additional steps to
disable the detection of devtools, personally. I don't think they should be
detectable under _any_ circumstances, if that's possible to implement.

------
RandallBrown
If you're going to trust a website with your credit card you probably trust
them enough to not try and steal your paypal information.

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.

~~~
jfoster
There is a way to do this securely whilst improving the user experience. The
merchant site can run PayPal's js, which would check whether the user is
signed in to PayPal. If they are signed in, the js could just display a
"confirm payment" button rather than requesting credentials from the user. If
they're not signed in, it could just ask the user to sign in to PayPal in a
new window, where the user can verify via the browser's address bar whether
they are signing into the real PayPal.

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.

~~~
homakov
> the js could just display a "confirm payment" button rather than requesting
> credentials from the user.

clickjacking

------
rtpg
Huh, this seems very obvious in hindsight. I guess with Stripe things are a
bit easier since you have none of this username/password stuff to be dealing
with (you could get your cc number swiped, but if you're an American you're
dealing with that issue everyday anyways).

~~~
homakov
Exactly, giving your CC details to some website is a routine, but your
email+password are critical credentials.

~~~
djloche
Specifically because PayPal has incentives for people to link their bank
accounts. If you have someone's login for PayPal, you may have access to their
checking bank account.

------
talldan
This isn't a new thing, it's been possible for a number of years to integrate
paypal using an iframe.

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.

~~~
homakov
>This isn't a new thing, it's been possible for a number of years to integrate
paypal using an iframe.

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')?

~~~
talldan
that's a good option - hadn't considered that approach.

~~~
homakov
Yeah, and it's very widely used in oauth. (Talking in separate threads is
weird)

------
astrocat
This seems like something that's going to become more and more of a problem as
services attempt to create ever more seamless integrations to create better
user experiences.

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?

------
dscrd
Did Paypal just remove the issue reporting page or is the link in the article
just wrong? [https://www.paypal.com/webapps/mpp/security/report-
problem](https://www.paypal.com/webapps/mpp/security/report-problem)

~~~
iancarroll
That link works, but this page is probably what was used -
[https://www.paypal.com/webapps/mpp/security/reporting-
securi...](https://www.paypal.com/webapps/mpp/security/reporting-security-
vulnerability)

------
kkaa
This is a big security problem with iframes. I have hoped for years that
developers of the major browsers should understand this and automatically
change the adress bar to the iframes url when the iframe is having focus.
Problem solved!

~~~
patcheudor
Not really problem solved so long as browsers continue to have cross frame
scripting (XFS) issues. There are also issues surrounding which iframe to
enumerate in the address bar. Finally, additional attacks would surely arise.
Because the host domain still owns the DOM it could overwrite the region where
the iframe is presented, knowing that the address bar would change to a
trusted domain. In short I see this sort of solution leading to major
problems.

~~~
kkaa
I do not agree with you! Cross frame scripting is not a problem today. If it
was a problem PayPal would never use this UI. And for my solution: If I place
the cursor for example in the password input, then the address bar of the
browser would show the iframe url, so the enumeration is not a problem. And if
the parent site places anything over the iframe, who cares, since it can not
fake the address bar of the browser. The point of this solution is to give the
user the possibility to verify what site the iframe belongs to.

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.

------
Sidnicious
There is a better way for technically aware users to check an iframe's
authenticity. Chrome and Firefox, at least, let you right click anywhere in an
iframe and get info about its URL and HTTPS cert.

------
csomar
I have implemented PayPal for Digital Goods a couple months ago. The Login
page opens in a separate page. I wonder if it's a privilege they give to
trustworthy websites?

------
zameerb
untils websites become smart with these we need workarounds what I do on those
occasions is one of two things, I would purposefully enter a random wrong
username and password in to paypal which usually springs up a normal browser
window with paypal url and then I retype my correct password. Or I would open
a different blank browser window and log into paypal and then go to github and
refresh which then automatically logs into paypal without reentering
password..

~~~
homakov
> I would purposefully enter a random wrong username and password

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.

------
JoachimSchipper
PayPal _probably_ has good enough fraud detection that easier-but-riskier
integration is still a net win for PayPal. (Not so much for the rest of the
internet, though...)

Similarly, Google's "No CAPTCHA"
([https://news.ycombinator.com/item?id=8693767](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.

~~~
manifesto
It's not just PayPal fraud per se. Leaking user's PayPal email address and
password has a lot of other consequences. (Yeah yeah in theory you should use
distinct passwords for different sites etc etc)

~~~
JoachimSchipper
Yes, but if PayPal's security is good enough, that's everyone else's problem.

(Yes, that's pretty nasty - but is putting a poorly-secured "startup" online
really any better?)

~~~
homakov
To log in paypal account password is enough, user-agent and IP/location can be
faked. When you're in you get access to user's transaction history. Ouch.

~~~
Gigablah
I just spent 10 minutes navigating the Paypal website trying to activate
2-factor auth on my account. Apparently they don't even offer it, at least for
Singapore accounts.

