headers
Mark Baker | 8 Mar 2005 22:13
Picon
Favicon
Gravatar

WHAT-WG <at> WWW2005 DevDay?

Hello WHATers,

As co-chair of Developer's Day at WWW2005 (in Tokyo), I'd like to extend
a personal invitation to you to please consider giving a talk (or two)
there in May.

An unofficial "theme" that's emerged in at least two of the tracks that
are under-consideration is the whole "Evolution vs. Revolution" thing.
Revolution will be well represented there, of course, in the form of
RDF, XForms, etc.., but proposed tracks on microformats[1] and "Web
apps" should provide a nice evolutionary counterpoint to them.

I'd consider it *extremely* unfortunate if we couldn't have somebody
there to talk about Web Forms 2.0.

For the submission details, check the CFP[2].

Thanks.

 [1] http://ifindkarma.typepad.com/relax/2004/12/microformats.html
 [2] http://www2005.org/dday/cfp.html

Mark.
--

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Permalink | Reply | 0 comments |
headers
Chris Holland | 8 Mar 2005 23:21
Picon
Gravatar

ContextAgnosticXmlHttpRequest: an informal RFC

Note to moderators: please discard the duplicate of this email
awaiting moderation. I had sent it before joining the list. Sorry
about that :)

Hi all :)

I was hoping some of you might be able to give me some feedback on an
informal RFC i put together on my blog:

http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html

I'm basically looking to enable some sort of cross-host *and*
cross-domain interoperability between documents via a modified clone
of the XmlHttpRequest object, while attempting to tread very carefully
on various security issues, such as Cookies and Basic-Auth
credentials. A "ContextAgnosticXmlHttpRequest" would be a new object
developers could use, beyond the traditional XmlHttpRequest.

i'm not crazy about the ContextAgnostic* prefix ... but that's all i
could come-up with so-far.
It would obviously have a very very limited use and would absolutely
not negate the usefulness of an XmlHttpRequest.

I would look to use such object with non-transactional RESTful services/APIs

thank you for your time :)

--
Chris Holland
http://chrisholland.blogspot.com/
(Continue reading)

Permalink | Reply | 30 comments |
headers
Ian Hickson | 9 Mar 2005 01:30
Picon

Re: ContextAgnosticXmlHttpRequest: an informal RFC

On Tue, 8 Mar 2005, Chris Holland wrote:
> 
> http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html
> 
> I'm basically looking to enable some sort of cross-host *and* 
> cross-domain interoperability between documents via a modified clone of 
> the XmlHttpRequest object, while attempting to tread very carefully on 
> various security issues, such as Cookies and Basic-Auth credentials. A 
> "ContextAgnosticXmlHttpRequest" would be a new object developers could 
> use, beyond the traditional XmlHttpRequest.

One security problem with the above suggestion is that if you have a 
scenario where host H is accessed by a user U which is behind a corporate 
firewall, and behind that firewall are otherwise unprotected servers 
hosting sensitive information, you just gave hostile host H access to all 
that sensitive data.

The only real solution I can see is to have the remote server somehow opt 
in to being able to serve pages from any other site. I've been brain- 
storming possible ways to allow this kind of thing in:

   http://whatwg.org/specs/web-apps/current-work/#network

...but nothing currently there should be considered even remotely finished 
yet (or even representative of what I'm currently thinking, it's really 
just a scratchpad).

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Chris Holland | 9 Mar 2005 02:13
Picon
Gravatar

Re: ContextAgnosticXmlHttpRequest: an informal RFC

Thanks for your reply Ian :)

... interesting points: if i understand correctly, such exploit would
require a foreign malicious web page to know the precise URL of an
HTTP/XML service serving sensitive data behind a firewall. Since the
client lives behind the firewall, it'll be able initiate requests to
both foreign and local hosts transparently, resulting in potential
<strike>"undesirable"</strike>dreadful cross-pollination of data into
the foreign document.

Keeping in mind that, in my specification, no cookies or basic auth
credentials would ever be sent as part of a
ContextAgnosticXmlHttpRequest. But it does still open the doors to
unsecured, non-authenticated sensitive data on intranets, and would
put network administrators in the undesirable position where "A
firewall just isn't enough anymore".

eek. yeah. not good. crap. :( i knew i was missing something big! heh
:) ... BUT ...

Another feature I had mentioned was for the User Agent to send an HTTP
Refer(r)er header with absolute integrity. The value, in our specific
case, being the URI of our evil foreign document. A publisher of an
HTTP/XML service, to truly secure it and restrict it to local access,
might restrict Referrer values to specific host patterns.

