TiddlyWiki GitHub Saving Questions (JavaScript specifically)

117 views
Skip to first unread message

Finn Lancaster

unread,
Apr 21, 2021, 8:42:04 PM4/21/21
to TiddlyWiki

Hello,
I had a random thought pop in my head about TiddlyWiki GitHub saving security the other day, and couldn't think of my own solution, so I thought I'd ask.

My question is this: From the TiddlyWiki GitHub saving file (https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/savers/github.js), it looks as if the entire wiki file (ie from html tag or similar) is placed inside a new commit for the user's given repo.

Correct me if I'm wrong, but this seems to be completely insecure. If it does work the way I described (.get() request to GitHub to get SHAs and pushing to provided filename), then what is keeping a user from inspecting the code (Right Click>Inspect) and adding a <script>var addedVariable = document.cookie;</script>, or adding TW5 saved localStorage password value with <script>var addedVariable=localStorage.getItem('PASSWORD-LocalStorageName');</script>
and then waiting for someone with proper permissions to come through and save.

The way that this is working in my head (probably completely wrong) is that this variable would be saved as it's inside the bounds of the tag innerHTML, and run each time the wiki is opened. As TiddlyWiki is single-file when downloaded as empty, I can't envision a multi-file system where each Tiddler is saved to a different .txt file, per say, which is the way I would have approached this.

Finn Lancaster

unread,
Apr 22, 2021, 6:40:43 AM4/22/21
to tiddl...@googlegroups.com
Whoops, just realized my mistake: only the creator of the TiddlyWiki or someone with the correct PAT can save. I guess my real question is if TiddlyWiki does save by html tag, or if it grabs the values of Tiddlers individually and safely adds this code into the existing repo file. If so, how is this possible? It would seem like the GitHub API does not allow you to use existing code and just add new content in. 

--
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 tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/bd7284b4-861a-42c5-be25-d77a6eacdc98n%40googlegroups.com.

PMario

unread,
Apr 22, 2021, 7:01:52 AM4/22/21
to TiddlyWiki
On Thursday, April 22, 2021 at 2:42:04 AM UTC+2 flanc...@gmail.com wrote:
...
My question is this: From the TiddlyWiki GitHub saving file (https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/savers/github.js), it looks as if the entire wiki file (ie from html tag or similar) is placed inside a new commit for the user's given repo.

That's right. The git-savers are still working with a "single-file" wiki.
 
Correct me if I'm wrong, but this seems to be completely insecure. If it does work the way I described (.get() request to GitHub to get SHAs and pushing to provided filename), then what is keeping a user from inspecting the code (Right Click>Inspect) and adding a <script>var addedVariable = document.cookie;</script>, or adding TW5 saved localStorage password value with <script>var addedVariable=localStorage.getItem('PASSWORD-LocalStorageName');</script>
and then waiting for someone with proper permissions to come through and save.

It's not that simple to add new code to the "inspected" code view. .. It's a viewer only. So you can't crate new HTML elements and let the browser "execute" it.

BUT you can add new tw plugins to the existing wiki, that is entirely held in the browser memory. ... IF you have local access to the PC you can make the TW save changes. ....

BUT that's the same for every other app on the PC. So that's a completely different "security problem" than browser security. This has to be addressed at the OS level. Eg: Lock the system. So no other users have access to the system in general.
 
The way that this is working in my head (probably completely wrong) is that this variable would be saved as it's inside the bounds of the tag innerHTML, and run each time the wiki is opened.

As I wrote. If I was able to install a TW plugin ... Yes.
 
As TiddlyWiki is single-file when downloaded as empty, I can't envision a multi-file system where each Tiddler is saved to a different .txt file, per say, which is the way I would have approached this.

That's exactly the same problem as a single-file system. The difference is that it would be much harder to detect, because you have many files instead of one.
So the problem doesn't go away, if you use an ed: nodejs. TW version. In contrary. It's harder.

-mario

Finn Lancaster

