create new tag
, view all tags
TWiki should not use JavaScript.

While I appreciate the advantages of scripting, it's a major security issue. It would be easy to log in as TWikiGuest and insert malicious HTML, using TWiki as an unsuspecting vehicle for an attack.

It would be enough to clearly state somewhere that JavaScript is not used in TWiki, so that people can simply switch off scripting when browsing a TWiki site.

BTW this applies to all forms of active content, be it JavaScript, Java, ActiveX controls, or whatever. Even PDF isn't safe (though it's a bit of a hassle to construct a PDF file that stages an attack).

-- JoachimDurchholz - 12 Dec 2000

I strongly disagree. I'm not a programmer nor a security expert, but it seems those problems are solvable. Meanwhile, the amazing TWiki advantage is its smooth blending of basic HTML web authoring features - HTML, HTTP authentication, template structure, etc - with uncompromised Wiki essentials.

To exclude anything HTML-related would seem to go against TWiki's fundamental strength as an integrator.

-- MikeMannix - 14 Feb 2001

Both sides have their merits which is probably just one of the reasons Javascript isn't a requirement for a running Twiki. However, outright banning it at all precludes extensions that are useful and the majority of people would use. After al >90% of people surfing the web (probably >95% in fact) run with browsers that are at least javascript 1.0 compliant or higher, and are capable of running Java 1.0 based apps. As a result the base Twiki should allow people without Javascript/Java to run (so that people running KFM/Lynx or don't like Java and/or Javascript are happy), and that extensions shouldn't really go beyond a certain level of Style Sheet/Javascript/Java levels to maximise relevancy. Clearly extensions people do for themselves don't have that restriction smile

For example I've added the Java based DrawPlugin to our local TWiki and it's been thought to be a very good thing. However it's written in a version of java that's too high to work well in anything other than IE... (Hence the idea on a ceiling on Java versions, despite how much of a pain that is smile )

-- TWikiGuest - 19 Mar 2001

I would not like JavaScript to be banned in plug-ins - not when I was considering writing an AutomaticWikiWordMakingTextEntry.

-- MartinCleaver - 19 Mar 2001

I probably didn't make my point clear enough.

JavaScript as used by TWiki is OK (well, sort of, I'm definitely in the "don't like Java and/or JavaScript" category, but if other people want it, I'll just avoid their sites).

JavaScript in the editable text is a major risk. In a typical TWiki web, a guest can edit a page and insert damaging code. The file upload facilities allow even nastier attacks against subsequent TWiki users. (I should really go and look whether I can find such code.)

So, if TWiki doesn't ban those scripting facilities entirely, it should at least filter them out.
The downside of this solution is that it's a continual maintenance task: somebody must be aware of new forms of active content and make sure that the corresponding tags are filtered out.

OTOH this may be legally risky. If TWiki filters out damaging content but overlooks some of it, the maintainer of the site (or, ultimately, Peter) may be held responsible for damage. This is a real risk in Germany, I've bee told, so this isn't to be taken lightly.
If, OTOH, the TWiki explicitly instructs the users to switch off any active content because it's not needed to operate TWiki, the user is at least partially responsible for any damages because he has ignored the advice from TWiki itself.

OT3H it may be impossible to make sure that such a disclaimer is visible - somebody might add a tag that changes the font color of the disclaimer into "white on white" so that it's invisible... so my current conclusion is that it's best to have TWiki filter out active content.

-- JoachimDurchholz - 31 Mar 2001

As far as public Wikis go, I agree with Joachim. However, TWiki states it's goal as the corporate intranet. That's the use I put it to. And as long as the corporate intranet itself remains secure from the internet, then I don't mind active content.

-- CrawfordCurrie - 30 Jun 2001

Hmm... I think scripting should be an option. In two senses:

  1. Configurable within TWiki, i.e. a variable %ACTIVE_CONTENTS_ENABLED%.
  2. Configurable by the user, so if a TWiki uses scripting then everybody can decide by himself whether he prefers convenience or safety.

One slight gotcha here: Users are not logged in until they start editing, so they might get active contents even if they configured to have none.

Currently that wouldn't be a problem (no active contents in the viewing templates), but a caveat should be added to this effect.

-- JoachimDurchholz - 30 Jun 2001

BTW the corporate intranet setting doesn't mean that you can trust your users.

Quite to the contrary:

  • Most damage is done by pranksters and disgruntled workers, i.e. from inside the corporate web.
  • This shouldn't come as a surprise, since insiders know where to attack most effectively.

CERT has a page on exactly this type of problem. See http://www.cert.org/advisories/CA-2000-02.html

-- JoachimDurchholz - 28 Nov 2001

There's another reason to be wary of Javascript in the editable content of TWiki pages. I found recently that the topic TWikiRegistration contains some Javascript (that generates a suggested WikiName from the user's name). Guess what - because this is embedded in the page text, TWiki's view script expands any characters that it considers should be HTML entities. This breaks the Javascript interpreter in certain browsers, such as IE 5.5.

