Re: UniMsg: editorial

Hi Dan,

Thank you for reviewing the Uniform Messaging document. I very much
like your suggested editorial changes and will incorporate them in the
next draft we send out. Answers to your questions are inline below...

On Mon, Dec 7, 2009 at 9:40 AM, Dan Connolly <connolly@w3.org> wrote:
> Also, re "virtue of being the same subset supported by the HTML form
> element"; that's not derived from HTML specs, is it? That's just well-known
> lore about how HTML is implemented? A citation would be nifty, though I can
> imagine there isn't a good one.

With one exception, I believe all the behavior we rely upon is
documented by HTML 4.01. The one exception is that the HTML form
element supports setting the Content-Type of a POST to "text/plain".

The HTML 4.01 spec says: "User agents must support the content types
listed below. Behavior for other content types is unspecified.", where
only "application/x-www-form-urlencoded" and "multipart/form-data"
were listed. Somehow, "text/plain" was added to this list and then an
assumption was made that no other Content-Type was allowed. I don't
know of a good citation for this oral tradition, but defacto security
policy.

> I don't grok "If the permissions needed for a POST are provided in response
> to a GET, ..." . Help?

A common CSRF defense is to include an unguessable secret in a POST
request. A GET request fetches an HTML form that is pre-populated with
the secret token. This secret token represents permission to submit
the POST request. This CSRF-defense depends upon the Same Origin
Policy to prevent an attacker from reading the response to a GET
request, and so acquiring permission to submit a POST request.

In clickjacking, the attacker avoids the need to read the GET
response, and simply allows the contained HTML form to be rendered.
Various techniques can then be used to cause the user to click on the
legitimate HTML form, without realizing the significance of the
action. In some cases, there are no visible clues that a form from
another origin is being "displayed" and submitted. To prevent this
attack, the GET request that sets up the POST request must perform
additional access checks. For example, the URL for the GET request
could itself contain a secret token.

I suspect all of the above is familiar to you and that you were
tripped up by the use of the word "permission", instead of "secret
token" or similar. We've used the word "permission" since a secret
token is not the only way of including an explicit permission in a
HTTP request.

> Also.. "When placing permissions ..." confused me;
> s/permissions/credentials/?

It looks like we need to define the term "permission" in Uniform
Messaging. It is very different from "credential", which typically
means an attribute of the requestor, which is then used in combination
with identifiers in the request to determine whether or not to honour
the request. The latter is the pattern we're trying to avoid by
stripping client context (such as cookies, which are credentials) from
the request. A permission is independent of the requestor. For
example, a secret token that is a permission might have the meaning:
"permission to delete resource foo".

We'll include a good definition of "permission" in the next draft.

Thanks,
--Tyler

Received on Monday, 7 December 2009 20:14:25 UTC