New Paypal gateway UI susceptible to spoofing • Hacker News Board

Re: New Paypal gateway UI susceptible to spoofing

#21

Post by idbehold » Sun, Dec 07, 2014, 4:47 PM UTC

spartas wrote: post #14

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

Re: New Paypal gateway UI susceptible to spoofing

#22

Post by zaroth » Sun, Dec 07, 2014, 4:53 PM UTC

talldan wrote: post #18

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…

Don't most competent popup blockers actually allow popups which are implemented plainly as links with a different target? I mean, the popups you want to block are only the ones which don't result in a single window/tab opening directly based on a user input where you would expect a popup to result.

Re: New Paypal gateway UI susceptible to spoofing

#23

Post by homakov » Sun, Dec 07, 2014, 5:00 PM UTC

talldan wrote: post #18

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…

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

Re: New Paypal gateway UI susceptible to spoofing

#24

Post by talldan » Sun, Dec 07, 2014, 5:00 PM UTC

zaroth wrote: post #22

talldan wrote: post #18

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…

Don't most competent popup blockers actually allow popups which are implemented plainly as links with a different target? I mean, the popups you want to block are only the ones which don't result in a single window/tab opening directly based on a user input where you would expect a popup to result.

yes - as I mentioned above, it's impossible to do this in one step, though. It requires getting the url from a server-side call, and then rendering the link to that url. Since the pressure is on to reduce friction in the process, you can see why this has been reduced to using an iframe (which can launch seamlessly in a single button press).

Re: New Paypal gateway UI susceptible to spoofing

#25

Post by talldan » Sun, Dec 07, 2014, 5:03 PM UTC

homakov wrote: post #23

talldan wrote: post #18

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…

>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-f…

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

Re: New Paypal gateway UI susceptible to spoofing

#26

Post by homakov » Sun, Dec 07, 2014, 5:06 PM UTC

talldan wrote: post #24

zaroth wrote: post #22

Earlier quoted context omitted.

Don't most competent popup blockers actually allow popups which are implemented plainly as links with a different target? I mean, the popups you want to block are only the ones which don't result in a single window/tab opening directly based on a user input where you would expect a popup to result.

yes - as I mentioned above, it's impossible to do this in one step, though. It requires getting the url from a server-side call, and then rendering the link to that url. Since the pressure is on to reduce friction in the process, you can see why this has been reduced to using an iframe (which can launch seamlessly in a single button press).

If by "server-side" call you mean getting a token for Express Checkout, I don't see how it's different from any existing OAuth implementation where site.com/oauth/twitter redirects to twitter.com/?oauth_token=TOKEN. That's the best practice actually.

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

Re: New Paypal gateway UI susceptible to spoofing

#27

Post by homakov » Sun, Dec 07, 2014, 5:07 PM UTC

talldan wrote: post #25

homakov wrote: post #23

Earlier quoted context omitted.

>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-f…

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

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

Re: New Paypal gateway UI susceptible to spoofing

#28

Post by spartas » Sun, Dec 07, 2014, 5:17 PM UTC

idbehold wrote: post #21

spartas wrote: post #14

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

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.

Re: New Paypal gateway UI susceptible to spoofing

#29

Post by homakov » Sun, Dec 07, 2014, 5:18 PM UTC

zameerb wrote: post #19

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…

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

Re: New Paypal gateway UI susceptible to spoofing

#30

Post by spartas » Sun, Dec 07, 2014, 5:19 PM UTC

muglug wrote: post #20

spartas wrote: post #14

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…

But it would be very easy to forge any secure iframe address bar using JS/CSS.

The bar would be part of the user agent's iframe element, not accessible via JS/CSS.

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.