Could the file descriptors be encrypted before storage? Then when there's a save the plugin could fetch the encrypted descriptor, decrypt it, and use it for the save?
On Tuesday, April 27, 2021 at 3:59:23 PM UTC-7 [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: > > 1. You save teaminfo.html to a shared drive which includes > passwords/valuable docs/etc. > 2. You are writing some Rust code and have the docs open (which the > rustdoc tool conveniently generates for you locally). > 3. Someone, NSA/Russia/whoever, compromised some libraries docs and > inserted malicious JS. > 4. This malicious code gets the file descriptor by scanning IndexedDB > and uploads it to some remote location. > 5. 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]> > wrote: > >> >> >> On Mon, Apr 26, 2021 at 11:58 PM Dyllon Gagnier <[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]> 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/ >>>>> >>>>> 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. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [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]. >>> 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. >> To unsubscribe from this group and all its topics, send an email to >> [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]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3a052774-a404-4759-a668-1a7576be194an%40googlegroups.com.