unread,
Apr 22, 2021, 7:22:01 AM4/22/21
to tiddl...@googlegroups.com
Thanks for your quick response @pmario. You cleared up many of my questions. However, if you could, could you explain the GitHub saving in more depth? For example, is the entire code file saved from the html tag onward? Or is something else used, such as the Tiddler text added to existing commits. If the latter, could you explain how (with the GitHub API) this is even possible? 

--
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 tiddlywiki+...@googlegroups.com.

PMario

unread,
Apr 22, 2021, 7:25:12 AM4/22/21
to TiddlyWiki
On Thursday, April 22, 2021 at 12:40:43 PM UTC+2 flanc...@gmail.com wrote:
Whoops, just realized my mistake: only the creator of the TiddlyWiki or someone with the correct PAT can save.

That's right. ... And there actually is a problem, that worried me at the beginning and it still does. The existing TW code, stores the PAT in plain text in the browser local storage. .. That means, if I do have access to your PC it will probably take 10 seconds for me to get your github access token. ... I'll need a mobile phone to make photo.
 
I guess my real question is if TiddlyWiki does save by html tag, or if it grabs the values of Tiddlers individually and safely adds this code into the existing repo file. If so, how is this possible? It would seem like the GitHub API does not allow you to use existing code and just add new content in. 

As I wrote. Using several files, doesn't make it more secure.  ... Only more complex.

--------------

I think the discussion at github came to this conclusion.

A more secure workflow can look like this.

 - The PAT is encrypted and stored to the local storage
 - The user opens the wiki and views it.
    - The PAT isn't needed. So nothing happens.

 - The user wants to save back to github
 - A (to be made) dialogue asks for the password to decrypt the PAT ... see [1]
 - PAT is decrypted and used to save
 - Decrypted PAT in memory is thrown away immediately

[1] As written at the github issue, it's should be possible to use a browser AddON, that let's you "autofill" the password-form.
The AddOn may also have a dialogue with a "master - PW"

So ... We trade convenience for security.

have fun!
mario

PMario

unread,
Apr 22, 2021, 7:37:38 AM4/22/21
to TiddlyWiki
OnThursday, April 22, 2021 at 1:22:01 PM UTC+2 flanc...@gmail.com wrote:
...
However, if you could, could you explain the GitHub saving in more depth?

For example, is the entire code file saved from the html tag onward?

The whole wiki is stored and modified in the browser memory that is different, to what you see with "right-click inspect". ...

If the save-button is clicked, the button will send a tm-save-wiki message. The TW core will "catch" this message and internally rebuild itself, using templates.

tm-save-wiki is similar to tm-download-file message, which is used to save TW locally.
 
Or is something else used, such as the Tiddler text added to existing commits. If the latter, could you explain how (with the GitHub API) this is even possible? 

It would be possible, to send single tiddlers to github, but this would be called "a tiddlywiki syncer" and they are much more complex.
From a security point of view it wouldn't change anything.

-mario

Finn Lancaster

unread,
Apr 22, 2021, 7:38:35 AM4/22/21
to tiddl...@googlegroups.com
Interesting. So what’s stopping a TW owner from injecting a malicious script into a tiddler? On a side note, PAT’s May be more safely stored by using the CryptoJS library (AES) which requires a password to decode the PAT. I did something similar in my repo at GitHub.com/flancast90/lockifyJS, which could be simply adapted. 

--
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 tiddlywiki+...@googlegroups.com.

Finn Lancaster

unread,
Apr 22, 2021, 7:46:16 AM4/22/21
to tiddl...@googlegroups.com
Why not? If you can add tiddler text to a txt file, any HTML code will not run. It is then much easier to call this plaintext back safely. Why is this just as insecure as a single file solution, then? 

PMario

unread,
Apr 22, 2021, 7:47:54 AM4/22/21
to TiddlyWiki
On Thursday, April 22, 2021 at 1:38:35 PM UTC+2 flanc...@gmail.com wrote:
Interesting. So what’s stopping a TW owner from injecting a malicious script into a tiddler?

IMO "owner" is the key here. ... If you own it, you can do what ever you want.

