14

slate.com's paid membership program collects credit card info inside an HTTPS iframe over plain HTTP . The HTTPS url is https://my.slate.com/subscriptions/manage/. Screenshot of credit card form

In an article, they claim this is safe:

When credit card data are submitted, they are sent to a third-party payment provider and your credit card data are not stored by Slate itself. Your credit card data are always sent over HTTPS. I assure you that entering your credit card information at Slate is a very safe thing to do and I hope that you enjoy Slate Plus.

However, they also take username/password over plain HTTP so I am skeptical. screenshot of username and password form

Could someone tell me if it is possible to securely get credit card information in the way they have described?

mcranston18
  • 251
  • 2
  • 6
  • 1
    yes, the info transit is safe. – dandavis Sep 09 '16 at 20:00
  • 19
    More accurately, the info transit is safe against passive attacks, but not MITM. – 700 Software Sep 09 '16 at 20:21
  • 5
    I wonder if this will be detected by Chrome's new warning for http pages that request credit card information... https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html The password form certainly will... – Ajedi32 Sep 09 '16 at 20:24
  • 2
    Your username/password are NOT sent over plain HTTP. Their homepage just uses HTTP, but the action of the form is `https://profile.slate.com/widget/traditional_signin.jsonp`, so when you submit the login form your username and password are sent encrypted to `profile.slate.com`. – Jonah H. Sep 10 '16 at 01:13
  • 1
    Dupe http://security.stackexchange.com/questions/133983/is-it-safe-to-provide-my-details-via-an-iframe and near dupe http://security.stackexchange.com/questions/31813/entering-sensitive-information-into-non-ssl-site-that-uses-secure-iframe – dave_thompson_085 Sep 10 '16 at 09:35
  • 1
    FWIW I'm implementing an iFrame payment form using a payment service provider. They *insist* that the page containing the iFrame is delivered on HTTPS. – Qwerky Oct 03 '16 at 11:59

4 Answers4

39

What they are doing is certainly better than not doing https at all. However, their external http page is more susceptible to attacks like Man-In-The-Middle that could cause the 'secure' iFrame to be replaced or compromised in other ways. This method makes it hard for end users to make their own determinations, too - the lock icon is helpful and browsers are working hard to teach the users how to determine if a site is safe.

Given the minimal cost of https now and given how much additional security it offers in general, there's no reason for them to defend this - they should just fix it and go https everywhere.

crovers
  • 6,311
  • 1
  • 19
  • 29
  • Paypal has this to say about using Secure IFrames in insecure websites: "There's lower risk compared to solutions where all the payment information is being collected directly on your website but we still have to make sure the store website itself is secure." https://www.paypal-community.com/t5/About-Products-Archive/PCI-Compliance-scanning-on-PayFlow-Link-and-Payments-Advanced/td-p/492910 – Kevin Fee Sep 09 '16 at 20:58
  • @KevinFee, typically, yes, it is often nice for security (and compliance) if someone else can keep the payment info. ....But it's not really necessary. That's an implementation detail. You certainly could have a secure site that accepts its own payment info. It's a question of resources and such. In contrast, HTTPS *is a requirement* for trust. Maybe a MITM puts the payment iframe as https://evil.org. – Paul Draper Sep 11 '16 at 04:25
  • 1
    @PaulDraper Correct. That's why the Paypal says that "we still have to make sure the store website itself is secure." If it's not secure, then a MitM can alter the secure iframe's target or inject some key logging javascript or whatever. Point being, even Paypal, who offers secure, embedded iframes, says you shouldn't rely on that feature for your all of your security. – Kevin Fee Sep 12 '16 at 15:05
8

Caveat, IANAQSA

Update: Slate isn't actually a SAQ A - they aren't using iframes, and they're submitting card info to, for example, https://profile.slate.com/widget/traditional_register.jsonp... most of what's below still applies in spirit though.

Could someone tell me if it is possible to securely get credit card information in the way they have described?

Yes, it is possible. However, there is some implied responsibility shifted to you to check that your connection is secure and that the payment site you go to is a legitimate payment processor.

That said, this configuration is both acceptable (as per PCI) and mildly inadvisable (per security best practices).

A reading of SAQ A - which applies to merchants who outsource all card handling to their processor via an iframe - suggests that this is a legal configuration. Note that it does not place any explicit requirements on the pages containing the payment page (iframe) enclosing the Service Provider's payment page(s); just the SP's page(s) come from the SP and the SP is PCI DSS compliant (which implies encryption):

SAQ A Eligibility Requirements

Now, that being said, there are issues such as MITM that make the lack of outer encryption by Slate inadvisable. Many organizations have fought their way over this hump and eventually decided that encrypting everything on their site was preferable to dealing with the perception of insecurity. But it usually takes time and complaints before they organizations get there. So feel free to complain about this.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
7

When you encrypt the whole site, you are protected against passive attackes, who only read the traffic without modifying it, as well as against active attackers, who will actively try to obtain information from you and to bypass security measures. By using an encrypted iframe, you are still protected against passive attackers, because the payment data is encrypted in transit. However, because the original page is unencrypted, an active attacker (aka a man in the middle) can just replace the secure iframe with one pointing to their own site, which they can make look identical to the one that is supposed to be there, or just force the iframe to load and submit over an unsecured connection (provided that it's not using HSTS to force you to load it over HTTPS). They are then able to capture everything that you enter, including your payment details. Moreover, there are no browser notices to inform you that what you enter is being intercepted, because iframes don't have protocol or origin indicators. That means that the only way for you to detect an attack like this would be to inspect element on the form, which almost nobody would do.

Using a HTTPS iframe is far better than nothing, but it would be wrong to say that is secure. Personally, I would never enter payment details on a page that doesn't have https in the URL bar, but when on a trusted connection (aka not public wifi), the risk is very small.

JackW
  • 713
  • 3
  • 8
  • _"There are two threats that HTTPS is intended to protect against - passive attackers and active attackers."_ Perhaps I'm misunderstanding something, but isn't this entire notion redundant? What other attacks are there, aside from "passive" and "active"? The two categories are polar opposites and between them cover the entire spectrum by definition, no? – Lightness Races in Orbit Sep 11 '16 at 10:36
  • @LightnessRacesinOrbit I included that because the risks from active and passive attackers are very different in this case, and I then handled each of them in turn. I have edited the post to clear it up, because I agree that the sentence in its original form didn't really add much. – JackW Sep 11 '16 at 11:59
  • Oh I see yep okay. – Lightness Races in Orbit Sep 11 '16 at 15:56
0

Since slate.com is redirecting to (still) slate.com, while it's a protocol switch from http to https, it doesn't qualify slate.com as having no cardholder data environment. Yes, there is the increased security (assuming TLS 1.2, for example) between the user's browser and slate.com, but that's about it.

Grant
  • 1