Re: [LimeBits 172] Displaying untrusted content

[Jonathan A. Marshall]

Subject:	Re: [LimeBits 172] Re: Displaying untrusted content
Date:	Wed, 11 Mar 2009 02:00:00 -0700
From:	Dean Brettle <de...@brettle.com>
To:	jmar...@limebits.com

Hi Jonathan,

[I'm replying off-list because this message discusses potential limebits security vulnerabilities.  If you'd rather continue the conversation on the list, feel free to repost this there.  I'm not sure what your policy for vulnerability reports is so I'm playing it safe...]

On Mon, Mar 9, 2009 at 8:00 AM, Jonathan A. Marshall <jmar...@limebits.com> wrote:

Thanks, Dean.  LimeBits is a platform for developing, hosting, and sharing full-functioning javascript.  We try to avoid impairing or subsetting javascript.

That is admirable and understandable, but I think you need more safeguards than you currently have and I think it is possible to achieve those safeguards without sacrificing functionality.
 

Our notion of a sandbox is a subdomain isolated from the user's sensitive information (plus some other protections).  Because the subdomain is isolated, scripts running in (a page loaded from) that same subdomain are not dangerous.

They are not dangerous to other subdomains, but they are dangerous to the subdomain in which they run, to the degree that the user running them has permissions in that subdomain.  The simplest example is an attacker adding script to my scrapbook page.  When I view the scrapbook, the attacker's script can do anything that I can do, including deleting my entire site.  You could argue that the scrapbook app should remove the script before rendering the untrusted content, but there is more nefarious problem.  What if instead of adding the script to my scrapbook, the attacker adds the following text comment to my blog?

<script src="/!lime/root/library/limebits/latest/axis/AXIS.js" type="text/javascript" charset="utf-8"></script>
<script type="text/javascript">
AXIS.onWindowLoad(function() { AXIS.WebDAV.PUT({url: '/index.html', content: 'Got ya!'}); });
</script>

The blog module treats it as text, so when viewing the blog everything would be fine -- I'd just see the above source.  However,
I can easily be tricked into rendering the untrusted content as HTML.  The attacker just needs to get my browser to load the URL where his comment is stored.  An URL something like:

http://brettle.limebits.com/webdablog/data/data/7e236cd4-c3b2-4823-a9a1-914a431accd5/1236752179796

He could do that by getting me to click an innocent looking link or getting me to visit a page where he has placed an invisible iframe that loads the URL automatically.  That's a very small amount of social engineering to do some very major damage.

In short, we have a module that doesn't render untrusted HTML, but because it uses WebDAV to store untrusted content, there is a vulnerability.  I think this vulnerability can be fixed by changing the Content-Type that the server uses when serving untrusted resources.  That should prevent browsers from rendering the untrusted HTML and executing the script, while still allowing module scripts to access the untrusted content and sanitize it before adding it to the DOM.

NeatHtml might be of interest to developers using the LimeBits platform, if their sites display untrusted content.  But NeatHtml requires server-side processing, which LimeBits does not now support.

Actually, the only reason that NeatHtml needs server-side processing is to delimit the untrusted content in a page and to ensure that users without javascript can see the content.  If the untrusted content is already separated by being a separate resource and javascript is already required (as with limebits), no server-side processing would be needed.  NeatHtml's FilterTagSoupToXml() javascript method takes an untrusted string and returns sanitized well-formed XHTML.  Currently FilterTagSoupToXml() isn't publicly exposed, but that would be extremely easy to change.

--Dean

[Jonathan A. Marshall]

Subject:	Re: [LimeBits 172] Re: Displaying untrusted content

Date:	Tue, 17 Mar 2009 19:36:00 -0400
From:	Jonathan A. Marshall <jmar...@limebits.com>
To:	Dean Brettle <de...@brettle.com>

Thanks, Dean.  I appreciate your input and insights.

We're trying to be as open as possible, so I'm CC'ing the LimeBits forum.

> They are not dangerous to other subdomains, but they are dangerous to the subdomain in which they run

Correct.  The key is to have multiple subdomains, so that mischief in one doesn't hurt another.  For example, if I copy code into newapp.jam.limebits.com and load it from that subdomain, LimeBits sandboxing will isolate it from www.jam.limebits.com.

Later, if I decide that I trust the code (after suitable examination), I can load it as www.jam.limebits.com/newapp -- which confers access to the contents of that subdomain.

We are working on the sandboxing and hope to finish it in a few months.

> I think this vulnerability can be fixed by changing the Content-Type that the server uses when serving untrusted resources.

Great idea.  We'll discuss implementing that.

