Wow thats a rough read.
Could something similar be done to django sites ?
Harvesting credit card numbers and passwords from websites
61–70 of 128 posts
Re: Harvesting credit card numbers and passwords from websites
#62while this post is about the more general attack vector, its worth pointing out that if you use a modern credit card tool like Stripe Elements it is impossible to steal credit card numbers as they are embedded in an iframe and your page just gets a token that is meaningless to anyone else
Re: Harvesting credit card numbers and passwords from websites
#63Earlier quoted context omitted.
You could arguably come up with something similar for backends. It's just a story of a malicious and sneaky dependency.
exactly. I question all these comments by people singling out npm as the root of the problem. doesn't sound to me like they fully understand the issue.
npm isn't the root of the problem, it's just a particularly popular example of it. Sort of like how Intel isn't really the root of that other problem, just the implementer of speculative execution with the biggest market share.
Re: Harvesting credit card numbers and passwords from websites
#64Earlier quoted context omitted.
Even if you had that, no one is going to inspect all that code. npm is a cluster-farkle of insane amounts of packages. The whole point of the article is you should implement CSP.
Sure but why not implement CSP and also get your packages from somewhere trustworthy and audit the code you actually run? Just because "most people are lazy" doesn't mean you have to be. "Audit the code you run" is still good advice right?
It's often impractical to audit the source code for all your 3rd party dependencies even if they are open source. When was the last time you or anyone you know reviewed every line of your web framework or DI framework? How about the dependencies of your dependencies? Many organizations don't even review all the code their developers write internally. Does your organization code review 100% of releases? Since inception? Like it or not, we're all placing a lot of trust in our dependencies.
Re: Harvesting credit card numbers and passwords from websites
#65Wow thats a rough read. Could something similar be done to django sites ?
Yes. There are basically three steps here...
1. Use social engineering to get your package included as a dependency;
2. Use obfuscation techniques to hide the real intent of the package;
3. Capture data and send it off to a remote server.
First can be pulled off, but really depends on the community / maintainers doing their job right. In case of Django, I imagine that would be pretty hard - while the codebase is giant, by itself it has no other dependencies (except stdlib and pytz). Then 3 could be either much easier or much harder on the backend, depending on how well the box is secured (e.g. outgoing firewall rules).
However the impact could be much more severe, since you're executing code on the server - at the very least you can inject any malicious JS you like, rewrite the CSP headers (if present), just dump the entire DB right away, and a lot of other bad things.
This basic recipe has a chance to work regardless of the target language/package manager. It's all up to your dev process and security regime to catch it.
Re: Harvesting credit card numbers and passwords from websites
#66while this post is about the more general attack vector, its worth pointing out that if you use a modern credit card tool like Stripe Elements it is impossible to steal credit card numbers as they are embedded in an iframe and your page just gets a token that is meaningless to anyone else
The attacker could inject code that replaces the Stripe integration with something that looks identical to the end-user but harvests the CCs.
Re: Harvesting credit card numbers and passwords from websites
#67What if the author snuck his code into frontend modules, and also snuck his code into backend modules? If CSP is enabled, the frontend checks to see if the backend code has opened up the particular port or route on the backend. The back-end code could sniff through require.cache to see if he could hook into the existing server instance ( same port ), or open a new port ( depending on CSP ). I suppose the CSP equivale…
Author here. Someone in a comment pointed out that you if you could get your code in express middleware (or something depended on by express middleware or similar) you could potentially alter any CSP header in the responses (if it's set in middleware before your's in the chain).
Re: Harvesting credit card numbers and passwords from websites
#68So it seems developers are in fact responsible for dependencies that they use... Who would've thought...
And anyway, what dependencies does a webpage for processing credit cards need?
Re: Harvesting credit card numbers and passwords from websites
#69Earlier quoted context omitted.
The browser’s? People do tend to keep their PC in the local timezone.
That makes sense but then the article's claim of losing half the credit cards is only true if we assume even distribution of user activity which seems far fetched at best.
I originally wrote "about half" but there was one too many words in the sentence. Also I figure for an eCommerce site max-traffic might be 7-9pm or something so even though there's more sleeping happening outside 7am-7pm, there might be equal traffic. Anyway ... close enough.
Re: Harvesting credit card numbers and passwords from websites
#70Couldn't one circumvent CSP by sending the data to a legitimate analytics service that everyone uses like Google Analytics?
This is why, when I recently built a credit card form, we didn't include any trackers or third-party code (beyond our vendor's). No dependencies at all—our vendor also has no dependencies in the JS we use to implement the CC form. That did mean no jQuery, no Google Analytics, no NPM modules and we had to build it as a standalone page outside our React setup, but it's worth it to be able to definitively inspect every…
Thanks for this. I've added a note to the post. "...consider having dedicated, lightweight pages for login and credit card collection that don’t ship any third party code (npm packages, advertising, analytics, GTM, etc.)"