Hacker News Reader

Comment by bentlegen | Hacker News Reader

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

View on HN

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.

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/...

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.

Reply on news.ycombinator.com