[fossil-users] XSS attack and fossil hosting services

[Eduard]

Hi,

I recently realized that fossil repository hosting websites (such as
chiselapp  and hydra
) are vulnerable to arbitrary HTML
injection (XSS) as soon as they give (untrusted) users the 'setup'
capability to the repositories they create. An attacker can place
malicious javascript at the top of every page by supplying a custom
fossil theme; alternatively they could configure the server to serve an
arbitrary html documentation file as the home page. Said malicious
javascript (allowed by same-origin policy) can perform requests and read
their results; they could, for example, change the victim's password
and/or give the attacker maximal privileges on all repositories the
victim has access to.

One way to prevent this would be by creating a cap between 'setup' and
'admin'. This cap would be able to configure all fossil settings that
aren't an XSS risk. In particular, the ability to run arbitrary TH1 and
SQL may also need to be restricted/disallowed (because a user could just
modify the config table using SQL, for example).

For now I'm considering patching fossil itself to prevent users from
modifying dangerous settings (and outright removing the run-SQL/TH1
pages) and by changing the recognized mimetype for html files.

(Another way to fix it is by giving each repository a separate
subdomain, but letsencrypt doesn't do wildcard subdomains and real TLS
certs are expensive.)

As a related and more general question, what damage can a "fossil http
-R $repo" command do to surrounding files/other repositories? In
particular, using TH1/SQL or using the JSON interface?

Best,
Eduard

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] REST API and client for same

[Warren Young]

On Apr 2, 2017, at 2:48 PM, Stephan Beal  wrote:
> 
> a) that's essentially what the JSON API is

…minus the lightweight Subversion-like client, of course.

But, it’s good to know that most of the work is already done.

> with the notable exception of missing blob support (since JSON has no 
> definition for blobs).

When I said that the default return representation should be JSON, I did not 
mean that all data must be in JSON format.  I just mean that, when no better 
representation exists, the API should use JSON.

Contrast the Fossil HTTP API here, where sometimes pulling a specific file 
shows it in the browser as-is, sometimes it displays it inline with other 
material, and sometimes it downloads it.  The Fossil HTTP API knows it’s 
talking to a web browser, and that a human is likely driving that browser, so 
it is trying to present the information in the manner the human most likely 
wants it.

With this REST API, I’d expect to get a file download every time, because the 
server cannot make any assumptions about the nature of the client, particularly 
about the display semantics.  Web applications like Fossil UI often make such 
assumptions.  The REST API would be more policy-free, in this sense.

> b) CGI does not specify certain methods which REST conventionally relies on, 
> most notably PUT.

PUT is nice to have for REST, but not essential.

The typical need for PUT vs POST is to distinguish “insert” from “update” — to 
put it in SQL terms — but that’s just one flavor of REST.  Another flavor 
distinguishes the cases based on whether you give a record ID or not; if not, 
it’s “insert.”

The PUT vs POST idempotency distinction also works in our favor here: it’s 
better that the one verb we get be the one that doesn’t try to guarantee 
idempotency.

> A strictly-REST-compliant API

Who specifies “strict” REST?

All I see are a bunch of cliques and camps, no actual standards.

That said, if some of this didn’t work with CGI, I don’t see a problem with 
that, since it is merely one alternative way to access Fossil, not the main 
one.  If the requirement is that you use “fossil server” with this, that seems 
fine to me.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] REST API and client for same

[Stephan Beal]

On Sun, Apr 2, 2017 at 8:58 PM, Warren Young  wrote:

> In a conversation off-list, I had an idea that might solve several
> existing problems.  What if the current HTTP URL interface of Fossil were
> expanded to be able to do everything that Fossil internally can do, such
> that it eventually implements REST API interface that is functionally
> equivalent to fossil CLI + Fossil UI?
>

Very briefly before bed:

a) that's essentially what the JSON API is, with the notable exception of
missing blob support (since JSON has no definition for blobs).

b) CGI does not specify certain methods which REST conventionally relies
on, most notably PUT. A strictly-REST-compliant API is not, IMO, possible
with fossil unless it is limited to server mode (as opposed to CGI mode).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] REST API and client for same

[Warren Young]

In a conversation off-list, I had an idea that might solve several existing 
problems.  What if the current HTTP URL interface of Fossil were expanded to be 
able to do everything that Fossil internally can do, such that it eventually 
implements REST API interface that is functionally equivalent to fossil CLI + 
Fossil UI?

This REST API should not map 1:1 to the existing interfaces, nor should it 
merely expose Fossil’s internal API 1:1.  It needs to be its own thing, 
designed with the high latency and statelessness of HTTP in mind.  But, it 
should be *functionally* equivalent.

This would have the following benefits:

1. With a curl client or libcurl, you could replace libfossil without the 
duplicate effort.  Imagine what this would do for scripting.

2. Those needing the benefits of a non-distributed VCS (e.g. low checkout time, 
single-checkout footprint size for checkouts, etc.) could use a lightweight 
client written against this REST API instead of the full Fossil experience.  To 
such a user, Fossil would operate more like Subversion.

I propose calling that client frapi, standing for Fossil REST API.  Plus, 
coffee allusions seem to make programmers happy.

3. Since the remote REST client does not need to hold large chunks of the 
Fossil DB in RAM, it would probably take much less RAM.

For example, consider checking out a large BLOB.  Does fossil not currently 
pull that BLOB from the DB into RAM and then write a copy of it back out to 
disk in the checkout directory?  A REST API would allow a streaming mode of 
operation: as bytes come from the remote Fossil instance over HTTP, it can just 
write them straight to disk.

This idea could be implemented piecemeal.  Just as the current HTTP API is 
already useful as-is, the REST API should be built up in an as-needed fashion.

Unlike the HTTP API, the default return type of the REST API should be JSON, 
not HTML.

I have little need for such a thing myself, so I’m just throwing this idea out 
there for anyone who thinks it looks like a good itch to scratch.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users