In my test, the code didn't do anything. So it's hard to evaluate. What exactly could the code do? Unless it could write to the file system (which is really hard in JS), or if it could send the keystrokes back to a server-based entity, it would not be able to accomplish anything. What browser are you testing with?
I think the WP article is talking about abilities that existed before modern browsers. Modern browsers, as we have found out to our chagrin, tell you that they are doing a download. They can only download to one place, which is usually the download directory. They know nothing about the file system, and can't even tell you the path of an image that has been loaded (also to our chagrin). Once a file is downloaded, it can only be executed by a deliberate action. On Linux, most file managers won't execute from the GUI anymore, so no accidental clicking. On Windows, Windows pops up a message warning you that you are about to run a potentially dangerous file. So it's not easy to get your code executed even if it is downloaded. If a person deliberately puts code on their page that does malicious things, it doesn't matter how it is inserted. So basically, you're just saying that TW uses Javascript and somebody could insert additional JS. But that is a weakness/strength of all AJAX pages. It's not like I could go to an existing TW site and add my own malicious code. It would have to be running a special server based version of TW (node, Bob, ) to make that possible -- not the standalone. In terms of self-protection, the best away to avoid malicious code would be to only use code/plugins that are WikiText based (after reviewing that it doesn't create JS tiddlers), or only using plugins from sources that you really, really trust (e.g. Eric S.) On Tuesday, August 17, 2021 at 7:53:28 AM UTC-7 flanc...@gmail.com wrote: > Mark, > > The scenario I had in mind was: Person A (attacker), adds malicious code > to his TW instance, which is accessible via the web through GitHub pages, > or something similar. He then shares his wiki link with Person B, who > unknowingly goes to take a look at Person A's wiki. On doing this, Person B > then has this malicious JS execute on his end, thereby hacking/infecting > him. > > With JS, this exploit could be crafted in a variety of ways, as stated, > there is already pure-JS ransomware, which, combined with some creativity, > could trick the user into allowing the wiki to access the local filesystem. > There is also ways of installing damaging malware to the users system (see > https://en.wikipedia.org/wiki/Drive-by_download), purely from > vulnerabilities like this. > > So this exploit can reach beyond the scope of there being someone who "can > sit down at your desk and insert code." > > On Tuesday, August 17, 2021 at 10:30:02 AM UTC-4 Mark S. wrote: > >> I'm trying to understand what the problem is. >> >> TW isn't multi-user. If someone can sit down at your desk and insert >> code, then you already have security problems way beyond code. >> Likewise, if you have a publicly exposed TW that anyone can save with, >> then you have security problems beyond a code hack. >> >> So I'm not seeing what the concern is. If someone has the ability to save >> to your TW, then you already have a security breach, regardless of the >> nature of the inserted code. >> >> >> On Tuesday, August 17, 2021 at 7:21:56 AM UTC-7 R² wrote: >> >>> OK, got it to execute. For some mysterious reason, the first few >>> keypresses didn't do anything, then a few did, I clicked elsewhere and >>> modified another tiddler, the next few didn't, and when I went back to the >>> malicious tiddler to get it to execute again, it hadn't recorded keypresses >>> made in the other tiddler. It does seem as if it's at least partly >>> sandboxed but I'll defer to the core coders, I was just curious to see what >>> this was about. >>> >>> Best, >>> R² >>> >> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/de43776c-b2b3-43ea-b96c-c793276bf3a1n%40googlegroups.com.