The same is true for "attacker" ;) ... If s/he has access to your PC, nothing can prevent them from adding malicious code to your wiki. But as I wrote, that's not a TW problem. That's a OS level problem.
 
On a side note, PAT’s May be more safely stored by using the CryptoJS library (AES) which requires a password to decode the PAT.

That's what the guthub issue is about.
 
I did something similar in my repo at GitHub.com/flancast90/lockifyJS, which could be simply adapted. 
 
Will have a look.

-mario

PMario

unread,
Apr 22, 2021, 7:57:37 AM4/22/21
to TiddlyWiki
On Thursday, April 22, 2021 at 1:46:16 PM UTC+2 flanc...@gmail.com wrote:
Why not? If you can add tiddler text to a txt file, any HTML code will not run. It is then much easier to call this plaintext back safely. Why is this just as insecure as a single file solution, then?

That's part of the "more complex" system I was referring to. If you want to have a different level of access, you'll need to create a real TW-syncer, where you can do whatever you want. ...

But this system is still vulnerable to eg: social engineering. I can give you 10 different txt files, that contain javascript code. Every single one of them doesn't do something special. Then I can give you a malicious plugin that isn't related to the text files. .. eg: a presentation plugin, that will allow you to present tiddlers in a nice way. ... The next time you save your wiki the text files are combined into a library module, with full access to your wiki data.

So the problem here is, that you should only use plugins, that you really trust!

BUT that's not a TW problem. That's general security problem.

-mario

Jeremy Ruston

unread,
Apr 22, 2021, 8:20:45 AM4/22/21
to tiddl...@googlegroups.com
I think Mario may have covered this, but the most obvious vulnerability with the GitHub Saver is that of installing a malicious plugin that reads the username and PAT from local storage and exfiltrates it to an external server.

The mitigation for such an attack is that sensitive data in local storage is intentionally not exposed to wikitext, so the attacker would need to install a JavaScript module/plugin, which is somewhat harder to do than a wikitext tiddler.

I think the ideal solution would be to use OAUTH but that is not available for wikis loaded from a file URI.

Best wishes

Jeremy


On 22 Apr 2021, at 12:57, PMario <pmar...@gmail.com> wrote:


--
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 tiddlywiki+...@googlegroups.com.

PMario

unread,
Apr 22, 2021, 9:10:42 AM4/22/21
to TiddlyWiki
On Thursday, April 22, 2021 at 1:38:35 PM UTC+2 flanc...@gmail.com wrote:
Interesting. So what’s stopping a TW owner from injecting a malicious script into a tiddler? On a side note, PAT’s May be more safely stored by using the CryptoJS library (AES) which requires a password to decode the PAT. I did something similar in my repo at GitHub.com/flancast90/lockifyJS, which could be simply adapted. 

Hi,
I did have a short look at your code. .. There are several problems, that immediately jumped into my face.

1st: jquery dependency. about 9000 lines of code
2nd: crypto-js an other 3000+ lines of code

add1) Just to use $.ajax() and $get from jquery. ... Have a closer look at the browser fetch API, which is built into every browser now.
add2) have a closer look at the browser crypto api

At https://github.com/flancast90/lockifyJS/blob/main/Login/js/auth.js#L2 it seems you directly load code from an untrusted source into html.innerHTML, without any sanitation. This is  cross site scripting ! That's extremely unsecure! ... Search the web for .innerHTML, code sanitaiton  and security best practice!

See: https://developer.mozilla.org/en-US/docs/Web/Security

Sorry, but I didn't look further. ...

There are 3 important rules about security.

 - The less code involved, the better!
 - Only use code that you really trust .... even better: That you understand!
 - Security done right is hard!

Just my thoughts
-mario


Finn Lancaster

unread,
Apr 22, 2021, 5:16:54 PM4/22/21
to tiddl...@googlegroups.com
Interesting takeaways. As the project is still being developed, I will be working to change these (I had already identified these issues). However, the auth.js file you reference was created by me, how could it be “not trusted?” 

--
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 tiddlywiki+...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages