RE: Comments on the "new" 2518 -- XSS

I believe this is way too weak of language on what the risks are around
Webdav (and HTTP for that matter).  We need to point out to people that
there is a LARGE risk in allowing users to post data to servers because
of the way HTTP and Webdav work.

"The server might not have a close trust relationship with the author
that is publishing the document."  -- Even in corporate, I don't have a
strong trust relationship with every employee...  There are also
numerous servers that are being used by multiple sets of people.  If
someone for ANY reason can PUT information on the server, it is possible
for others to be compromised by that person.  I think we need to spell
this out for people so they understand the risks.  

"Servers that allow clients to publish arbitrary content can usefully
implement precautions to check that content published to the server is
not harmful to other clients. Servers could do this by techniques such
as restricting the types of content that is allowed to be published and
running virus and malware detection software on published content."  --
Again this is a catch 22.  Basically there is a line between usefulness
and security.  People have valid reasons for posting lots of different
content.  How do you know if they are malicious or not?  Also I know of
no virus protection software that flags xmlHTTP() as a virus.  Right now
clicking on index.html in web folders launches my browser which can then
execute code (and since IE shares login info) that will make any type of
Webdav calls to the server using xmlHTTP and my security permissions.
The major problem I believe we need to solve is the relationship between
a GET and HTML.  

"Servers can also mitigate the risk by having appropriate access
restriction and authentication of users that are allowed to publish
content to the server." -- This makes it seem like valid ACL will solve
the problem.  This is not necessarily true.  If you allow me to write to
ANY part of your server, I can trick you into letting me have access to
the rest of it.  I think this language is vague and leads people to
believe things are safe when they are not.  We need to spell out what
the risks are and let people know.

I remember a few years ago when MS had a buffer overflow exploit in
there Webdav server, it took a lot of convincing to prove to people that
it was a problem with the MS server and not the protocol. "Webdav is
insecure" is what people kept saying.  We need to discuss these issues
else Webdav could get a really bad rap (even though most of these
problems also affect HTTP itself).


-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
On Behalf Of Julian Reschke
Sent: Thursday, March 02, 2006 12:34 AM
To: Kevin Wiggen
Cc: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518 -- XSS


Kevin Wiggen wrote:
> Webdav needs to mention (and hopefully help) solve XSS attack
problems.  
> XSS (Cross-Site Scripting) is aimed at inserting active code in an
HTML 
> document to either abuse client-side active scripting holes, or to
send 
> privileged information (e.g. authentication/session cookies) to a 
> previously unknown evil collection site.

We currently have 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-14.html#r
fc.section.20.8>, 
which says:

"HTTP has the ability to host programs which are executed on client 
machines. These programs can take many forms including web scripts, 
executables, plug in modules, and macros in documents. WebDAV does not 
change any of the security concerns around these programs yet often 
WebDAV is used in contexts where a wide range of users can publish 
documents on a server. The server might not have a close trust 
relationship with the author that is publishing the document. Servers 
that allow clients to publish arbitrary content can usefully implement 
precautions to check that content published to the server is not harmful

to other clients. Servers could do this by techniques such as 
restricting the types of content that is allowed to be published and 
running virus and malware detection software on published content. 
Servers can also mitigate the risk by having appropriate access 
restriction and authentication of users that are allowed to publish 
content to the server."

I don't think that saying more would be good. This is a general problem 
*not* specific to WebDAV.

> Webdav to date is content agnostic and allows for clients to retrieve 
> and save information to/from a server.  Unfortunately with Javascript 
> and some knowledge of webdav, people can start to "hack" webdav
servers 
> to do unexpected things.  Imagine I upload (using PUT) a HTML page
that 
> uses a browser xmlHTTP() to send a propfind to the server and then
issue 
> DELETE to everything I could find.  By simply sending you a link to a 
> URL on a common secured server, a browser will ask you to log in and 
> then execute the javascript AS YOU.  There are a lot of problems that 
> smart people can create because the GET and other Webdav methods all 
> originate from the same server.  There are possible solutions (from 
> scraping all input and not allowing certain content) but each always
has 
> some drawbacks (hey I want that javascript to do something important
on 
> my webpage, you can't cut it out when I upload it). 

So do you have any specific proposal about what to do?

> A separate but related issue is the MS "translate" issue.  If someone 
> uploads a jsp to a server, when they request it back, do they want the

> server to give the jsp? Or execute the jsp and return the result? 
> 
> It seems that Webdav (web distributed AUTHORING and versioning) could 
> take some steps to help out both of these areas.  One line of thinking

> (notice I don't say solution) is to have Webdav separate the authoring

> world from the view (or execute world).  In this world there would be 
> two different namespaces (one for Webdav and one for GET/Execute).
The 
> webdav world would tell clients that it is meant for authoring and
thus 
> servers will NOT execute things like jsps and clients should NOT
render 
> and execute these objects (like javascript in HTML) in things like 
> browsers but rather a edit mode (like HTML editor).  In this way, 
> Javascript should not be executed by HTML Editors and the namespace
will 
> be protected from malicious code stored in the sheep's clothing of
HTML.

That's basically the question the DAV:source property was supposed to 
solve. It has been removed from the spec due to a complete lack of 
implementation experience.

It's an interesting and important topic, but it was impossible to solve 
within the time that has been allocated to us.

> Again I believe it important for Webdav to speak about these problems 
> and try to give solutions.
> 

Best regards, Julian

Received on Friday, 3 March 2006 23:31:49 UTC