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 On Thu, Jan 8, 2009 at 7:52 PM, Reenen Laurie <[email protected]> wrote: > Isn't a 3rd option filtering the content? > > ie... a tiddler containing all "illegal" words, or otherwise it could be > plugin driven? > > Regards, > -Reenen > > > On Thu, Jan 8, 2009 at 7:30 PM, [email protected] > <[email protected]>wrote: > >> >> >> 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. >> >> > > > -- > o__ > ,_.>/ _ > (_)_\(_)_______ > ...speed is good > _______________ > I believe five out of four people have a problem with fractions. > > > > > -- Jeremy Ruston mailto:[email protected] http://www.tiddlywiki.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
