Hacker News Reader

Comment by capableweb | Hacker News Reader

> How do you find out what payment processor(s) a given site uses?

I'm a developer so looking at what kind of request the application is doing when interacting with anything involving payments. In the case of OnlyFans it was easy as they make direct requests to Stripe. In other cases, I've looked at the data structures stored in the current page by using the JS console and compare it to the API docs of various payment processors.

View on HN

I'm not a web developer but I always assumed that happened on the backend, so it wouldn't be visible. I guess not?

Most websites can't/shouldn't store the card number, they embed Stripe JavaScript that sends card number to Stripe and get a token id to use on the backend later on. Can't store CCV or number without passing PCI compliance.

For the CVV you can't store it even if you have passed PCI compliance. You are only allowed to collect it for a specific transaction, and are required to forget it when that transaction is complete.

That can't be right. I entered my credit card information once into uber eats and I can buy food whenever without entering a CCV and my credit card is immediately charged.

If this were true 1000s of large companies would not be PCI compliant.

It’s possible to process transactions without a CVV, but it often costs slightly more due to the increased fraud risk. In the case of Uber Eats, they’ve presumably decided the increase in purchases from removing that friction makes up for the higher fee.

Storing the CVV permanently is indeed strictly forbidden. The CVV is not used for purchases on a stored card.

Interesting. Do they literally embed Stripe JS? I'm not a front end developer and don't know a ton about web security, but it seems like a malicious/hacked site could still get the card number this way.

The purpose of PCI compliance is to protect the number/info, so how would Stripe (and similar) get approved if they're creating a payment widget that allows third parties to snoop card numbers?

Is this a PCI loophole, or is there some technical barrier preventing the third-party site from getting access?

Stripe JS uses an iframe for card number which blocks the site from accessing the number. And the only way to access the card number is either a security hole in the iframe message handling or in the browser.

Not really. It's true that the main site (parent of the iframe) wouldn't normally have access to the card numbers, but there's nothing preventing you from replacing the iframe entirely. There isn't an "address bar" for iframes, and people certainty aren't manually checking the address by right-clicking, so there's a very high chance you can get away with it. Even if some user checked and noticed the iframe was missing, there are enough sites that don't use iframes for payment processing (ie. they submit credit card numbers directly to their servers) that it wouldn't look out of place.

> There isn't an "address bar" for iframes

Maybe there should be? If it's important to know what site you're looking at in a top level page, the same thing should apply to an embedded one.

Often when I learn about web security, it seems like the user agent abdicates responsibility to be an agent for the user.

Probably a case where it's more obvious in hindsight why this is important, but it could still be retrofitted. Maybe there's a better way, but for example, a browser could make the address bar a breadcrumb widget using multiple URLs to depict the iframe nesting.

>Maybe there should be?

How do you prevent a website from faking the address bar? The only reason that you can trust address bars right now is that the website can't draw outside the content frame. There's already attacks on mobile[1] involving fake address bars because the address bar can be hidden, allowing the site to draw a fake address bar in its place. The only secure way to do it would be to opening another window (like when you try to use sign in with google), but that still has the issue that lots of legacy sites won't use this security feature, so users will still happily enter in their credit card numbers.

[1] https://jameshfisher.com/2019/04/27/the-inception-bar-a-new-...

> How do you prevent a website from faking the address bar?

Well, my suggestion was to add additional URL(s) into the same address bar that already exists at the top. (Hence the breadcrumb widget.)

My original motivation was to not wreck the layout of pages that are currently counting on the inside of the iframe to be big enough to hold all the expected content.

But it also protects the additional URL(s) from being drawn over because you already can't draw over the address bar.

That mobile address bar hiding hack is pretty scary, though.

Yeah that is true. I guess in the end you still have to trust the site unless it uses the stripe hosted checkout.

Thanks, that makes sense. It's <iframe>, not <script>. (They're embedding more than JS.)

One of the easiest ways to ensure PCI compliance is never actually serving the credit card form from your server, and never seeing the response. Hence the front-end will load and send content to/from Stripe directly.

Depends on the implementation, with Stripe you can embed their widgets directly on your website to save some development time, but you can also implement in the backend. Even though you would implement it in the backend, there is usually some details leaking (on purpose obviously) to the frontend, like identifiers (Stripes IDs are usually pretty easy to spot) or even the structure of the data can tell you which provider.

The contents of the request should hopefully be encrypted, but you can easily see where the request is going.

Very often it is an IFrame with embedded content from the payment processor.

Reply on news.ycombinator.com