3 ms·

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

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

cperciva 14y ago
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.
bentlegen 14y ago
@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?
- cperciva 14y ago
  My understanding is that pages from yourdomain.com would already have document.domain set to 'yourdomain.com', but I'm not a javascript expert.
- bentlegen 14y ago
  @cperciva – it is and it isn't. Implicit vs explicit. This answer expands: http://stackoverflow.com/a/3978372 http://stackoverflow.com/a/3978372
  - cperciva 14y ago
    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.
    - bentlegen 14y ago
      This document.domain behaviour is documented as part of the HTML spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#relaxing-the-same-origin-restriction http://www.whatwg.org/specs/web-apps/current-work/multipage/...
tptacek 14y ago
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.
slexaxton 14y ago
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.
- tptacek 14y ago
  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.
  - bentlegen 14y ago
    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 https://stripe.com/docs/api
    - tptacek 14y ago
      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.
      - cperciva 14y ago
        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.

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

cperciva 14y ago

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.

bentlegen 14y ago

@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?

cperciva 14y ago
My understanding is that pages from yourdomain.com would already have document.domain set to 'yourdomain.com', but I'm not a javascript expert.
bentlegen 14y ago
@cperciva – it is and it isn't. Implicit vs explicit. This answer expands: http://stackoverflow.com/a/3978372 http://stackoverflow.com/a/3978372
- cperciva 14y ago
  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.
  - bentlegen 14y ago
    This document.domain behaviour is documented as part of the HTML spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#relaxing-the-same-origin-restriction http://www.whatwg.org/specs/web-apps/current-work/multipage/...

tptacek 14y ago

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.

slexaxton 14y ago

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.

tptacek 14y ago
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.
- bentlegen 14y ago
  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 https://stripe.com/docs/api
  - tptacek 14y ago
    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.
    - cperciva 14y ago
      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.