web_applications_security_requ.html 14.4 KB

Raw Blame History Permalink

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <style type="text/css" media="all">
    @import "/QA/2006/01/blogstyle.css";
    </style>
    <meta name="keywords" content='security, webapps' />
    <meta name="description" content=" 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..." />
    <meta name="revision" content="$Id: web_applications_security_requ.html,v 1.38 2011/12/16 03:03:12 gerald Exp $" />
   <link rel="alternate" type="application/atom+xml" title="Atom" href="http://www.w3.org/QA/atom.xml" />
   <link rel="alternate" type="application/rss+xml" title="RSS 1.0" href="http://www.w3.org/QA/news.rss" />
   <title>How to evaluate Web Applications security designs? - W3C Blog</title>

   <link rel="start" href="http://www.w3.org/QA/" title="Home" />
   <link rel="prev" href="http://www.w3.org/QA/2008/11/_as_part_of_a.html" title="Interview: Dan Appelquist on Vodafone, Mobile Web, and W3C Standards" />
   <link rel="next" href="http://www.w3.org/QA/2008/12/xml_and_language_resources.html" title="XML and language resources" />


    <!-- <script type="text/javascript" src="http://www.w3.org/QA/mt.js"></script>-->

</head>
<body class="layout-one-column">
      <div id="banner">
      <h1 id="title">
	<a href="http://www.w3.org/"><img height="48" alt="W3C" id="logo" src="http://www.w3.org/Icons/WWW/w3c_home_nb" /></a>
W3C Blog
</h1>
    </div>

    <ul class="navbar" id="menu">
        <li><strong><a href="/QA/" title="W3C Blog Home">[ W3C Blog ]</a></strong></li>
        <li><a href="/QA/Library/" title="Documents and Publications on Web and Quality">Documents</a></li>
        <li><a href="/QA/Tools/" accesskey="3" title="Validators and other Tools">Tools</a></li>
        <li><a href="/2007/12/qa-blog-help/index#feedback">Feedback</a></li>
    </ul>
<div id="searchbox">
<form method="get" action="http://www.google.com/custom" enctype="application/x-www-form-urlencoded">
<p id="formbox"><input type="text" size="15" class="textfield" name="q" accesskey="E" maxlength="255" /> <input type="submit" class="submitfield" value="Search" id="goButton" name="sa" accesskey="G" /> <input type="hidden" name="cof" value="T:black;LW:72;ALC:#ff3300;L:http://www.w3.org/Icons/w3c_home;LC:#000099;LH:48;BGC:white;AH:left;VLC:#660066;GL:0;AWFID:0b9847e42caf283e;" /><input type="hidden" id="searchW3C" name="sitesearch" checked="checked" value="www.w3.org/QA" /><input type="hidden" name="domains" value="www.w3.org/QA" /></p>
</form>
</div>


    <div id="main"><!-- This DIV encapsulates everything in this page - necessary for the positioning -->

                     <p class="content-nav">
                        <a href="http://www.w3.org/QA/2008/11/_as_part_of_a.html">&laquo; Interview: Dan Appelquist on Vodafone, Mobile Web, and W3C Standards</a> |
                        <a href="http://www.w3.org/QA/">Main</a>
                        | <a href="http://www.w3.org/QA/2008/12/xml_and_language_resources.html">XML and language resources &raquo;</a>
                     </p>

                        <h2 class="entry-header">How to evaluate Web Applications security designs?</h2>
                           <div class="entry-body">

<p>I could use some help getting my head around security for Web
Applications and mashups.</p>

<p>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 <a
href="http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=819"
>April 2008 item</a>:</p>

<blockquote>
<p>
... 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.</p>
</blockquote>

<p>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 <a href="http://en.wikipedia.org/wiki/BAN_logic">BAN
logic</a> to analyze the Kerberos protocols was very interesting.</p>

<p>I also enjoyed studying <a
href="http://erights.org/elib/capability/ode/overview.html">capability
security and the E system</a>, 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 <a
href="http://www.w3.org/TR/webarch/#id-access">linking and access
control</a> work in the Web:</p>

<blockquote>
<p>
The Web provides several mechanisms
to control access to resources; these mechanisms do not rely on
hiding or suppressing URIs for those resources.
</p>
</blockquote>

<p>On the other hand, after wrestling with the patchwork of javascript
security policies in browsers in the past few weeks, the capability
approach in <a
href="http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=706"
>adsafe</a> 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? <a
href="http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=736"
>Crockford's Jan 2008 post</a> is quite critical of W3C's current
work:</p>

<blockquote>
<p>This same sort of wrong-end-of-the-network thinking can be seen today
in the HTML 5 working group's <a href="http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0008.html">crazy    XHR access control language</a>.
</p>
</blockquote>

<p><a href="http://www.w3.org/TR/access-control/">Access Control for Cross-Site Requests</a>
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...</p>

<p><a href="http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=736"><span id="date">Crockford's comment</span></a> cites his proposal and argues...</p>

<blockquote>
<p>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.</p>
</blockquote>

