Hi Dyllon We actually have the same issue with the GitHub saver module: it saves the access token to local storage, which is subject to the same peculiarity of all file: URIs counting as a single origin. Thus, if an attacker can induce a user to download an HTML file and open it in the browser then they can exfiltrate all the access tokens.
I think Google’s answer would be “don’t use file URIs to manage sensitive data”, but it makes me sad that there’s so much erosion of the users power to manage their own data locally. I think the alternative is to run TiddlyWiki as a PWA, but that would subject us to browser compatibility issues, and give end users a much more obscure mental model. Best wishes Jeremy > On 27 Apr 2021, at 23:54, Dyllon Gagnier <[email protected]> wrote: > > @mohammad.rahmani the security issue is actually relevant to TiddlyWiki even > if the file itself is secured. > > Google decided this was a duplicate issue so I can disclose the issue in > full. 1202597 - Security: File Access API Permission Bypass - chromium > <https://bugs.chromium.org/p/chromium/issues/detail?id=1202597#c3> > > You can save file/directory handles to IndexedDB (like localStorage, but more > confusing) so that you don't need to select the TiddlyWiki > file from the file picker each time you refresh the tab/open it. However, > Chromium has a bug/design which considers everything from file:// > to be from the same origin/domain. This means if you download and double > click on some "malicious.html" it could just scan IndexedDB > and use the same descriptors TiddlyWiki saved for convenience. > > Here is a potential outline of this attack: > You save teaminfo.html to a shared drive which includes passwords/valuable > docs/etc. > You are writing some Rust code and have the docs open (which the rustdoc tool > conveniently generates for you locally). > Someone, NSA/Russia/whoever, compromised some libraries docs and inserted > malicious JS. > This malicious code gets the file descriptor by scanning IndexedDB and > uploads it to some remote location. > If you happen to have said wiki open in another tab (as I personally often > do), it can also overwrite this file and then be ransomware. > How to avoid this: > Do not save file descriptors to IndexedDB > The code I posted doesn't save to IndexedDB, so this is for people modifying > the code. > I am working on a proper plugin for this and my plan is to only save > descriptors if not served from file://. > Use a static server like "pythom -m http.server" > Firefox doesn't support this API yet, but they seem to be more strict with > same origin than Chromium. > Wait for Chromium to actually fix this issue and enforce a better origin > policy for IndexedDB. > > On Mon, Apr 26, 2021 at 8:26 PM Mohammad Rahmani <[email protected] > <mailto:[email protected]>> wrote: > > > On Mon, Apr 26, 2021 at 11:58 PM Dyllon Gagnier <[email protected] > <mailto:[email protected]>> wrote: > I would caution on being too hasty with this. There are some serious security > implications with opening wikis hosted on the file system (i.e. file://, not > talking about local servers or TiddlyDesktop). > > Apparently permissions are shared pretty broadly for anything open on > file://. The code I shared is probably ok, but I have reported one issue to > the Chromium team that I would like to hear > their feedback on since it has some potential security implications for > TiddlyWiki. I know there are people who store very valuable data on their > wikis which is why I want to put a big caveat > on all this. > > Even with my current concerns, I believe that the API is very safe so long as > you serve the wiki from a local server (any local server, doesn't need to be > TiddlyWiki specific). For example, > launching a web server in a directory with the wiki via "python3 -m > http.server". There is less of a benefit over the tiddlywiki node server, but > I do think there is still a benefit. Since there > is almost no coupling between the server and TiddlyWiki, you can debug things > entirely in the browser and synchronization of state is easier to think > about. There is only the state on disk > and the state of the browser tab, no hidden state/watch issues with the web > server. > > I think expanding the code to support wiki folders would be great and would > help solve some of the issues around having images embedded in portable wikis. > > I am planning on releasing this as an actual plugin, but in addition to > security and versioning, I want the plugin to: > Support versioning/backup like TiddlyDesktop. > Have settings for the plugin to control stuff like logging from the component > itself without modifying code. > > This looks very promising! Having a simple method for saving is very > essential in many use cases! While I understand your concern for security > issues, I think still this approach of saving TW is very useful and demanding! > > > > Thanks, > Dyllon > > On Sat, Apr 24, 2021 at 9:15 PM TW Tones <[email protected] > <mailto:[email protected]>> wrote: > Folks, > > This may be the opportunity to simplify saving and give the local storage > plugin or its equivalent safe access to the local system. Thus users can > access a read only online resource and use it as if it were a local app, with > their own data stored locally. > > Any way to reduce the complexity of using, especially saving tiddlywiki(s) > will increase adoption. If the logic and and setup can be included in the > original wiki then they become eminently deployable with self documented > setups. This could include backups, localisation or cloning, I can quickly do > this now with Timimi already in place, if such facilities can be introduced > without a two step, browser specific install, all the better. Yes, all the > appropriate authorisation is needed for security. > > Tones > > > > > On Saturday, 24 April 2021 at 17:42:18 UTC+10 Jeremy Ruston wrote: > Hi Dyllon, > > >> I wrote a small module for saving using the Chromium file system API (which >> is in the process of being standardized). >> >> Example TiddlyWiki 5 Saver Using HTML 5 File System Access API (github.com) >> <https://gist.github.com/slaymaker1907/7a04a6188179bfe113b122b1f51e22b5> > Great stuff, I’ve been following the File System API with interest, and would > be keen to get a saver in the core once the spec settles down. > > Here’s a link for those unfamiliar: > > https://web.dev/file-system-access/ <https://web.dev/file-system-access/> > > I don’t know if any other browsers are planning to implement the API. It > seems like an obvious requirement for ChromeOS, but perhaps other browsers > will have less incentive to implement. > >> The first time a save action is triggered, it prompts for a save location >> but future saves should go to the same location. >> >> It's a bit dangerous because if saving fails, there is no way AFAIK to >> disable the saver after it loads. I would be interested to know if anyone >> knows a way to disable a saver after it has already loaded. > > I think you’re already following the correct approach: for the save() method > to synchronously return false if the save cannot proceed so that the next > saver in the cascade gets a chance. > > Another thought with respect to the File System API is that it may be > possible to write a syncadaptor module so that we can support TiddlyWiki > folders containing individual .tid files in the browser. > > Best wishes > > Jeremy > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "TiddlyWiki" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe > <https://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/6d3bc90f-54eb-4512-a56d-3a62931b75b4n%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywiki/6d3bc90f-54eb-4512-a56d-3a62931b75b4n%40googlegroups.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/CAJsXKEMU2-R3asA6jOZOB35NQca7mpaxnT%3D%3D6sZiev6XVvWG-g%40mail.gmail.com > > <https://groups.google.com/d/msgid/tiddlywiki/CAJsXKEMU2-R3asA6jOZOB35NQca7mpaxnT%3D%3D6sZiev6XVvWG-g%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "TiddlyWiki" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe > <https://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMCuej%2Bg6Aup7WXRdQco4yo5OXyiBeZqb4BMkVa%3D%2BBXOhw%40mail.gmail.com > > <https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMCuej%2Bg6Aup7WXRdQco4yo5OXyiBeZqb4BMkVa%3D%2BBXOhw%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/CAJsXKEMvmHaNG-uwkJAyuHOJd8ZpSkkoimx-qEhPmdM%3DW%3D8TqA%40mail.gmail.com > > <https://groups.google.com/d/msgid/tiddlywiki/CAJsXKEMvmHaNG-uwkJAyuHOJd8ZpSkkoimx-qEhPmdM%3DW%3D8TqA%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/D1C6FA71-1742-456A-A757-899B211934F7%40gmail.com.