> If the untrusted content is already separated by being a separate resource and javascript is already required (as with limebits), no server-side processing would be needed.  NeatHtml's FilterTagSoupToXml() javascript method takes an untrusted string and returns sanitized well-formed XHTML.  Currently FilterTagSoupToXml() isn't publicly exposed, but that would be extremely easy to change.

OK, then this is definitely useful for apps that want to sanitize yet still allow some code in the input.  If the developer doesn't want simply to escape all code trigger characters (like converting < and > to &lt; and &gt;) then FilterTagSoupToXml() would be handy.

Can you explain more about the use cases where FilterTagSoupToXml() would be preferred over a simpler escape conversion?

Best wishes,
--Jonathan

Dean Brettle wrote:

Hi Jonathan,

[I'm replying off-list because this message discusses potential limebits security vulnerabilities.  If you'd rather continue the conversation on the list, feel free to repost this there.  I'm not sure what your policy for vulnerability reports is so I'm playing it safe...]

[Jonathan A. Marshall]

Subject:	Re: [LimeBits 172] Re: Displaying untrusted content

Date:	Fri, 20 Mar 2009 16:32:36 -0700
From:	Dean Brettle <de...@brettle.com>
To:	Jonathan A. Marshall <jmar...@limebits.com>

[Looks like you forgot to cc the forum. I'm continuing in private because you might want to avoid disclosure until at least the "comments" vulnerability is fixed by serving untrusted content with a different content type.]

Regarding sandboxing modules in subdomains until the site developer trusts them, I think that is a nice feature but isn't critical.  I run all sorts of open source software on my computer without personally examining it first.  I trust it because it is open source and I trust the distributor, the developers, or others who have recommended it.  Similarly, I'd find some sort of rating system or developer reputation/identification system for LimeBits more useful than sandboxing modules in subdomains. 

I'm far more concerned about XSS attacks in untrusted content.  LimeBits javascript+WebDAV architecture makes it especially vulnerable because all untrusted content must be available via an URL in the domain of the app that will use it.  So I urge you to fix that (e.g. by changing the content-type) as quickly as you can.

As for use cases for FilterTagSoupToXml(), they are exactly what you describe -- any situation where the user would like to add rich content instead of plain text.  This could be in blog comments, forum posts, reviews, scrapbooks, wiki-style systems, etc.  I haven't looked at the LimeBits API in any detail but it might be useful to provide methods for retrieving untrusted HTML and untrusted plain text.  The former could sanitize it using something like FilterTagSoupToXml() and the latter could sanitize by HTML-encoding the special chars.

--Dean

On Mar 17, 2009 4:36 PM, "Jonathan A. Marshall" <jmar...@limebits.com> wrote:

Thanks, Dean.  I appreciate your input and insights.

We're trying to be as open as possible, so I'm CC'ing the LimeBits forum.

> > They are not dangerous to other subdomains, but they are dangerous to the subdomain in which t...

Correct.  The key is to have multiple subdomains, so that mischief in one doesn't hurt another.  For example, if I copy code into newapp.jam.limebits.com and load it from that subdomain, LimeBits sandboxing will isolate it from www.jam.limebits.com.

Later, if I decide that I trust the code (after suitable examination), I can load it as www.jam.limebits.com/newapp -- which confers access to the contents of that subdomain.

We are working on the sandboxing and hope to finish it in a few months.

> > I think this vulnerability can be fixed by changing the Content-Type that the server uses when...

Great idea.  We'll discuss implementing that.

> > If the untrusted content is already separated by being a separate resource and javascript is a...

OK, then this is definitely useful for apps that want to sanitize yet still allow some code in the input.  If the developer doesn't want simply to escape all code trigger characters (like converting < and > to &lt; and &gt;) then FilterTagSoupToXml() would be handy.

Can you explain more about the use cases where FilterTagSoupToXml() would be preferred over a simpler escape conversion?

Best wishes,
--Jonathan

Dean Brettle wrote:

> > Hi Jonathan, > > [I'm replying off-list because this message discusses potential limebits secur...

On Mon, Mar 9, 2009 at 8:00 AM, Jonathan A. Marshall wrote:

>> >> Thanks, Dean.  LimeBits is a platform for developing, hosting, and sharing full-functioning j...

[Jonathan A. Marshall]

Hi Dean,

I'm following up on your helpful emails from March.   You've made some interesting and valid points, which we take to heart.

We've just decided on a sandboxing model and will start implementing it shortly.  The basic idea is to use the browsers' same-origin policy to isolate (sub-)*domains from one another, as I described earlier in this thread.  Details to follow.

We understand that sandboxing of JavaScript/web code is not a complete answer to security questions, but we believe it will help.  Further enhancements for security will be added to LimeBits in the future.

We invite and welcome more questions on displaying untrusted content.

Thanks again and best wishes,