<p> I'm not sure I understand that. I'm glad to learn there's more to
the difference between XMLHttpRequest and JSONRequest than just
&lt;pointy-brackets&gt; vs {curly-braces}, but I'd like to understand
better how "ambient authority" relates to the interests of users,
sites, advertisers, and the like.</p>

<p>In response, the <a href="http://www.w3.org/TR/access-control/#design-decision-faq">FAQ in the WACL spec</a> says:</p>

<blockquote>
<p>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.
</p>
</blockquote>

<p>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?</p>


                           </div>
                           <div id="more" class="entry-more">

                           </div>
                       <p class="postinfo">Filed by <a href="http://www.w3.org/People/Connolly/">Dan Connolly</a> on December  3, 2008  5:00 PM in <a href="http://www.w3.org/QA/archive/technology/html/">HTML</a>, <a href="http://www.w3.org/QA/archive/web_architecture/">Web Architecture</a><br />
<span class="separator">|</span> <a class="permalink" href="http://www.w3.org/QA/2008/12/web_applications_security_requ.html">Permalink</a>
                                 | <a href="http://www.w3.org/QA/2008/12/web_applications_security_requ.html#comments">Comments (3)</a>

</p>


<h3 class="comments-header" id="comments">Comments</h3>
<div class="comment" id="comment-169513">
<p class="comment-meta" id="c169513">
<span class="comment-meta-author"><strong>Anne van Kesteren </strong></span>
<span class="comment-meta-date"><a href="#c169513">#</a> 2008-12-04</span>
</p>
<div class="comment-bulk">
<p>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.)</p>

<p>E.g., going forward it will be possible to create file upload controls that work with &lt;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.</p>

</div>
</div>


<div class="comment" id="comment-169554">
<p class="comment-meta" id="c169554">
<span class="comment-meta-author"><strong>Dan Connolly </strong></span>
<span class="comment-meta-date"><a href="#c169554">#</a> 2008-12-05</span>
</p>
<div class="comment-bulk">
<p>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.</p>

<p>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>

<p>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.</p>

</div>
</div>


<div class="comment" id="comment-173101">
<p class="comment-meta" id="c173101">
<span class="comment-meta-author"><strong>Anne van Kesteren </strong></span>
<span class="comment-meta-date"><a href="#c173101">#</a> 2009-02-06</span>
</p>
<div class="comment-bulk">
<p>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.</p>

</div>
</div>


  <div class="comments-open" id="comments-open">
<h3 class="comments-open-header">Leave a comment</h3>

<div class="comments-open-moderated">
   <p>
   Note: this blog is intended to foster <strong>polite
   on-topic discussions</strong>. Comments failing these
   requirements and spam will not get published. Please,
   enter your real name and email address. Every
   individual comment is reviewed by the W3C staff.
   This may take some time, thank you for your patience.
   </p>
   <p>
   You can use the following HTML markup (a href, b, i,
   br/, p, strong, em, ul, ol, li, blockquote, pre)
   and/or <a href="http://daringfireball.net/projects/markdown/syntax">Markdown syntax</a>.</p>
</div>

<div id="comments-open-data">
<form method="post" action="http://www.w3.org/QA/sununga/beach.pl" id="comments-form">
<h4>Your comment</h4>
<div id="comments-open-text">
  <textarea id="comment-text" name="text" rows="20" cols="100"></textarea><br />
<label for="comment-text">Write your comment text here. Remember, keep the discussion on topic and courteous.</label>
</div>

<h4>About you</h4>
<div id="comment-form-name">
  <input type="hidden" name="static" value="1" />
<input type="hidden" name="entry_id" value="595" />
<input type="hidden" name="__lang" value="en" />
<label for="comment-author">Your Name</label>
<input id="comment-author" name="author" size="30" value="" />
</div>
<div id="comment-form-email">
<label for="comment-email">Your Email Address</label>
<input id="comment-email" name="email" size="30" value="" />
</div>

<div id="comments-open-footer">
<input type="submit" accesskey="s" name="post" id="comment-submit" value="Submit" />

</div>
</form>
</div>
</div>


<p id="gentime">This page was last generated on $Date: 2011/12/16 03:03:12 $</p>

      </div><!-- End of "main" DIV. -->

<address>

This blog is written by W3C staff and working group participants,<br />
&nbsp;and maintained by <a href="/People/CMercier/">Coralie Mercier</a>.<br />
Authorized parties may <a href="/QA/new">log in</a> to create a new entry.<br/>
<span id="poweredby">Powered by Movable Type, magpierss and a lot of Web Technology</span>
    </address>


    <p class="copyright">
      <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &copy; 1994-2011
      <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a>&reg;
      (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>,
      <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
      <a href="http://www.keio.ac.jp/">Keio</a>),
      All Rights Reserved.
      W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
      <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
      <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
      and <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a>
      rules apply. Your interactions with this site are in accordance
      with our <a href="http://www.w3.org/Consortium/Legal/privacy-statement#Public">public</a> and
      <a href="http://www.w3.org/Consortium/Legal/privacy-statement#Members">Member</a> privacy
      statements.
    </p>

  </body>
</html>