The approved style for such utility functions is to place them in a separate .js file and to invoke them as function calls, rather than in-line them. Naturally you still have to be able to execute the inlined bit of Javascript that invokes the external function. This could be subject to TWiki / Web / user preferences, as outlined above.

-- ImmoHuneke - 02 Jan 2002

I am trying to get a WikiClone that I can use in a corporate intranet setting. most of my users would be prepared to trust anything that is within the intranet, and some wouldn't even think of blocking an ActiveX app such as the FileSystemObject from their browser. Is it any wonder then that I would like to see JavaScript disabled from the user editable parts of TWiki?

-- RobNorman - 17 Jul 2002

A friend (PaulPetterson) pointed out to me the other day that scripting can also be used to bypass TWikiAccessControl. Someone can use the XMLHTTP object to do a POST of, for example, changes to the TWikiPreferences page. Then if a member of a group that has edit privileges on TWikiPreferences views the page containing that script, the twiki site is basically owned by the original attacker. The only work-around I can think of at present is, when logged in as a member of TWikiAdminGroup, to never visit any page other than those that require TWikiAdminGroup edit privileges.

-- DaleBrayden - 17 Jul 2002

Well, I poked around in the code to see what I could do. First off, I needed to remove all HTML to be on the safe side - just about any HTML tag could contain JavaScript, so this turned into a GetRidOfHTML issue. A plugin wouldn't do the job as it escaped HTML from the header and footer of the page, from the <BODY> tag onwards.

Fortunately, the template text and the user text are held seperately at first, so all I had to do was escape the &, < and > symbols in the user %TEXT% part, just before the call to getRenderedVersion. This needs to be done in view, preview, and any other script that displays user text (e.g. rdiff)

This has the effect of removing all raw user html, but still allowing plugins to use HTML and script, as this only gets inserted during getRenderedVersion() and so would not be escaped. Anything that gets called by a %VARIABLE% would still be able to use HTML (except INCLUDEs which should get parsed in a similar fashion to the current topic). Unfortunately, it also renders the <nop> tag useless (pre and verbatim are less of an issue with no html anyway) - but there must be a way of putting an alternative to <nop> into the Wiki syntax.

As far as I can see, this could be incorporated into the core code with an option in the config file, but it might still need some work to get smaller bugs sorted out.

-- RobNorman - 26 Jul 2002

Interesting - would be worth considering MorePluginHooks to enable this sort of filtering to be done in a plugin, as it's probably something that is needed by quite a few sites.

-- RichardDonkin - 27 Jul 2002

As I was answering the questionnaire for Peter's book, I realized that one of my biggest annoyances is that TWiki doesn't have UploadablePlugins. To install a plugin you have to be the wiki administartor. Which often I am; but often I ask IT to administer the wiki, and when they do I am not allowed to install plugins, because installing plugins could give me access to other user's Windows passwords...

What does this have to do with enabling or disabling JavaScript? Well, since I have encountered at least one wiki completely written in JavaScript, it is obvious that a lot of functionality can be implementedin JavaScript, and do not require Perl.

For example, my favorite plugin, TREEVIEW, could be implemented totally in JavaScript. The JavaScript could find all the pages in a wiki web via the web interface, and then do the TEEEVIEW proccessing. That might be making an already slow plugin even slower - one of the advantages of server side Perl plugins over client side JavaScript is that they can access the local filesystem. But it might motivate a more efficient general solution - e.g. caching the TREEVIEW in a wiki page, with an update button.

See my page UploadablePlugins for more discussion of how a wiki with uploadable plugins might work.

-- AndyGlew - 15 Jul 2005

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2005-07-15 - AndyGlew
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.