Question

While I'm happy that the content on my server can be changed at will, I am concerned about potential attacks similar to XSS (CrossSiteScripting), and the ability to insert javascript into Wiki pages. I have a duty to at least try and protect users in this way, and to delete such a post would mean having viewed it first...

Is there any way to block <script>s from running, or to display them as verbatim text?

• TWiki version: 01 Dec 2001
• Web server: Apache 1.3.26
• Server OS: RedHat Linux 7.x
• Web browser: IE 5.5
• Client OS: Win98

-- RobNorman - 16 Jul 2002

Answer

Very valid concern, IMHO. I dimly recall a discussion in Codev about HTML tags to be disabled/removed when saving page. Sorry no links. Try search.

-- PeterMasiar - 16 Jul 2002

See SanitisingHTML, DisableHTML

-- PeterThoeny - 17 Jul 2002

Followup

So far so good, and these articles are helpful... I also found GetRidOfJavaScript somewhere in the search. Unfortunately, I still can't disable JavaScript in user edited pages since any html tag is capable of holding script elements in it's event handlers - e.g. onMouseover, onLoad

The GetRidOfJavaScript article mentions quite rightly that a large proportion of corporate security breaches occur from within the company. Since I am planning to run a Wiki within a corporate intranet, most of the staff are likely to trust anything it terms of security. If a popup says they're about to run a potentially unsafe ActiveX script, there's a good chance they would click 'Yes' and expose their hard drives to the FileSystemObject, sending the password policy and anti-virus measures out of the window.

IMHO the only way to get around this and create a 'safe' Wiki is to abandon the thought of HTML tags, and modify WikiSyntax so that the <verbatim> and <nop> tags are not html style tags at all.

Part of the original reason I fell in love with the Wiki concept was power in the sheer simplicity of it all. Here was a way of allowing users to create their own content without the headaches of teaching them HTML. It was searchable, and nobody needed to sit in a darkened room uploading files to the server. Soon afterwards, I realised exactly how much flexibility the users would have - and it scares me! Also, trying to teach users two different forms of syntax, and explain to users why things disappear when you use < symbols in a page is going to be a running battle. HTML does not always follow the KISS concept that most corporate systems are in need of.

Oops... I seem to have gone way off topic for XSS, but it's all pretty much the same thing (if you get their FileSystemObject, you get all their cookies!). The more functionality you build into a system in terms of scripting and formatting, the more holes you are putting in for malicious users to exploit. Maybe I'll have to hack TWiki to create a system for corporate users (and maybe take on board the RenameWebToZone ideas). I don't think I'd get the go ahead to release the current system, and that is a great shame.

-- RobNorman 17 Jul 2002

At work we depend on HTML because we wrote several TWiki-based applications. We however discurrage users from using HTML and JavaScript.

How about writing a DisableJavaScriptPlugin? This seems to me the right approach, and it seems to be a straight forward task of filtering out everything between script tags and all JavaScript event handlers in HTML tags.

-- PeterThoeny - 17 Jul 2002

If it were quite that simple I would agree. I started to make a DisableScriptPlugin to do just that, but then I got on to the thought of StyleSheets and Internet Explorer behaviors which can also bring scripting into play. I realised (again!) that you could possibly spend days chasing all the possible variations of including script in a page, and still have a browser vendor release some "new, exciting way of enriching the internet experience" that would blow holes in your attempts at making the thing safe. Should I also drop all Flash (object) tags to stop those holes from sinking the boat? What happens if a third party comes out with a product that's even less secure but which I can't do anything about...?

The only way I can see of making it safe (and that's what this is all about) is to use a function similar to PHPs htmlspecialchars() to escape all the HTML code, and to hell with legacy HTML pages - they can look weird until someone gets the time to refactor them (isn't that part of the fun of Wiki?) I could rip out all object tags, script tags, style / behaviour tags etc... but then what do I have left? Duplicates of WikiSyntax. And what is the point of that?

If you want to use JavaScript in plugins, great - but find some way to include that in the non-user editable parts, such as the templates. It needs admin interference to install the Plugin.pm file anyway, so I don't see that installing plugins with JavaScript should cause many more problems than it does already.

Should this be on Codev yet?

-- RobNorman 18 Jul 2002

All good points. However, there are TWiki based apps in corporate environment where you do need HTML.

Feel free to start a new topic in Codev or add to an existing one.

As an alternative, you could try to write a EscapeHtmlPlugin that does what it says in function outsidePREHandler.

-- PeterThoeny - 17 Jul 2002

I tried creating a plugin to escape HTML today but there's one slight problem... It escaped all the HTML in the page, from the <body> tag onwards.

Now, I could do some lengthy hack to try and figure out where the top of the template ends, and the user defined text starts, and set a flag here to indicate that the HTML should be escaped until the flag is unset through another lengthy hack to find the start of the template footer. Even if I were able to do this, it would likely screw up if the default templates were changed. It would also fail to correctly handle the footer of the template, as anything that the footer contains could be replicated in the user text to trick any such checks into unsetting the flag.

Anyone got any ideas?! as pointed out in GetRidOfJavaScript, having script enabled makes the permissions system potentially useless, yet I can't find an elegant way to block it out

I guess what I'm looking for is an alternative to outsidePREHandler that only affects the user text, not the template.

later on

I just had a poke around the code and inserted a few lines to remove &, <, and > just before certain getRenderedVersion() calls, and that seems to do the trick. Now I have to find an alternative to <nop> and rewrite the documentation to cut out html... Then again, judging by the TODO notes in the code, there still seems to be a security bug in Warning: Can't find topic ""."" for sites where the user isn't supposed to have read permission.

Incidentally, while editing this topic, I discovered that the <body> tag confuses the parser when used in its raw state and causes everything before it to not be rendered. I don't know if this has been mentioned before, but it goes to show how bad the rendering logic is

-- RobNorman - 25 Jul 2002