61–70 of 84 posts
If I was Stripe I'd be politely asking you to take this down. It's using their trademark (presumably) without permission and encouraging their users to do something very inadvisable. Offering to host this seems like a really bad idea. I know you're well meaning and trustworthy, but this shouldn't be run by a third party. For long term reliability reasons as much as security.
I showed it to people at Stripe before announcing it.
Earlier quoted context omitted.
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 if…
@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.yourdomain.com ).
Earlier quoted context omitted.
@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.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?
Earlier quoted context omitted.
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 if…
@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.yourdomain.com ).
Earlier quoted context omitted.
@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.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?
Earlier quoted context omitted.
@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.yourdomain.com ).
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.
Earlier quoted context omitted.
@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 – it is and it isn't. Implicit vs explicit. This answer expands: http://stackoverflow.com/a/3978372
It's also crazy enough that I wouldn't want to trust that every browser in the world will always share that same behaviour.
Earlier quoted context omitted.
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.
Listen, if you don't trust Stripe's JavaScript, just use their HTTP API instead from your server: https://stripe.com/docs/api
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
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.
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.