- From: Kevin Wiggen <kwiggen@xythos.com>
- Date: Wed, 1 Mar 2006 18:05:10 -0800
- To: <w3c-dist-auth@w3.org>
- Message-ID: <03E7D3E231BB7B4A915A6581D4296CC602062E14@NSNOVPS00411.nacio.xythos.com>
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.
Received on Thursday, 2 March 2006 02:05:13 UTC