Products > Security

Secure URLs

<< < (2/2)

golden_labels:

--- Quote from: Mjolinor on June 22, 2019, 09:40:46 am ---Are these pop up windows covered by the original HTTPS certificate?
--- End quote ---
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.


--- Quote from: rdl on March 18, 2020, 08:51:07 am ---Seriously? They expected you to enter credit card numbers in a pop up window?
--- End quote ---
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:

--- Quote from: electrolust on July 07, 2020, 08:05:24 pm ---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.
--- End quote ---
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.

Navigation

[0] Message Index

[*] Previous page