On 04/03/2017 02:16 AM, Warren Young wrote: > On Apr 2, 2017, at 9:28 PM, Eduard <eduard.c.dumitre...@gmail.com> wrote: >> >> An attacker can place malicious javascript at the top of every page > > Certainly. > >> they could, for example, change the victim's password > > Doesn’t the login cookie prevent the hosted user from doing that to any but > their own repository, at least through normal HTTP URLs? (As you say, TH1 > and SQL may well be a different matter.) > > Setup privilege isn’t given to all users of a repository, only to the most > trusted administrator(s) of that repository. > > Unless Fossil erroneously lets you log into repo A and then have the same > privileges on repo B hosted by the same Fossil server, I don’t see the > problem. Any wounds would be self-inflicted.
Not true. Suppose that good-user registers "https://example.com/f/goodproject"; and evil-user registers "https://example.com/f/evilproject"; (both have setup privileges on their respective repositories but don't trust each other). Good-user spends most of their time logged into goodproject. Evil-user then convinces good-user to visit evilproject while logged into goodproject; javascript on evilproject (running on good-user's browser instance) can make queries to and receive results for all pages on https://example.com/ (according to same-origin policy), including goodproject; it of course also has access to all of the good-user's cookies. That JS code can do anything that good-user can do on https://example.com/. The usage scenario to consider here is that of a large repository host (like github/sourceforge) which doesn't trust its users (since anyone with an email address can register an account). >> (Another way to fix it is by giving each repository a separate subdomain > > Since ChiselApp is using HTTPS, they must be using some kind of front-end > proxy, which could redirect each repo URL to a different Fossil instance. > That in turn could be run as a chroot or jail, which would mitigate most of > the problems you bring up, if not all. > > It’s not hard. I do this on for my own public repositories. > > It does mean you’re limited in the number of Fossil instances you can run on > a single server by RAM and private TCP port numbers, but I shouldn’t think > you’d want more than a few tens of thousands of Fossil instances on a single > machine anyway. Sorry, by "it" in "Another way to fix it" I meant the XSS vulnerability. Best, Eduard _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
