Data Leak Vulnerability in /wikieedit and /fileedit in 2.12

Edit: updated to tone down the severity, as the problem cannot leak data between multiple users, just edits made across multiple repos by the same user in the same browser profile instance.

In the course of responding to /forumpost/0f56c9edd9 it was, much to my dismay, discovered that we have a serious flaw in the /wikiedit and /fileedit pages in 2.12 which can cause a repo to "leak" edits to other repos being hosted on the "origin" (same domain and port number). The leak only applies to a single browser profile installation, i.e. the same user. Edits made by two users, or across two browsers, will not be visible to each other.

The fix is trivial:

https://fossil-scm.org/fossil/info/5b9a4c90594d8ea6

and simply disables the internal selection of localStorage as a storage option.

If you work with multiple repos on the same origin, please update your 2.12 releases to this version. In parallel, i will work with Richard to get a 2.12.1 out the door ASAP. :( The checkin for that release will be made as soon as this post is submitted (i want to link to this in the commit message).

Note that upgrading to this change will lose any edits currently stashed in localStorage, so if you have any to apply, do so before upgrading.

ChiselApp is not affected - i have it on good authority that they will be upgrading in the coming weeks, but don't yet have 2.12.

Likewise, versions earlier than 2.12 are not affected, as they apply only to features added in 2.12.

Details and Symptoms of the Problem

When /wikiedit and /fileedit believe you have made changes to the page/file you are working on in your browser, they stuff that into the fossil.storage JavaScript API so that you don't lose the edits if you reload the page, your browser crashes, or whatever. fossil.storage, in 2.12, checks for the longest-living storage option of:

1. window.localStorage
2. window.sessionStorage
3. An API-compatible transient in-memory object which is lost when reloading the page.

The fix linked to above simply skips step (1), choosing sessionStorage, if available, which is linked to the tab in question and survives reloads and navigation away from the page, so long as that tab remains open. Thus edits are still persistent, to some degree, but (A) not as persistent as before and (B) they cannot leak outside of that specific tab.

However: sessionData is also affected by this, but less dramatically: only when the user switches to a different repository from the same origin within the same "session" (which is limited to a single browser tab). Two tabs opened at a single origin at the same time, whether it's the same repo or not, do not share this state, so cannot see each other's edits. Closing a tab immediately eliminates the sessionStorage-stored state.

Problem Origin, Facepalm, and Apologies

You have my sincerest apologies for this - it's 100% my fault.

Seriously, this guts me. (Edit: it's not nearly as bad as i initially thought, so...) This is seriously embarrassing. The underlying cause for it is that my understanding of "origin," in the context of localStorage scoping, was fundamentally flawed. The secondary cause was that all test edits on my public test/demo repo were performed on a single repo, so there was no opportunity to witness the cross-repo leaking of the edits in other repos from the same "origin." The line of discussion in the above-mentioned thread brought that into question and, sure enough, a quick multi-repo test on the same server easily reveals that edits do cross repo boundaries via localStorage.

Feature or bug? Yes, but most definitely potentially more of a bug than a feature. (There are contexts where that would indeed be extremely useful, but it was never the intent to share this state across different repo instances.)

Please accept my apologies for this - it was an inexcusable breach.