Secure URLs

[Mjolinor]

I was just renewing my Direct Line car insurance online.

This involves a automatically popping up chat window from a HTTPS URL. During this chat he opens another pop up window that appears next to the original chat window into which I am supposed to enter my card details.

Are these pop up windows covered by the original HTTPS certificate?

I do realise that everyone should know stuff like this but I didn't so I refused to enter my details. The chat guy kept telling me it is secure but so did the Nigerian that told me an African prince had left me millions of £.

[mariush]

A good browser will show the address bar even on popups. Or you can right click on title bar and check "show address bar" , "show menu bar" etc

For example, here's the "Manage attachments" on jonnyguru.com forums ... I see the address bar and I can click on the I logo to get information about security :

[Bob Moore]

I usually check for the domain, if it's the same as the one on the main page it should be okay. I've never seen any attempt on stealing someone's information on a chat window, on pop-ups that redirect to other sites yes.

[rdl]

Seriously? They expected you to enter credit card numbers in a pop up window?

[electrolust]

Are these pop up windows covered by the original HTTPS certificate?

who cares? you are covered to max £50 liability on your CC, by law. most issuers extend that to £0.

nobody is stealing CC data in transit, they are stealing stored data. https isn't protecting you, and neither does it matter if it's the same site/cert or not. your insurer's stored data is just as likely to get popped (actually more so) than an independent CC processor's.

if you must, have 2 CC. One for recurring payments only, one for all others. That way when the main one is compromised, at least you don't have to re-do your recurring payments.

it's just misplaced worry.

[golden_labels]

Are these pop up windows covered by the original HTTPS certificate?

Those two things are unrelated. The only thing that is important is if the page in the pop-up window is using the same certificate, if the target domain receiving your data is using the same certificate, and if every resourced (in particular scripts) used in that pop-up are using the same certificate. The second and third one may be limited by the Content-Security-Policy header, the first one may only be checked as marish has explained it.

Seriously? They expected you to enter credit card numbers in a pop up window?

You have never seen that? Then let me tell you a little horror story! Some payment services require you to enter your credentials in an iframe embedded within another party’s website. No sane method verifying who receives the data before it is sent.

[golden_labels]

nobody is stealing CC data in transit, they are stealing stored data. https isn't protecting you, and neither does it matter if it's the same site/cert or not. your insurer's stored data is just as likely to get popped (actually more so) than an independent CC processor's.

No one? So what are doing those people, who have stolen credit card data from websites of 8 US cities — in transit, not stored? That particular malware is observed in the wild for over a year now.

Note: TLS connection alone would not prevent that, as malware was served from a compromised server. I’m countering this particular claim.

[electrolust]

that's not something you can detect, eg by inspecting the URL. the attack you are describing is, from the end user POV, equivalent to stealing stored data. it's not something you can protect against and it's not something you need to care about -- for CC data I mean.

[golden_labels]

No, the data is not stored. It is stolen directly in the browser, before it even has a chance of reaching the infrastructure of the intended website.

As for other things, which you brought up despite not being related to the original statement:

Yes, you can prevent it. In most cases proper CSP stops the attack. Even if it does not, because the attacker was able to modify CSP, then what I have said above still holds: two of three points I’ve mentioned are dealing with exactly that type of attack. If I would claim that common configurations allow you to do that easily, you would be right, but I haven’t.

And, for example with my current setup, it is impossible to execute. Unless the victim server is also used t store stolen data (which is not the case here). It requires contacting a 3rd party domain and I would have to explicitly allow that. It is not possible, at any significant level, if your company blackholes blacklisted domains. So I’m not theoretical here.

3-D Secure also makes the attack hard, even for an average setup.

[electrolust]

you are correct, i didn't read the link closely enough. still, that kind of attack is not the common type of stored data theft. regardless, the point is, you as consumer don't need to care about it.

CSP is not something the user can fix or configure. or, for the normal user, even reason about. even most implementers have no clue.

yes, there are at least 3 payment scenarios and at least iframe is impossible to intercept. however, even then, the user cannot know if the iframe is going to the actual payment provider or an injected other provider. IOW you as attacker hijack the flow before it gets to the (stripe, whoever) payment processor. the real difference in the 3-ish methods to take payment are in degree of detection, not prevention. VISA EU does a great job of breaking it down in their PCI documentation.