How to evaluate Web Applications security designs?
Author(s) and publish date
- By:
-
-
Dan Connolly
-
- Published:
I could use some help getting my head around security for Web Applications and mashups.
The first time someone told me W3C should be working on specs help the browser prevent sensitive data from leaking out of enterprises, I didn't get it. "Use the browser as part of the trusted computing base? Are you kidding?" was my response. I didn't see the bigger picture. Crockford explains in an April 2008 item:
... there are multiple interests involved in a web application. We have here the interests of the user, of the site, and of the advertiser. If we have a mashup, there can be many more interests.
Most of my study of security protocols concentrated on whether a request from party A should be granted by party B. You know, Alice and Bob. Using BAN logic to analyze the Kerberos protocols was very interesting.
I also enjoyed studying capability security and the E system, which is a fascinating model of secure multi-party communication (not to mention lockless concurrency), though it seems an impossibly high bar to reach, given the worse-is-better tendency in software deployment, and it seemed to me that capabilities are a poor match for the way linking and access control work in the Web:
The Web provides several mechanisms to control access to resources; these mechanisms do not rely on hiding or suppressing URIs for those resources.
On the other hand, after wrestling with the patchwork of javascript security policies in browsers in the past few weeks, the capability approach in adsafe looks simple and elegant by comparison. Is there any chance we can move the state-of-the-art that far? And what do we do in the mean time? Crockford's Jan 2008 post is quite critical of W3C's current work:
This same sort of wrong-end-of-the-network thinking can be seen today in the HTML 5 working group's crazy XHR access control language.
Access Control for Cross-Site Requests is a mouthful, and "Access Control" is too generic, which leads to "W3C Access Control". Didn't we already go through this with "W3C XML Schema"? Generic names are awkward. I think I'll call it WACL... yeah... rhymes with spackle... let's see if it sticks. Anyway...
Crockford's comment cites his proposal and argues...
JSONRequest does not allow the server to abdicate its responsibility of deciding if the data should be delivered to the browser. Therefore, no policy language is needed. JSONRequest requires explicit authorization. Cookies and other tokens of ambient authority are neither sent nor delivered.
I'm not sure I understand that. I'm glad to learn there's more to the difference between XMLHttpRequest and JSONRequest than just <pointy-brackets> vs {curly-braces}, but I'd like to understand better how "ambient authority" relates to the interests of users, sites, advertisers, and the like.
In response, the FAQ in the WACL spec says:
JSONRequest has been considered by the Web Applications Working Group and the group has concluded that it does not meet the documented requirements. E.g., requests originating from the JSONRequest API cannot include credentials and JSONRequest is format specific.
Including credentials seems more like a solution than a requirement; can someone help me understand how it relates to the multiple interests involved in a web application?
We want it to be possible for authentication mechanisms in place today for HTTP to be used by the client side HTTP API for the Web. We also want people to be able to exchange XML, HTML, text, image files, etc. using this API without having to resort to some clumsy JSON workaround for that. (E.g., wrapping JSON around XML. Not sure how that would even work for files.)
E.g., going forward it will be possible to create file upload controls that work with <input type=file> and XMLHttpRequest so you can create Flickr like upload widgets without having to resort to Flash. If the upload widget and file server are on separate domains it would be nice if things would just work, without having to resort to hacks.
Anne, yes, I understand the "must be applicable to arbitrary media types" requirement and I see how JSONRequest doesn't meet it. I suppose my " vs {curly-braces}" quip was too brief to be clear.
But what I'm trying to understand is the first half of of "requests originating from the JSRONRequest API cannot include credentials and JSONRequest is format specific," in the words of the WACL FAQ, vs. Crockford's claim that "tokens of ambient authority are neither sent nor delivered" is a feature. I'm trying to understand how this relates to multiple interests involved in a web application.
p.s. odd... this thing used to do openid; it doesn't even seem to ask for a link when it asks for name and email address any more.
I tried rewording why JSONRequest is not an adequate solution. I left out user credentials for the moment as that is just an aspect of the overall REST architecture that we want to allow.