Term user credentials defined but not used in XHR CR
User credentials is defined in section 2.2 of [1], but never used. Jonathan [1] http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/
[widgets] Authorities will never have authority?
Sorry, I missed the followup on Larry's email http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0131.html - can someone tell me where this is tracked? Specifically I want to check that the 'authority' component is adequately futureproofed. Devoid of semantics could mean devoid in this and future versions, i.e. it's a comment field. In this case it would be better to call it comment rather than authority. If instead you mean devoid in this version, but some revision of the spec gives some meaning, then you have to provide at least one value that a widget: URI minter can put in that field that will never, in the future, be taken to mean something that's not meant. Sorry for the post-LC comment, but probably a simple change of wording can clarify this to those who will be implementing the spec. Best Jonathan On Sat, Oct 10, 2009 at 12:44 PM, Larry Masinter masin...@adobe.com wrote: Re the widget: scheme http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0115.html http://www.w3.org/TR/2009/WD-widgets-uri-20091008/ (bcc www-tag since original call was; there's an AWWW suggestion buried in here somewhere, though) 1) ** WELL DEFINED QUERY AND AUTHORITY ** http://www.w3.org/TR/webarch/#URI-scheme points to RFC 2617, which has been replaced by RFC 4395. I think WebArch should be updated to recommend that W3C recommendations must use permanent schemes and not provisional ones. RFC 4395 requires that permanent scheme definitions be Well-defined. Leaving in syntactic components and declaring them out of scope is leaving them undefined. Suggestion: Remove 'authority' from the syntax, and any sections that refer to them; disallow query components Alternate Suggestion: define the meaning of authority and query components. 2) ** WELL-DEFINED MAPPING TO FILES ** Section 4.4 Step 2 makes normative reference: http://www.w3.org/TR/widgets/#rule-for-finding-a-file-within-a-widget- The algorithm there seems to be lacking a clear definition of matches which deals reasonably with the issues surrounding matching and equivalence for Unicode strings, or the handling of character sets in IRIs which are not represented in UTF8. Suggestion (Editorial): Move the definition of the mapping algorithm into the URI scheme registration document so that its definition can be reviewed for completeness. Suggestion (Technical): Define exactly and precisely what match means and make it clear what the appropriate response or error conditions are if there is more than one file that matches. 3) ** Reuse URI schemes ** http://www.w3.org/TR/webarch/#URI-scheme includes Good practice: Reuse URI schemes A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources. The draft suggests there are many other schemes (with merit) already proposed, but that these existing efforts, rather than identify packaged resources from the outside, widget URIs identify them only on the inside of a package, irrespective of that package's own location., but this seems to indicate that the requirements for widget URIs are weaker, not stronger. Suggestion: Supply use cases where reuse of existing schemes (including thismessage:/) do not provide the desired properties of identifiers and their relation to resources. Alternate Suggestion: Withdraw registration of widget: and reference existing scheme. Alternate Suggestion: Provide guidelines so that widget: can be used for other applications that need a way of referencing components within ZIP packages; rename widget: to use a scheme name that is appropriate for this broader application. AWWW Suggestion: add guideline: Make New URI Schemes Reusable If You Can't Reuse URI schemes. 4) ** EDITORIAL RE OTHER SCHEME ** In fact, it is possible that both this scheme and another defined to access Zip archive content would be used jointly, with little or no overlap in functionality. Without any other context, this is incomprehensible. Suggestion: remove sentence. 5) ** EDITORIAL USE OF URI FOR IRI ** Throughout this specification, wherever the term URI [URI] is used, it can be replaced interchangeably with the term IRI [RFC3987]. All widget URIs are IRIs, but the term URI is more common and was therefore preferred for readability. Seriously, do we need a W3C Guideline or Finding to cover DO NOT REDEFINE TERMS? There's glory for you! (see http://www.sabian.org/Alice/lgchap06.htm ). Suggestion: Use IRI since that's what is meant. 6) ** EDITORIAL RE FRAGMENT ** Note that assigning semantics or interpretation to the query or fragment components is outside the scope of this specification. The ways in which they are used depends on the content types that they are applied to, or what executable script decides to do with them. The wording might be taken to mean that a URI scheme
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
Comments inline On Sun, Dec 13, 2009 at 9:15 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 13, 2009, at 3:47 PM, Mark S. Miller wrote: On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak m...@apple.com wrote: The literature you cited seems to mostly be about whether capability systems have various technical flaws, and whether they can be made to do various things that ACL-based systems can do. This does not seem to me to show that the science is settled on how to design security systems. The question is whether separating credentials from naming has advantages over keeping them together. The references talk about certain kinds of putative advantages that have been proven illusory. It is true that there may be other advantages that haven't been articulated or surfaced. Mark is asking for help in understanding what they are. If there are undisputed weaknesses of ACLs compared to capabilities, and undisputed refutations of all claimed weaknesses capabilities compared ACLs, then what more is needed for the science to be settled? If the security considerations can't be convincing, then you are making your judgment of the inadequacy of the capability approach based on other considerations. I think there is a sincere question as to what those considerations are. Even if that is true with respect to formal security properties (and I honestly don't know), it doesn't necessarily show that ACL-based systems are always dangerously unsafe, or that the formal differences actually matter in practice in a particular case, enough to outweigh any pragmatic considerations in the other direction. Because the trusted computing base can always have flaws, and desired security policy may be formalized incorrectly, there is *always* risk. When comparing approaches based on security criteria, you have to ask which approach has lower risk. When applying other criteria, the questions are different. This may be a disagreement over goodness, so we need to work on being transparent about what good means. I'm also not sure that this Working Group is an appropriate venue to determine the answer to that question in a general way. I don't think most of us have the skillset to review the literature. Beyond that, our goal in the Working Group is to do practical security analysis of concrete protocols, and if there are flaws, to address them. If there are theoretical results that have direct bearing on Working Group deliverables, then the best way to provide that information would be to explain how they apply in that specific context. Fine with me. That's what we were doing before Adam raised the history of this controversy as an argument that we should stop. One important point to consider is that we are not deploying into a vacuum. The Web already pervasively makes use of tokens that are passively passed around to identify the agent (I feel a little weird calling these ACLs given the specific uses). In particular, the notion of origin is used already to control client-side scripting access to the DOM; and cookies are used pervasively for persistent login. I don't see a clear plan on the table for removing these passive identifiers. Removing same-origin policy for scripting would require either majorly redesigning scripting APIs or would lead to massive security holes in existing sites. As for cookies, it does not seem anyone has a practical replacement that allows a user to persistently stay logged into a site. In fact, many proposed mechanisms for cross-site communication ultimately depend at some point on cookies, including you and Tyler's proposed UM-based protocol for cross-site communication without prior arrangement. Even if a pure capability-based system is better than a pure ACL-based system (and I really have no way to evaluate, except to note that a large number of security architectures in widespread production use seem to be on some level ACL-based), it's not clear to me that solely pushing capabilities is the best way to improve the already existing Web. There seem to be two schools of thought that to some extent inform the thinking of participants in this discussion: 1) Try to encourage capability-based mechanisms by not providing anything that lets you extend the use of origins and cookies. 2) Try to build on the model that already exists and that we are likely stuck with, and provide practical ways to mitigate its risks. I don't see how we are going to settle the disagreement by further mailing list debate, because it seems to me that much of it is at the level of design philosophy, not provable security properties. This is a straw man as it does not address the question on the table. As far as I know, even if current credential-carrying same-origin requests are being challenged, prohibiting them is in neither the interest nor the power of the WG, so it's off the table. (Mark may argue for deprecation, but that in itself will have little effect.) AFAICT
Re: [cors] unaddressed security concerns
Comments below On Thu, Oct 22, 2009 at 6:12 PM, Doug Schepers schep...@w3.org wrote: Let's take it a step further, and propose a worst-case scenario. Say that some undetected hypothetical vulnerability in CORS is discovered some years from now, with a degree of severity akin to CSRF. At that time, we can learn from those new vulnerabilities, and either make CORS more secure, or develop a new technology that solves some or all or more of the use cases at hand, and discourage the use of CORS (or even block the CORS mechanism in servers and clients). Certainly, some damage will have been done. Will the damage done be more or less than the damage done by less-secure or less-private workaround developers employ instead to solve the use cases that CORS is designed for? It's impossible to predict, but it's a real question. I know that this argument is on the slippery slope towards being a slippery-slope argument, but my point is that, through inaction born of trepidation toward unknown unknowns, we may cause as much (or more) of a security problem than if we act now in a way that seems the most responsible course of action, and learn later from our mistakes how to improve the situation. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Thanks for putting the situation in these terms; I like the form of this analysis, even if am not sure I agree with the conclusion. The brief summary of the debate is that Mark M is citing Tyler's argument, and Mark's and Tyler's long experience with this kind of thing, in predicting that any system with the currently described CORS architecture will have vulnerabilities. Anne has said, I don't get it, show me the goods, and rejected a first attempt. It's not clear where the burden of proof should be; those who care about first about security will say convince me the risk is acceptable, while those who are first trying to get something done will say convince me that the risk is unacceptable. We're not talking about some unknown future vulnerability; we're talking about a known class of vulnerabilities (CSRF or confused deputy), and trying to figure out the magnitude of the risk given the proposed solution. The solution design is untried in distributed systems and in Javascript, which raises the risk, but there is a deployed analog, namely the Java security model, that those who like stack introspection can point to. So the risks are not necessarily unknowable; it may be that more analytical work is required than anyone who has been paying attention wants to invest. It seems OK if the WG's answer is let's take the risk as long as there is a well-articulated rationale similar to the one you give above. Then the downstream process can sort out whether the W3C brand should be applied to the solution. Jonathan
Re: [cors] unaddressed security concerns
On Mon, Oct 12, 2009 at 2:36 AM, Anne van Kesteren ann...@opera.com wrote: On Sat, 10 Oct 2009 01:36:50 +0200, Mark S. Miller erig...@google.com wrote: The last of the links above should make the application to CORS concrete. See also the dismissive replies which followed in that thread. If you find these dismissals plausible, please imagine back to the world in which CSRF was first diagnosed (second bullet above) as ask if CSRFs would have also seemed merely theoretical back then? In both cases, the answer well don't do that seems to make sense on first analysis for the same reasons. The concern seems to be mostly about CORS being an access control system. I'm not entirely sure that is justified (though the headers are indeed confusingly named, mea culpa). All CORS does is allowing cross-origin resources to communicate with each other. What actions follow from requests should in general not follow from (just) the origin were the request originated. That would allow all kinds of trouble. If access to resources weren't controlled (i.e. secure in the face of realistic risks), why would you deploy the feature? Then again, I think this was explained before as well, so I kind of have the feeling we are going around in circles. That you are going around in circles is an accurate assessment. I recommend you open an issue in your tracker for this, if you haven't already, and that the next time you ask the W3C membership to review a draft, if you haven't resolved the issue, that you include a note that a possible vulnerability has been identified, but that there isn't agreement in the WG over whether it is a real vulnerability; or if it is, whether it needs to be addressed. [sorry, can't figure out how to make that easier to read.] The stakes are pretty high here, so you want to make all reasonable efforts to ensure that the practice you're thinking of Recommending really is something that ought to be Recommended (as opposed to just something that's already being Done). And I think we'll all learn something if we get to the bottom of this! Think of your struggle to get consensus as an opportunity, not an annoyance. -Jonathan (not speaking on behalf of any group of which he is a member.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Origin enables XSS to escalate to XSRF (was: security issue with XMLHttpRequest API compatibility)
I think this may be a foolish question, but is the value of Origin: limited to sites? Couldn't it be an individual web page (URI)? Or a wildcard? Is there some principled reason for such a limitation (if it exists)? I took a look at the HTML5 draft (cited by CORS) and couldn't quite figure this out. Thanks Jonathan
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Dec 6, 2008, at 9:58 AM, timeless wrote: On Fri, Dec 5, 2008 at 3:42 PM, Jonathan Rees [EMAIL PROTECTED] wrote: I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz i'm 99% certain this is in the minutes from the F2F, a WUA needs to be able to instantiate multiple discreet instances of a widget, and needs to be able to distinguish them. the instances need to be distinct. Whether distinct instances should be able to enumerate and connect is not currently decided but for future improvement the scheme shouldn't prohibit this. OK, if you need to distinguish the instances, give each a different tag: URI. You could identify the instance using an entropy-generated bit string, and maintain a mapping from bit string to instance. Or, if you have some other way to designate an entity internally, such as process id + index into a table, you could put that information, or a hash of it, into the tag: URI, in combination with entropy or some other hash if you like. I hope it is clear that I'm not specifying a particular way to choose the tag: URI, as I can't because I don't know details of your requirements or architecture (sorry). The question was: Using tag: you can do just about anything you want in the way of exposing and/or hiding information (probably ten or twenty options here depending on what information and entropy feeds in and how/when/ whether it's hashed), so why not use tag: ? In other words, if you think file: and http: have problems, the tag: URI scheme might provide a way out that does not require registering a new URI scheme. You still have a design problem (which you would have regardless), but at least you avoid one source of unpleasantness. Jonathan
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz where - 2008 is fixed by convention (knowledge of date can sometimes be a security leak) - widgets-r-us.org is any domain name permitting this use (not necessarily fixed for all time, but cooperative at least at the time of the date or year occurring in the URI) (not necessarily bearing any relation to the client) and - 8948372837 is a random number, or checksum of something (the zip file maybe? ...), that is extremely unlikely to collide with anything anywhere. This avoids information leakage. (This could just as easily be put in the domain name / email address part of the URI.) The commitment on the part of the domain holder is extremely weak: the domain name is only used to avoid collisions with other tag: URIs - no promises of DNS resolution or persistence of ownership are required. (Alternatively a similarly hands-off email address could be used.) The local software would have to know how to look these things up, but the algorithm would be pretty simple: separate the URI into its parts using a regular expression, look the archive up in a table, and use zzz to get the file inside the archive. If you don't want to create a new local registry, figure out some other identification scheme and use that in the tag: URI, again being careful not to leak any local information that shouldn't be known to components that will see the URI. -Jonathan [1] http://tools.ietf.org/rfc/rfc4151.txt
