tiddlyweb/serverside content filtering, validation, sanitation

[chris...@gmail.com]

In IRC there has been discussion about the possible need to do server
side filtering of tiddler content that is PUT or POSTed to TiddlyWiki
serversides (such as TiddlyWeb of ccTiddly) in multi-user
environments. In some cases this is because of the need to validate
the structure of the data in the tiddler, in others it is because of
the need to prevent one user from generating tiddler content that will
damage the experience of other users utilizing related content.

A ticket has been created which relates to this issue:
http://trac.tiddlywiki.org/ticket/866

This is a complicated issue, one that is difficult to talk about
without falling quickly into solution space before really
understanding all the issues. I'm posting here because I know I don't
grasp the whole picture and am hoping that other folk will chip in
with their thoughts on the matter.

In IRC we came up with two extreme position on how things might be
handled:

* Do nothing on the server. If the client wants to clean, do some
cleaning, otherwise, let damage happen, this is just a wiki after all,
and beyond that it is TiddlyWiki, a loaded weapon in the first place.

* Adjust the server to allow it to do filtering based on the status of
the user making the PUT. If they are type X let them do anything, type
Y let them do style, type Z let them do just tiddlytext.

I lean toward the first because I think TiddlyWeb is already far too
smart but I also understand that there are significant issues that
need to be handled. My strawman solution is to extend the TiddlyWeb
Policy object so that recipes and bags can have a sanitize policy that
describes how tiddler content should be changed, either when being
saved or when being output (which is an important decision).

I realize this message is a bit vague. That's because the issue is
vague. Anyone with thoughts or comments? Make go!

Thanks.

[Reenen Laurie]

Isn't a 3rd option filtering the content?

ie... a tiddler containing all "illegal" words, or otherwise it could be plugin driven?

Regards,
-Reenen

--
o__
,_.>/ _
(_)_\(_)_______
...speed is good
_______________
I believe five out of four people have a problem with fractions.

[Jeremy Ruston]

I wasn't in the original IRC discussion but am very interested in the issue. The key to the problem seems to be an awareness of the representation format of text resources, and being careful to not, for instance, allow the user to enter plain text in one place that is then displayed as HTML somewhere else. We already track the mime type of the content of a tiddler, don't we? Are there risks in allowing people to request, say, a text tiddler to be returned as HTML?

On the client side, these concerns seem to me to be another good reason to use DOM methods over innerHTML. (For instance, you can always happily do a createTextNode() of unsafe HTML content, because it'll never actually render as HTML; in contrast using innerHTML to squirt in stitched together HTML fragments with bodged encodings frequently fails).

On another XSS-related note, I'm interested to understand how the standard defensive approach of adding a magic hidden token to each <FORM> generated by the server could work on something like TiddlyWeb where the "forms" we post to are often stitched together dynamically in JavaScript, and have never been served by the server.

Cheers

Jeremy

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com