Hacker News Reader

Comment by tptacek | Hacker News Reader

Sourcing dynamically-generated Javascript from some opaque randomized URL that plugs into an entire giant Rails application that nobody has ever assessed and that sees an "agile" deployment once every three hours, solely in order to get "dynamic A/B testing metrics" or "live chat": JUST FINE.

Sourcing static content from a static web server run by a security expert in order to segregate your application's secrets from those of Stripe: TOTALLY IRRESPONSIBLE.

View on HN

How can I be sure that it is static? And if it is static today, who's to say it won't be static tomorrow? What if the website's domain expires, and somebody snaps it up and puts something in its place? What if cperciva sells the domain to someone else?

I am not endorsing the use of third-party JavaScript on someone's payment page. I am also not endorsing the use of serving your payment form inside of a third-party iframe hosted on paymentiframe.com. I am not sure why you consider this opinion to be false.

Again: "payment page" is besides the point. The JS bug just has to happen anywhere in the path a user would take to get to the payment page.

It sure does make the argument simpler to pretend that you can just keep the Olark and Typekit and Optimizer bugs off your payments page and call it a day, but that doesn't actually do anything to protect most sites. Engage instead with my actual argument, which is that for virtually every app using these services, bugging your front page with Olark is even more unsafe than this iframe is.

@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.yourdomain.com).

Except that the evil javascript will set its domain to yourdomain.com (you're allowed to strip components) and then it can tamper with anything else from yourdomain.com.

@cperciva – wrong. Both pages have to opt into the same domain for that to work.

As in, even if the "evil script" set it's domain to yourdomain.com, unless your pages on yourdomain.com ALSO do

document.domain = 'yourdomain.com';

The script on the subdomain can't access that content.

[EDIT] Whoever is downvoting this, can you demonstrate otherwise?

My understanding is that pages from yourdomain.com would already have document.domain set to 'yourdomain.com', but I'm not a javascript expert.

@cperciva – it is and it isn't. Implicit vs explicit. This answer expands:

http://stackoverflow.com/a/3978372

This reminds me of the WAT talk.

It's also crazy enough that I wouldn't want to trust that every browser in the world will always share that same behaviour.

This document.domain behaviour is documented as part of the HTML spec:

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

Any Javascript you inject into the front page of your app owns the customer experience entirely. It does not matter that you set up a subdomain to send people to for payments; malicious Javascript is just going to "send" users to an extremely authentic looking facsimile of that domain.

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.

Seems like the best solution from where I'm sitting.

Listen, if you don't trust Stripe's JavaScript, just use their HTTP API instead from your server: https://stripe.com/docs/api

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.

Sourcing static content from a static web server

Technically, the iframe is dynamic content, seeing as it's generated by a CGI script based on the parameters in the URL. :-)

Reply on news.ycombinator.com