Re: ISSUE 19: Requirements and Usage Scenarios document

On 2008-01-15 10:29:21 -0800, Jon Ferraiolo wrote:

> But wouldn't it be better if the functionality were made
> available without introducing a new attack vector? I would
> suggest that the objective be to satisfy the functionality
> requirements that are dictated by the use cases, and if possible
> choose a technical approach that does not introduce new attack
> vectors.

Let's be precise here.


Browsers can be caused to send a cross-site GET request with the
user's ambient cookies through various existing means (including
these pesky hyperlinks, image tags, scripts, framesets, object tags,
stylesheet links, ...); that ability is a rather fundamental part of
the Web's architecture, and I don't think we want to touch that.

Web applications must not assume that they know what caused such a
request to be sent.  Any such assumption is a serious design flaw in
a web application.  The change in functionality proposed in the
access-control spec is that, if the "access-control" header is set,
scripts from specific additional origins get access to the data
retrieved, with the notable exception of response header and cookie
information.

Note that, as far as GET is concerned, the argument is not one of
horses having bolted, but one about a fundamental design decision on
the Web.

We're not going to forbid cross-origin hyperlinks, are we? ;)


For POST and other side effect bearing HTTP methods, the story looks
different: In this case, the original design includes an assumption
that requests can only be sent upon user action.  That assumption is
invalidated by things like form.submit(), parts of the xforms
design, and any number of plugins.  It's debatable to what extent
the POST horse has bolted or not.

If we assume that not causing additional POST requests is a
requirement that we have, then the current model serves that
requirement: There is an OPTIONS request which asks the service for
permission *before* the POST request is sent.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Wednesday, 16 January 2008 20:02:40 UTC