Could we also further protect this special object by thoroughly:

1) restricting the mime-type it'll accept from the service to text/xml
2) ensuring its validity as a pure parsable XML document
(Continue reading)

Permalink | Reply | 9 comments |
headers
Ian Hickson | 9 Mar 2005 03:06
Picon

Re: ContextAgnosticXmlHttpRequest: an informal RFC

On Tue, 8 Mar 2005, Chris Holland wrote:
> 
> Another feature I had mentioned was for the User Agent to send an HTTP 
> Refer(r)er header with absolute integrity. The value, in our specific 
> case, being the URI of our evil foreign document. A publisher of an 
> HTTP/XML service, to truly secure it and restrict it to local access, 
> might restrict Referrer values to specific host patterns.

Intranet content could just be a Web page, not an HTTP/XML service. 
There's no way to tell the difference remotely.

Existing sensitive content, including existing HTTP/XML services, are not 
protecting themselves using referrer tracking. Thus, requiring referrer 
tracking doesn't solve the problem.

In any case they couldn't if they wanted to, as the referrer could be 
anything -- for example, it could be a hotmail.msn.com referrer if an 
employee is chatting to another employee using his hotmail account and 
follows a link from such a mail to the other employee's (confidential) 
documents inside the intranet.

> Could we also further protect this special object by thoroughly:
> 
> 1) restricting the mime-type it'll accept from the service to text/xml

Web pages, which are part of the content at risk, can be XHTML. One of the 
correct MIME types for XHTML is text/xml.

> 2) ensuring its validity as a pure parsable XML document
(Continue reading)

Permalink | Reply | 8 comments |
headers
Chris Holland | 9 Mar 2005 04:09
Picon
Gravatar

Re: ContextAgnosticXmlHttpRequest: an informal RFC

> In any case they couldn't if they wanted to, as the referrer could be
> anything -- for example, it could be a hotmail.msn.com referrer if an
> employee is chatting to another employee using his hotmail account and
> follows a link from such a mail to the other employee's (confidential)
> documents inside the intranet.

Well, the value of the Referrer header i'm talking about in this case,
would always be the URI of the document originating the
ContextAgnosticXmlHttpRequest, NOT the *document*'s referrer. Based on
this requirement, i should be able to rely on this header to protect
my service. But I agree that existing firewalled syndication services
without referrer-checking in place would still be vulnerable, and we'd
be introducing a significant risk.

Point taken about text/xml also being valid XHTML MIME type, woops. 

How about requiring from a service that it sets an extra HTTP header
to offer its content to "foreign" hosts:

X-Allow-Foreign-Host: All | None | .someforeigndomain.com |
.somehost.someforeigndomain.com

Unless this HTTP header is sent as part of the HTTP response, the User
Agent would "crap out" with some generic, obscure "data retrieval
failure" message (per what you mentioned). If eBay suddently wanted to
expose their REST API to ContextAgnosticHttpRequests, they could
enhance their service to send out an additional X-Allow-Foreign-Host
header. Today's intranet XML/HTTP services should still be reasonably
safe, as none of them would be sending this header, therefore all
attempts to load them from foreign documents would obscurely crap out.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jim Ley | 9 Mar 2005 09:57
Picon

Re: ContextAgnosticXmlHttpRequest: an informal RFC

On Tue, 8 Mar 2005 19:09:43 -0800, Chris Holland <frenchy@...> wrote:
> Well, the value of the Referrer header i'm talking about in this case,
> would always be the URI of the document originating the
> ContextAgnosticXmlHttpRequest, NOT the *document*'s referrer. Based on
> this requirement, i should be able to rely on this header to protect
> my service. 

How do you know it's not just some random client with a refererrer
that happens to meet your idea of accurate.  Even if implementors of
your version of the object were religiously accurate in following this
rule, no other HTTP implementation need do it.

> How about requiring from a service that it sets an extra HTTP header
> to offer its content to "foreign" hosts:
> 
> X-Allow-Foreign-Host: All | None | .someforeigndomain.com |
> .somehost.someforeigndomain.com

This is a much better proposal than the stealing of URI's in my domain
to mean some special thing.  We're already plagued by the Favicon bugs
in FireFox hammering our servers with requests for documents we never
defined

> all this, i believe, tends to bleed into your own idea of establishing
> some sort of trust relationship. To that end, I need to spend more
> time  grokking 11.4 from your document. I think I'm getting there.

