With a bit of creativity, practically anything is possible! You’re right in
> that the JS could not have DIRECT access to the user’s file system, but as
> explained in
>
> https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/,
>
> one could
Super-interesting stuff! Thanks for the background.
There's a bit of consolation in there, though: It sounds like the RAA
attack relies on getting the user to execute JS in the WSH rather than
within the browser. TiddlyWiki on Node or running through Bob.exe or in
TiddlyDesktop *might* be a
@Scott,
With a bit of creativity, practically anything is possible! You’re right in
that the JS could not have DIRECT access to the user’s file system, but as
explained in
https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/,
one could simply use
On Tuesday, August 17, 2021 at 9:12:15 AM UTC-4 flanc...@gmail.com wrote:
What makes this more dangerous than the iframe is that it has DIRECT ACCESS
> to your TW instance, so practically anything can be done. For example, I
> could steal your tiddlywiki instance, encrypt it, and hold it for
Thanks all for considering this;
I think the best way to limit risks is to provide plugins in trusted
libraries, from trusted sources. then people could also install these in an
empty html and run a vulnerability test using a plugin designed to
highlight risks. As soon as a library contains
I agree that there are a lot of possible open "attack vectors", and keeping
track of every one is not feasable.
Good conversation so far. I think the primarily concern is that TW will run
obfuscated javascript without a refresh required. That should have an
option to "Sandbox" that behaviour
Really, it gets back to trust and reputation.
A TW coder could write a tiddler that contains no javascript tiddlers, but
that, when run, creates a javascript tiddler that will later get run. So
you would never see javascript code during import. The core TW is already
pretty huge. Adding patch
I never got the alert. I'm curious why some people are reporting that it
worked. Also, "alert" is very public and generally pretty harmless.
Possibly it could be used as part of a phishing scheme. It's not clear to
me that you could create code that could modify anything outside the iframe
Excellent points John. Most users will indeed not review the full text of
every single tiddler they import. I'm now thinking that pointing out which
ones should indeed be reviewed more explicitly would be both easy and
worthwhile.
At the tm-import-tiddlers widget level, any JS that's being
Well, what I see is this:
If you use TW, you use JavaScript. And if you use JavaScript code from
unknown / unsafe sources, you will run the risk of the code doing things
that it shouldn't be doing. That should actually be clear to everyone. But
that's not a problem for TW, but in principle for
Mark et al
You said *TW wasn't built from the ground-up for mult-user, and it's
definitely not how most people are using it. I'm sure products built as
server-side entities (e.g. WikiMedia) have all sorts of protection against
injected code. *
I agree, yet we have Bob which makes this
TW wasn't built from the ground-up for mult-user, and it's definitely not
how most people are using it. I'm sure products built as server-side
entities (e.g. WikiMedia) have all sorts of protection against injected
code.
Anyone who can write and save a tiddler can make a javascript tiddler,
I am currently playing with "real-time multiplayer" capabilities for TW5,
so this is an interesting security vulnerability to be aware of.
My primary concern was "what if a malicious user connected a MIS-IDENTIFIED
wiki to a real-time server. It has a bunch of malicious tiddlers, and it
DOES
Mark S. wrote:
> That was one of the concerns with TWederation. You could import from
> someone you trusted who imported from someone they trusted who ... actually
> couldn't be trusted. It's kind of a hard problem.
>
*Right! *It IS an interesting issue. But *maybe as much an anthropological
Mark S. wrote:
> ... 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
That was one of the concerns with TWederation. You could import from
someone you trusted who imported from someone they trusted who ... actually
couldn't be trusted. It's kind of a hard problem.
On Tuesday, August 17, 2021 at 8:13:42 AM UTC-7 saq.i...@gmail.com wrote:
>
>> I'd be more
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
>
>
> I'd be more concerned about people being tricked into importing a tiddler
> that contained code like this.
>
>From my perspective this is the only practical concern, and once again
emphasizes the need to be careful when importing content from others.
--
You received this message
On Tuesday, August 17, 2021 at 9:53:28 AM UTC-5 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
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,
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
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
@R2, the tiddler is blank by design. Once you have saved the tiddler, press
a key on your keyboard, and it alerts the keynumber back to you. Typing
multiple keys it will alert each key you've pressed as part of *every
keypress*.
On Tuesday, August 17, 2021 at 9:47:27 AM UTC-4 R² wrote:
> Hi
Hi Finn,
Could you perhaps post a video of what you see on your end? I tried on
several instances and don't get the "will alert your keystrokes back to
you" part, just a seemingly empty tiddler.
Best,
R²
--
You received this message because you are subscribed to the Google Groups
Update: just let the devs know
(https://github.com/Jermolene/TiddlyWiki5/issues/5960)
On Tuesday, August 17, 2021 at 9:12:15 AM UTC-4 Finn Lancaster wrote:
> Hello All,
>
> Following the discovery of the iframe content to execute JS in TiddlyWiki,
> I began pentesting TW to find other methods
25 matches
Mail list logo
