XSS Vulnerability and other security concerns

[st...@sunypoly.edu]

Hello old friends,

I'm working with the CIO at my University to see if it is possible to serve tiddlywiki files on our Web site.

These are two concerns that have been raised:

• Adding the TiddlySpot PHP script to enable rewriting from the browser is a potential security vulnerability that needs to be thoroughly vetted by the web team. 
• Exposing core JS files that can be publicly edited and have changes applied from the browser is a potential XSS vulnerability.

Not sure what the first means ("TiddlySpot PHP" script  - I had sent him a wiki served on TiddlySpot as an example of a page I wanted to host on our site). Could I eliminate that by building wikis from scratch on the desktop, or using TiddlyDesktop, or even on google drive?

The second - any thoughts? Can changes to the JS be applied from the browser? 

(Is this question better asked in the TiddlyWiki dev group -- a place I've always feared entering... :)?

Thanks for your help!

//steve.

[PMario]

Hi Steve,

How many users should be allowed to write back to the wiki? Or should they be read-only?

TW is able to save the whole content as static html files, without any javascript at all. ... BUT ... the usability will be completely different here! eg: no right sidebar, no tabs, no interactive elements. ... just content.

It would be a bit challenging, to make everything accessible, but it should be doable.

have fun!

mario

[st...@sunypoly.edu]

(inline)

On Thursday, February 21, 2019 at 9:58:49 AM UTC-5, PMario wrote:

Hi Steve,

How many users should be allowed to write back to the wiki? Or should they be read-only?

in the public-facing version, they could be read-only, I think -- though I don't know what it means to "write back to the wiki" -- for example, in this wiki visitors "write" their selects to a temp tiddler in order to interact with the content. Does that count as "write back"? 

TW is able to save the whole content as static html files, without any javascript at all. ... BUT ... the usability will be completely different here! eg: no right sidebar, no tabs, no interactive elements. ... just content.

Not especially interested in this approach -- the whole idea is to make spreadsheet-type data interactive, as shown here (same link as above).  

It would be a bit challenging, to make everything accessible, but it should be doable.

 

what did you mean "accessible" ? That's intriguing to me...

have fun!

This is an exercise in working with traditional CIO whose focus on on security and limiting access to the writeable web to a narrow group, while I find that my focus is on broadening access to the interactive web to a broad group of users..."fun" perhaps not, but challenging, absolutely.

Thanks for the response.

 

mario

[Eric Shulman]

On Thursday, February 21, 2019 at 6:47:20 AM UTC-8, st...@sunypoly.edu wrote:

I'm working with the CIO at my University to see if it is possible to serve tiddlywiki files on our Web site.

These are two concerns that have been raised:

• Adding the TiddlySpot PHP script to enable rewriting from the browser is a potential security vulnerability that needs to be thoroughly vetted by the web team. 
• Exposing core JS files that can be publicly edited and have changes applied from the browser is a potential XSS vulnerability.

If all you want to do is "serve tiddlywiki files"... then it is really no different than hosting any other regular HTML file on the server.  Without adding any additional server-side scripts (which could impact on existing security protocols), you would simply upload an HTML file to the server using whatever method is currently in place and approved by the University.

The entire uploaded TW is then simply delivered to the brower just like any other HTML file, and the javascript executes completely within the client-side browser, which runs in a locked-down sandbox environment that is not permitted to peform local file I/O.

The user CAN make changes in the TW and save them to a **local file** by using the default "download saver".  However, this does NOT create anything new *on the server* and opening the locally-saved TW file will still be secure since it is locked-down in the browser's sandbox environment.

-e

[Lost Admin]

Hi Steve,

On the topic of your first point, TiddlySpot PHP... TiddlySpot uses a program on the server to save the Tiddlywiki file. When you press the save button on your tiddlywiki, it makes a call to the server side program to save itself on the server.

The team is saying they need to review the server side script, apparently written in PHP. I reviewed a variation of that script. In my opinion the version I reviewed is adequate for a hobby site. I would want a lot of enhancements to it for anything serious (but that's just my opinion).

On the second point, there are really 2 issues in the one point. 

First is that anyone with access to save a tiddlywiki on your site could modify the javascript that makes tiddlywiki work. Since tiddlywiki is giving you the ability to edit the javascript within the tiddlywiki, it is easy for anyone who has access to it to modify and save it so that it affects the next person to view the tiddlywiki.

Second is the issue of cross-site-scripting (XSS). That is, because the core of tiddlywiki can be modified by anyone who can save a tiddlywiki, they can have it call outside scripts (this is how things like the discus plugin work). The problem is, like the first part, once one person modifies it, it is affected by everyone else who uses the tiddlywiki.

In summary, tiddlywiki requires a very high level of trust in everyone who can edit a tiddlywiki document. As such, it may not be appropriate for environments where you shouldn't place a high level of trust in your users. Like say the students at a University.

The node.js version of Tiddlywiki might be a bit better in addressing the above, but it would still need to prevent the users from saving any javascript.

[st...@sunypoly.edu]

Thank for the responses...I think I've got it (and this confirms my understanding): so I'll try to summarize:

As Eric notes, as long as there are no server-side scripts, TiddlyWiki is just like any other HTML file, and the fact that visitors can modify **their** local "copy" of the wikii in their browser has no impact on my server. As long as they don't have write permissions -- thus, we should (as I've proposed) do our wiki development in a secure sandbox, and wiki serving on the public Web site. And, to repeat, just be sure I've got it: there is nothing different (from a security perspective) about an html that happens to be a tiddlywiki and an html file generated by drupal or any other content management system.

As Lost Admin (?) notes, correctly, that giving individuals *edit* privs in a TiddlyWiki is a whole different ballgame -- and that is not what I'm asking for.

Many thanks for the insights. It's interesting trying to convince info tech professionals to hold two contradictory beliefs simultaneously:  that TW is really not much different than any other html files you've seen, and that TW is radically different than every other application you've ever seen.

//steve.

[TonyM]

//steve.

I feel for you and the "two contradictory beliefs simultaneously".

Just keep in mind, With a read only html file served to the world the content visible or not, can be found, its content is not protected in anyway. But of course the server is protected unless contained therein your html file is compromising information. Just make it clear to users their TiddlyWiki is globally accessible and an open book. Include nothing you do not want the world to see.

The ability to use tiddlywiki in the browser unsaved to disk, or saved locally is fabulous for user interaction because they can enter their own custom data. This will be extended somewhat with the pending release of the next version that includes a local storage plugin, the thing to do is reassure security this is local browser storage, not on the server (Although it will look like it).

Further, If you permit people to publish to the server, or do it on their behalf, make it clear in the domain / folder names this is demo or student published content. Otherwise they could construct a "trojan" wiki that looks like an official site and miss represents the colledge.

In future the local storage plugin could be used to install a trojan on one computer only, although look as if it were only the wiki stored at a readonly html address. But once again give a meaning full  domain / folder name and they can't conceal it completely.

Regards

Tony