[Tickets #2565] Re: Gecko Bookmarks extension

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=2565
-----------------------------------------------------------------------
 Ticket             | 2565
 Updated By         | Chuck Hagenbuch <chuck at horde.org>
 Summary            | Gecko Bookmarks extension
 Queue              | Trean
 Type               | Enhancement
 State              | Feedback
 Priority           | 2. Medium
 Owners             | 
-----------------------------------------------------------------------


Chuck Hagenbuch <chuck at horde.org> (2007-08-16 13:05) wrote:

> I remembered that the browser is caching the HTTP Basic credentials, 
> which is bad.  I think I can prevent that.  I'm hoping after the 
> first call using Basic auth, the cookie I get will be enough.

Unless we modify jsonrpc to use sessions instead of HTTP auth, that won't
work.

> But I think I see now how it's exploitable.  Couldn't someone 
> automatically submit a FORM with a POST to Horde, and the auth cookie 
> would attach to the request regardless of the domain of the POSTing 
> site?  I guess they may not be able to do much with the response, but 
> just sending is enough to do nasty things.

Right. This is a pretty good explanation:
http://en.wikipedia.org/wiki/Cross-site_request_forgery

> So you're suggesting my extension holds a unique, opaque session key 
> (probably in addition to the cookie I already have) that isn't stored 
> anywhere in the browser proper?

As long as it's not something that is passed when the browser makes a
regular page request, or an xhr request, it'll work.

> Also, is this really specific to JSON-RPC, or is it something that 
> could be a problem with any of the RPC methods?  Because on second 
> thought, I think JSON-RPC requests would be difficult to forge 
> because XHR is probably protected enough, and they can't be done by 
> FORM that I know of, because they aren't sent using the standard URL 
> encoding form.  They use a POST Content-Type of 'application/json' or 
> something, and the body is straight JSON, not wrapped in URL 
> &key=value form.

XHR is protected by cross-domain restrictions; you can do GET requests for
javascript, but jsonrpc (and the other RPC stuff) uses POST.

Other RPC types could be vulnerable if they could be faked by a form
submission. I think you're right that a regular form submit couldn't be
used for jsonrpc (or most of the other RPC types) because you can't create
that data with a regular form. Since the only other way to get the user's
browser to do a POST is with XHR, and that's out of domain, then I think
we're okay here without additional changes and tokens. But it's a good
thing to think through. :)

I want to sit on this another day or so before committing it, though, just
in case.

Thanks!