11.4 isn't particularly relevant surely?  That's about Cross-document,
so both documents would need to exist on the client before any
communication could occur.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Chris Holland | 9 Mar 2005 10:31
Picon
Gravatar

Re: ContextAgnosticXmlHttpRequest: an informal RFC

On Wed, 9 Mar 2005 08:57:12 +0000, Jim Ley <jim.ley@...> wrote:
> On Tue, 8 Mar 2005 19:09:43 -0800, Chris Holland <frenchy@...> wrote:
> > Well, the value of the Referrer header i'm talking about in this case,
> > would always be the URI of the document originating the
> > ContextAgnosticXmlHttpRequest, NOT the *document*'s referrer. Based on
> > this requirement, i should be able to rely on this header to protect
> > my service.
> 
> How do you know it's not just some random client with a refererrer
> that happens to meet your idea of accurate.  Even if implementors of
> your version of the object were religiously accurate in following this
> rule, no other HTTP implementation need do it.
> 

well this is part of a much broader issue. If you offer an HTTP
service, any piece of software out there is free to abuse it. An
end-user has to first install said piece of software and run it. What
we're talking about here is a malicious web *document* gaining access
to data from a foreign host. If the User Agent is a traditional web
browser, the only way a given document could ever initiate a request
to a host different from the one that served it, would be through a
ContextAgnosticHttpRequest (i'm liking this name less and less, sorry
about that), and this request would infallibly send, in every request,
the full URI of the document initiating the request, as the value of
the "Referer" header.

I'm agreeing with the both of you that this isn't likely to be a good
solution to the whole permission issue as it would require providers
of existing services that live behind firewalls to protect themselves
to not be vulnerable should such a feature ever roll out into
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jim Ley | 9 Mar 2005 13:14
Picon

Re: ContextAgnosticXmlHttpRequest: an informal RFC

On Wed, 9 Mar 2005 01:31:50 -0800, Chris Holland <frenchy@...> wrote:
> On Wed, 9 Mar 2005 08:57:12 +0000, Jim Ley <jim.ley@...> wrote:
>If the User Agent is a traditional web
> browser, the only way a given document could ever initiate a request
> to a host different from the one that served it, would be through a
> ContextAgnosticHttpRequest (i'm liking this name less and less, sorry
> about that), and this request would infallibly send, in every request,
> the full URI of the document initiating the request, as the value of
> the "Referer" header.

Are you sure you're not advocating this to get around privacy based
proxies of the type that normally disable such referrer based content
so as to reliably block
privacy invasions?

> > Please don't have any solution that limits the user to XML, it's a
> > pointless arbritrary restriction that offers nothing but serious
> > performance hits to the client, and complications to the user.
> 
> well it would appear XML validity already is a restriction, but okee.

Nope, there's no such restriction, and very few of the implementations
that I know of that use xmlhttprequest on websites use XML.

Jim.
Permalink | Reply | 3 comments |
headers
Chris Holland | 9 Mar 2005 17:42
Picon
Gravatar

Re: ContextAgnosticXmlHttpRequest: an informal RFC

On Wed, 9 Mar 2005 12:14:52 +0000, Jim Ley <jim.ley@...> wrote:
> On Wed, 9 Mar 2005 01:31:50 -0800, Chris Holland <frenchy@...> wrote:
> > On Wed, 9 Mar 2005 08:57:12 +0000, Jim Ley <jim.ley@...> wrote:
> >If the User Agent is a traditional web
> > browser, the only way a given document could ever initiate a request
> > to a host different from the one that served it, would be through a
> > ContextAgnosticHttpRequest (i'm liking this name less and less, sorry
> > about that), and this request would infallibly send, in every request,
> > the full URI of the document initiating the request, as the value of
> > the "Referer" header.
> 
> Are you sure you're not advocating this to get around privacy based
> proxies of the type that normally disable such referrer based content
> so as to reliably block
> privacy invasions?
> 

well, if a proxy starts filtering out http headers sent by the client,
there isn't much we can do about that now is there. heh.

> > > Please don't have any solution that limits the user to XML, it's a
> > > pointless arbritrary restriction that offers nothing but serious
> > > performance hits to the client, and complications to the user.
> >
> > well it would appear XML validity already is a restriction, but okee.
> 
> Nope, there's no such restriction, and very few of the implementations
> that I know of that use xmlhttprequest on websites use XML.
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane