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

Hi,

I think that Kevin is correct that this is a new type of attack not 
discussed before, although I think it's misleading to call it an XSS attack.

I have opened a BugZilla issue for it 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=237>). Once we 
have consensus that this is a real problem, we need to discuss what to 
say in the Security Considerations section.

Best regards, Julian



Kevin Wiggen wrote:
> 
> 
> 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
> 
> 
> 
> 


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 21 March 2006 17:39:38 UTC