W3C home > Mailing lists > Public > public-appformats@w3.org > November 2007

Re: Design issues for access-control

From: Thomas Roessler <tlr@w3.org>
Date: Mon, 5 Nov 2007 10:22:15 -0500
To: Anne van Kesteren <annevk@opera.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-ID: <20071105152215.GG9549@raktajino.does-not-exist.org>

On 2007-11-05 09:54:53 -0500, Anne van Kesteren wrote:

>> Well, Xforms is built around the notion of submitting data in
>> XML to arbitrary destination URIs, and that spec enables
>> automatic submission (through POST) even without use of
>> Javascript.

> You'd only be vulnerable if you'd have a) XForms support and b)
> it does that. Seems rather theoretical and more a problem of
> XForms.

There are two points here:

1. There is a design decision at least in Xforms to enable
cross-site POST with XML content.

1. You are "vulnerable" to a cross-site POST if your *user* has
xforms support active.  If you deploy a web application (or Web
Service) that is vulnerable to cross-site POST with an XML content
type, you probably have a problem.

Together, these suggest to me that trying to avoid specifically XML
content in unattended cross-site POST requests (if they are caused
by XHR) is an exercise that's not worth the effort.

>>>>> Servers will have to deal with cross-site <form> POST, but
>>>>> probably don't deal with cross-site XMLHttpRequest POST. As such,
>>>>> XMLHttpRequest POST is not guaranteed to be as "safe" as
>>>>> cross-site <form> POST is.

>>>> Please explain the differences from the perspective of the site that
>>>> needs to handle these requests, and explain how they are relevant
>>>> for the discussion at hand.

>>> <form> POST is not relevant to the discussion at hand.
>>> XMLHttpRequest POST follows the model with Method-Check, etc.

>> You're not answering my question.

> I don't understand it then, I suppose.

Key words: "from the perspective of the site that needs to handle
these requests"

>> There is a difference between deploying a web application and
>> deploying a different HTTP stack.

> Well yes, some changes have to be made in order to support this.
> This is not that complicated though with typical server-side
> languages.

We seemed to have a goal to do it all without server changes at some
point.  Seems that has been lost.

Thomas Roessler, W3C  <tlr@w3.org>
Received on Monday, 5 November 2007 15:22:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:08 UTC