Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.
On Tue, 8 Dec 2009, Sebastian Andersson wrote: On Sat, Dec 5, 2009 at 09:53, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Dec 2009, Sebastian Andersson wrote: How would the policy file and the service not be under the same control? In a shared hosting environment, typically port 80 is a virtual hosted HTTP server, and the ports above 1024 are under the control of the first user to bind to it. So ports 1024 and 1025 can be under the control of different users. If the policy file is served from port 1024, it can allow script on port 80 from one virtual host to access the service on port 1025 intended for scripts of pages of another virtual host on port 80. Just like the firewall would have to be opened up for the new service's port, so would the policy file have to be updated. That is a job of the service provider, not of any of the users and as I already wrote, that is an administrative issue, not a technical one. Right now, today, if I were to expose a WebSocket service on my Dreamhost shared server, I could do so without any trouble. If we used a scheme such as the one described above using a policy file, anyone else also hosting their site on the same server could grant access to my server to their scripts on their page. Whether this is a technical or administrative issue, it's an issue we have to handle today. If we assume a round-trip time of 120ms, that means that opening a WebSocket connection takes 360ms rather than the 120ms it takes with the security model in the spec today. That's a lot of extra latency. One could also do both connections at the same time, but not open the socket to the application until the policy file has been read. Or simply use a cache. That seems more complex than necessary. It would probably be among the simplest of the code in a browser that is able to render html5 and run javascript. Sure, but that doesn't mean it's not more complex than necessary. I don't know if the current player caches the result, but that could be added. Then you increase the race condition I mentioned from being merely a few milliseconds to being whatever the time-to-live of the policy file is. Since I fail to see the attack scenario, I fail to see the race condition. The race condition is a separate issue. The race condition is what happens when the policy changes between the time that the policy file is read and the connection is established. Consider for instance the window between an error being found in a policy file and the policy being fixed. If the policy has a 24 hour time-to-live, then the site is automatically vulnerable for up to 24 hours for some users. I still don't see an attack scenario being described here. Yes, administrative changes will take some time to propagate when caches are used if the object has been cached. Just like DNS, some CDNs, reverse proxies etc., that is hardly something new for an administrator. The policy file is only one of many access control mechanisms and even if it is incorrectly written, it would still take special malicious code to create a vulnerability, the firewall would have to allow access to the port There's no firewall in a shared hosting environment. and the service's access control mechanisms would have to allow the connection and the browser would somehow get to run the malicious code from an origin that was listed in the policy file. If we weren't worried about malicious code from an origin that was (mistakenly) listed in the policy file, then we wouldn't have a problem. Of course there is an opportunity, but is it a big risk? IMHO, yes. I understand that security is a tradeoff between risk and reward, but fundamentally, it seems to me that it is far off the risk/reward scale to design a system in such a way that a security problem cannot be fixed when it is discovered. Having the user agent cache the security policy and act on that cached version even after a security problem has been found prevents security problems from being fixed in a timely manner. What's wrong with the way WebSocket does it? Many custom protocols are based on a length field followed by a protocol frame. With WebSocket it is possible to connect to such a service and be connected for a while until a timeout happens and thus a DoS attack against such a service would be trivial to write. Interesting. Do you have any examples of such services that I could study? If we could mitigate that that would be very useful. Are these services that send no traffic until they've received the first packet? MS-RPC and CIFS are such I believe. Interesting. I shall study these, thanks. I spoke to one of the Samba developers about this issue. He pointed out that such attacks with Web Sockets are already possible with unscripted HTML pages today, since any page, even
Re: [XHR][XHR2] HTTP redirects / XHR Version detection
Le 30/01/2010 04:41, Anne van Kesteren a écrit : On Sat, 23 Jan 2010 23:05:50 +0100, David Bruant dbru...@ucsd.edu wrote: My comments and questions are based on the editor's drafts (http://dev.w3.org/2006/webapi/XMLHttpRequest/ and http://dev.w3.org/2006/webapi/XMLHttpRequest-2). Between the two versions of the same-origin request event rules (#same-origin-request-event-rules), for the If the response is an HTTP redirect rule, the word transparently has disappeared. I understood the word transparently as don't consider any other step of the algorithm (like switching to the HEADERS_RECEIVED state, because if a redirect has been detected, it means that the headers has been received at least the location header). The absence of this word in XHR2 suggests that the state should be switched to HEADERS_RECEIVED even if it is a redirect. So, more generally, my question is : for HTTP redirects, should the implementations of XHR and XHR2 switch the state to HEADERS_RECIEVED ? I don't know how it is currently implemented by the current browsers, but I would be in favor of switching the state (and thus dispatch an event) so that authors could write tools allowing them to have an idea of the number of redirects generated by some URL and then do an analysis of their websites (for instance all the links within a HTML page) from the client side. The idea is actually that a redirect does not involve a state transition. I have suggested on this mailing list a way to control whether redirects are followed but due to lack of response I have not done anything with it so far. Ok. The use case that could require to not follow silently or to follow silently but still leaving so kind of trace of redirects is a project I am currently working on : http://wiki.github.com/DavidBruant/linkChecker/ This is still very experimental (and a mess !) and not really ready to be deployed on actual websites. But the idea is to execute some JS on the client side and create a report of all resource links that can be found. Because it is run on the client side, if some content brought asynchronously contains links, these can be tested too (what is not true about this static checker : http://validator.w3.org/checklink). I think that the clients of my library could be interested in knowing if some links involve none or one or a lot of redirects. Redirects imply back and forth communication between client and server, as a consequence, they can affect performance of applications. For that reason, it could be interesting for me to provide the number of redirects and the different intermediate locations in the report. It would be a good way to provide a full analysis of the HTTP traffic. Would it be clearer if after Once all HTTP headers have been received and the asynchronous flag is true I added (and this is not an HTTP redirect)? I think that because receiving HTTP headers are chronologically the first thing that happens, it could be the first written : Once all HTTP headers have been received and the asynchronous flag is true if it is an HTTP redirect then blabla if it is not, blabla. Now I know that the semantic of the HEADERS_RECEIVED state is not headers received, but headers of the expected/final resource received, I think it would deserve some sort of note at this (http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#headers-received-state) moment to explain that it is not only a matter of recieving some/any headers, but there is also the notion of final/expected resource. My next question should find its answer thanks to the previous one, but juste to be sure : Is it possible that the state be to DONE and the status be a redirect (300 = status 400) ? If there is no Location header this is possible. (Have not tested whether this is correctly implemented.) Ok, thank you. If the behavior has changed between XHR and XHR2, how authors can know what version is implemented by user agents ? In other words, is there a way defined by the spec to make the difference between a XHR conforming user agent and a XHR2 conforming user agent since the interface has the same name (XMLHttpRequest) ? No, because in general user agents do not implement everything from one or the other. E.g. a couple of user agents implemented features from XHR2 but are not at all conforming to XHR1 requirements that did not change in XHR2. Implementations evolve organically, not in concrete steps. So, why having two specifications in a working draft state ? Wouldn't it be easier for maintenability of the specs to have only the XHR2 spec and notes about legacy behaviors (and attributes/methods) ? Will XHR1 reach the recommandation state one day ? Will it make sense ? Thank you for the answer. David
RE: Microsoft pre-LCWD feedback on WebSocket API
On Wed, 16 Dec 2009, Adrian Bateman wrote: On Thursday, December 03, 2009 5:20 PM, Ian Hickson wrote: On Thu, 19 Nov 2009, Adrian Bateman wrote: 1) In the WebSocket constructor, we think it would make sense to limit the optional protocol string to a set of characters that is easier to secure. The UI never surfaces this string and having something that doesn't require processing the full set of strings into UTF-8 shouldn't be a significant restriction. We also think that specifying length constraints would be useful. For example, stipulating the minimum length that conforming implementations must be able to handle. One suggestion was to re-use the same criteria as a valid scheme name as defined in section 3.1 of RFC 3986. I don't see why we'd make it _that_ restricted, but I do agree that it needs to be restricted to at least disallow non-ASCII characters and CRLF, since that would break the handshake. I've updated the spec accordingly. Our general feeling was that having it be fairly restrictive was unlikely to be problematic and it is easier to relax the constraints if it becomes apparent that it is necessary than to try to constrain further in future. I don't think that's really a good reason to restrict things. XML tried that approach (over-restrict and relax later) and it caused all kinds of problems. Generally speaking, it's when we start having extra conditions that implementations mistakes creep in, with the associated lack of interoperability, and potentially even security bugs. I'd really much rather keep everything really simple than have arbitrary restrictions. 3) The spec uses many terms that the HTML5 spec defines. As far as I can tell, there isn't a definitive list of these. The 2.1 dependencies section notes that many concepts come from HTML5 but not saying which ones seems insufficient for spec moving to Last Call. Most of the people who looked at this spec had never looked at HTML5 before and their feedback was simply that many terms were undefined. I recommend using the WHATWG complete.html version of the spec, which integrates all of HTML5 and both the Web Sockets API and Web Socket protocol specs (and a few others) into a single document: http://www.whatwg.org/specs/web-apps/current-work/complete.html#network The cross-references in that document mean that all the terms defined in HTML5 are clearly referenced. I am hoping that we will be able to make the postprocessor generate appropriate cross-references even in the case of the split specs. This seems like something that should be done before the spec proceeds. gsnedders has said he's working on this, so I'll wait until he's done and then try to apply his work to this spec. Failing that, would the approach I recently used in the Microdata draft be acceptable? http://dev.w3.org/html5/md/#terminology It makes the cross-references in the spec all go to a single terminology section, which thus disambiguates which terms are defined in HTML5 and which are not. Notwithstanding the way the spec is split at the W3C and the IETF, this really is all just part of the complete.html spec at the WHATWG. I don't want to duplicate the definitions everywhere, since then they'd start getting out of sync, which is a recipe for disaster. 4) In step 2 of the UA steps for the WebSocket() constructor, the spec calls for an exception to be thrown if the user agent chooses to block a well-known port. We think that web developers will often miss this case because it will be hard to test the error case and may be an unusual failure. We propose that the UA signal this condition in the same way as failing to connect to a service which will be much more common and more likely to be handled by web developers. Wouldn't this error be caught very early in development, when the connection just wasn't established? It seems unlikely that non-hostile authors will ever run into this anyway, since they shouldn't be using these ports. It's not clear that all user agents would impose the same rules so there's no guarantee this would be caught. It's entirely possible someone might legitimately host a WebSocket service on a well-known port believing this to be an appropriate strategy without realising that some user agents might block that. Our feedback is that it is a best practice in library design to encourage developers to handle unusual cases without the need to write extra code. It is common for developers to measure the success of their testing with code coverage - we prefer to avoid trying to get our test teams to have to set up weird test beds to construct obscure test cases to test unusual scenarios. I don't really see how firing onclose is going to help in this case. If the author isn't going to catch this before shipping, why is it going to make
