Hi, I recently realized that fossil repository hosting websites (such as chiselapp <http://chiselapp.com/> and hydra <https://hydra.ecd.space/f/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
