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

From: "Kevin Wiggen" <[email-masked]>
Date: Wed, 1 Mar 2006 18:05:10 -0800

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. 

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).  

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.

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Mar 2006 09:33:32 +0100

> previously unknown evil collection site.

We currently have 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-14.html#rfc.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.

> and some knowledge of webdav, people can start to “hack” webdav servers 
> 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 
> (notice I don’t say solution) is to have Webdav separate the authoring 
> 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.

> and try to give solutions.

Best regards, Julian