W3C home > Mailing lists > Public > www-tag@w3.org > May 2006

Re: [metadataInURI-31] New editors draft for Metadata In URIs Finding

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 15 May 2006 21:27:37 -0400
To: Dan Connolly <connolly@w3.org>
Cc: Stuart Williams <skw@hp.com>, www-tag@w3.org
Message-ID: <OFAEA4ACAD.D1503A20-ON85257170.000540BA-85257170.00081C15@lotus.com>

Dan Connolly wrote:

> Regarding...
> | HTML forms [HTMLForms] and now XForms [XFORMS] each provide a means by
> | which a authority can assert its support for a class of parameterized
> | URIs, while simultaneously programming Web clients to prompt for the 
> | necessary parameters.
> You might note that the action= attribute allows a form to point
> anywhere in the web, so in fact, HTML forms allows anyone,
> not just an authority, to make claims about the URI structure
> of http://example.org/cityweather .

Yes, interesting. 

> That introduces a 3rd party into the discussion. That might
> be more trouble than it's worth. Hmm.

Well, the subtlety seems to me that the claims are authoritative (in the 
sense the finding discusses) only if the authority sourcing the form and 
the authority for the ACTION URI are the same.  It's cool that I can serve 
up lots of Web forms with ACTIONs pointing to danconnolly.com, but I 
expect you shouldn't be held responsible for either the implied structure 
of your URIs, or for anything I might say about them in the natural 
language text of the form.  I'm thinking it might be worth a sentence in 
the finding to give that warning, I.e. that 3rd party claims in forms have 
the same standing or lack thereof as 3rd party claims in books, ordinary 
web pages, or on the sides of busses: trust claims that (appear to be) 
made by someone other than the resource authority only at your own risk. 

> I think the "Hiding metadata for security reasons" story
> is a little thin. It's in the right direction, but there
> are more credible threats than a "malicious worker at
> an Internet Service Provider" these days.
> Does anybody have a cross-site scripting horror story
> or something that's not too hard to follow?

Suggestions are most welcome. 

FWIW: I am fairly sure I know of a security consultant who discovered 
exactly the problem in the finding in the early days of the Web.  He 
basically went to the bank or credit card company (not sure which):  "Your 
site's not secure"; "Yes it is"; "Well I have account information for a 
few of your customers and can show you how to get more"; "Ooops - how'd 
you do it?".

The person who discovered the problem found that the URI for his account 
record was along the lines of:


seems that 

  &     http://notsogoodbank.com/accountdata/customer="142"

produced useful information about other accounts.  I'm remembering that 
from many years ago and have no documentation, but I believe the essence 
of the story is right.  So this stuff happens, or used to happen anyway. 
If anyone has more compelling ideas for the security story, that would be 
great.  Frankly, I was afraid the finding was getting too long, but if you 
still had patience for more, maybe others would feel the same.  I'm 
certainly willing to add more if we can figure out what we want there.


Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Tuesday, 16 May 2006 01:27:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:12 UTC