[tw5] Re: XSS Vulnerability and other security concerns

2019-02-21 Thread 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

On Friday, February 22, 2019 at 5:11:34 AM UTC+11, st...@sunypoly.edu wrote:
>
> 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.
>
>
> On Thursday, February 21, 2019 at 10:17:03 AM UTC-5, Lost Admin wrote:
>>
>> 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.
>>
>> On Thursday, February 21, 2019 at 9:47:20 AM UTC-5, st...@sunypoly.edu 
>> wrote:
>>>
>>> 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:
>>>
>>>
>>>-

[tw5] Re: XSS Vulnerability and other security concerns

2019-02-21 Thread steve 
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.


On Thursday, February 21, 2019 at 10:17:03 AM UTC-5, Lost Admin wrote:
>
> 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.
>
> On Thursday, February 21, 2019 at 9:47:20 AM UTC-5, st...@sunypoly.edu 
> wrote:
>>
>> 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.
>>
>>
>>

-- 
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 post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/96fd801e-651a-41a7-9e75-46d00824c999%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[tw5] Re: XSS Vulnerability and other security concerns

2019-02-21 Thread 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.

On Thursday, February 21, 2019 at 9:47:20 AM UTC-5, st...@sunypoly.edu 
wrote:
>
> 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.
>
>
>

-- 
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 post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/035afca9-0b46-4dd2-8365-e0256951137e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[tw5] Re: XSS Vulnerability and other security concerns

2019-02-21 Thread 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

-- 
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 post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/38191b28-aec4-4af8-9a55-999763b79c3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[tw5] Re: XSS Vulnerability and other security concerns

2019-02-21 Thread steve 
(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
>

-- 
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 post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/92f104fb-68e0-4849-9ca1-0ba7376cc290%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[tw5] Re: XSS Vulnerability and other security concerns

2019-02-21 Thread 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

-- 
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 post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/43aef15a-ab0c-4b22-b7f6-aaf989cf97f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.