8 ms·
Stripe moves to JSONP; adds CORS support
- gkoberger 14y agoInteresting they choose JSONP (which is GET only, and can't return proper error codes) for such a POST-heavy library. It doesn't really matter, since they abstract it away. However, it's interesting they're completely ignoring so many basic REST principles. Edit: I don't disagree with their decision, I just imagine it wasn't an easy one.
- jonknee 14y agoIt's not interesting, if you read the post you would know that they did it because of IE lacking support for CORS. > Unfortunately, that’s not quite enough for Stripe.js. IE6 and IE7 both lack CORS support, while IE8 and IE9 have broken implementations. IE10 is the only version with a non-buggy CORS implementation. Obviously, compatibility is paramount for Stripe.js — we want to support all major browsers, right down to IE6—and so we needed to look elsewhere.
- bceagle 14y agoFYI, it is true that the implementation is broken in IE8 and IE9, but there is a fairly straightforward fix. http://mcox.tumblr.com/post/22791023337/ie-cors-support-in-jquery http://mcox.tumblr.com/post/22791023337/ie-cors-support-in-j...
- cheald 14y agoPracticality > ideology. I'd rather have a functioning solution that "ignores basic REST principles" and lets me accept money from IE users than a principled library that requires the latest greatest browser to process transactions with.
- gobengo 14y agoI'm not sure how common this is, but our application totally has a middleware to allow simulating other methods via _method and _body querystring parameters in GET requests. I know I've seen many other companies do this. Some may scoff at this for probably naive reasons, but REST doesn't have to mean 'correct' HTTP. It's just an architectural style.
- bitsweet 14y agoTL;DR; JSONP is the only hack that is IE proof IE6, as usual, doesn’t support postMessage. IE6 and IE7 both lack CORS support, while IE8 and IE9 have broken implementations Oh what mankind could have achieved by now if we weren't so occupied making our websites work in IEx.
- justatdotin 14y ago... if we weren't so occupied making our websites work for users ... ? deal with it: or not.
- voltagex_ 14y agoxdr.js will mostly work for IE7/8 as far as I can tell.
- RKearney 14y agoWell people need to stop writing code specifically for IE and just stick to web standards. If Google/Facebook/PayPal/All Banks stopped coding hacks to get their sites to work in IE, the users that use IE would have no other choice but to switch to a standards compliant web browser.
- deleted 14y ago[deleted]
- prodigal_erik 14y agoIE users should get the standard-compliant pure-HTML version which is sure to work on every browser. Only developers who neglected to start there have a problem.
- esrauch 14y agoI dont buy it. Some features just aren't reasonable to do without js and the number of people without js is tending towards vanishingly small, and you can have a nondegraded experience for a very significant percentage of traffic by not just dismissing all versions of IE. Not that you should support all versions, but if you are sending a separate no-js version to IE10 then you are doing it wrong. In my experience it is totally absurd to think that you can just write "standards compliant HTML" and expect it to be rendered correctly on IE6 or 7 in any meaningful way anyway, you will always need to change your HTML and CSS to specifically support those browsers and realistically any browser that you want to support, the standards just are not uniformly implemented.
- taskstrike 14y agoThis is big, it's another functionality that used to be server only moving to the clientside.
- dos1 14y agoAre there any security concerns with this? Is the URL of a GET request over SSL encrypted as well as the payload? I assume it must be if they are sending credit card information that way?
- Pwntastic 14y agoIf I remember correctly, most of the URL including the parameters are encrypted when you use SSL. I think the only part that isn't is the hostname
- gcr 14y agoAlmost right. The entire URL, including the hostname, is "encrypted," but you still have to have the IP address of the machine you're talking to, which means your machine will probably be doing (unencrypted) DNS lookups and will send encrypted packets to the target's IP address. Attackers can see the hostname of the machine you're talking to, but not because it's an "unencrypted" part of the SSL packet somehow.
- pc 14y ago> Is the URL of a GET request over SSL encrypted as well as the payload? Yes. Obviously, DNS resolution of the host happens in the clear, but SSL handshake takes place before the path is transmitted.
- dan15 14y agoSSL/TLS is at a lower level than HTTP. The whole connection is secure as all the encryption is set up before the HTTP request is even sent. This is why SSL used to always require a dedicated IP address - The server didn't even know what domain you were going to while the connection was being set up (as the host name is in the HTTP headers) so you could only have one SSL certificate per IP address. Server Name Indication (http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication) works around this by sending the host name during the TLS handshake, so that multiple domains can use SSL on the same IP address. In this case, only the host name is sent in the clear. The whole HTTP request and response are still encrypted.
- jashkenas 14y agoI'm curious about how this change handles cross-domain security. Is there never any sensitive data in Stripe.js' JSONP responses? Or do y'all have a mechanism for preventing a malicious 3rd party site from loading a script pointing at one of your JSONP urls?
- cheald 14y agoIt shouldn't be any different than the existing functionality. stripe.js is solely responsible for turning credit card information into one-use tokens, so that CC information never hits your servers. That token is then used to communicate with Stripe using a private shared key (kept serverside, never exposed on the client) to create a Customer record, which is then used to conduct the actual money parts of the transaction. So, a malicious party could create tokens with CC information, but without the private key they'd have no way to use them.
- pc 14y agoYeah, that's right. It's also worth emphasizing that the Stripe API doesn't support sessions, and so isn't vulnerable to standard CSRF attacks.
- tlrobinson 14y agoThis is only an issue if you use cookies to authenticate JSONP requests, which you shouldn't do. I wrote a summary of the issues with JSONP on StackOverflow awhile ago: http://stackoverflow.com/a/1392153 http://stackoverflow.com/a/1392153
- dreamdu5t 14y agoEwwww JSONP. Keep it RESTful with useful response codes. People accepting credit card payments online should have the ability to do things server-side instead of use JS.
- cheald 14y agoYou might want to read up on how Stripe works before commenting.
- mmahemoff 14y agoHopefully they add a "pay" Web Intent next. (The Web Intent polyfill is implemented with the same postMessage hack they were originally using, so technically they could just use the web intent and nothing else. Though in practice, it probably doesn't handle cross-domain iFrame messaging for the old browsers that don't support postMessage.)
- smarx 14y agoWhat's broken about CORS in IE8 and IE9?
- abraham 14y agoSupported somewhat in IE8 and IE9 using the XDomainRequest object http://caniuse.com/#search=cors http://caniuse.com/#search=cors
- JoshTriplett 14y agoThis seems like a step backward. The iframe-based communication, as hackish as it seems, allows cross-domain communication without resorting to completely unsandboxed script tags referencing a remote server. Meanwhile, JSONP uses a script tag, and nothing forces the response to actually conform to JSONP (JSON wrapped in a specific function call) rather than running arbitrary Javascript code.
- lucasgonze 14y agoThe only new exploit I can think of is domain hijacking, so that an attacker replaces the real Stripe response with their own. If they can do domain hijacking, though, whether or not they choose to insert the replaced content into a third party page via JSON is a less damaging hack than just swiping your credit card info sent to Stripe.
- JoshTriplett 14y agoDomain hijacking doesn't seem like an issue here, given HTTPS; if someone can MITM that they can do the same to my own site. However, just because I trust a service to process payments or do any other specific business-critical task doesn't mean I trust that service to run arbitrary Javascript code in the context of my site. Customers may have significantly more sensitive data than just payment information, and third-party Javascript represents a major issue. I need the ability to confidently say to customers that no third-party service has access to their private data. Given this new approach, I'd have to sandbox payment code off on a separate domain that has no access to other user data.
- cheald 14y ago> However, just because I trust a service to process payments or do any other specific business-critical task doesn't mean I trust that service to run arbitrary Javascript code in the context of my site. You...include their Javascript on your site to even be able to make the JSONP calls in the first place. Their "arbitrary Javascript" is on your domain already. You certainly could audit it, locally mirror it, and then do that every time they publish an update, but are you actually going to do that?
- jader201 14y agoSorry for the off-topic comment, but I couldn't help but notice (and comment on) the noticeably slow-loading picture of Alex at the top, only to realize it's a 378KB 500x500 image[1] resized at render-time to 68x68. I'm just surprised that a tech company like Stripe w/ such a polished site and attention to UX would not find a way to optimize this. [1] https://stripe.com/img/about/team/alex.png https://stripe.com/img/about/team/alex.png