Question

On SecuringYourTWiki it mentions security holes, but that "To work around this problem, admins can setup TWiki on a different domain than the other web applications, and require the use of web browsers which support client side domain scripting context separation, such as Mozilla Firefox or Opera."

I have a couple of questions about this:

1. Would it be sufficient security to setup TWiki on a different subdomain (e.g. www.sub.domain.com) instead of on a different domain? I am hosted by 1and1 so can do this, and it is implemented as a virtual host in the httpd.conf.
2. Even new domains I create are all located on the same host (e.g. www.abcd.com maps to .../clients/abcd and www.efgh.com maps to ../clients/efgh). So if I create a new domain for my TWiki, is it actually going to offer any added security?
3. How do I "require the use of ... Firefox or Opera"? I assume if I just ask nicely, then hackers can still use other browsers.
4. Maybe I don;t understand the security risk properly. Is this 'just' a risk to the user of having their username and password stolen? Or could a hacker gain someone else's (e.g. the admin's) un and pw and gain control of the wiki? Or could a hacker gain access to my server and extract or modify data in other web applications? How could a hacker do this - could you please link to more info on this.

Environment

-- EricWoods - 06 Feb 2007

Answer

Not sure on the details, but if I aint' wrong, security depends on the application and the OS.

No application is 100% secure, hence the bug fixes/patches. So far, TWiki is good in pushing out security fixes.

The other side of things is, you should take a look at SettingFileAccessRightsLinuxUnix

-- KwangErnLiew - 10 Feb 2007

Thanks. Yes, I've kept a close eye on the security fixes, but I was hoping to get a bit more detail on the sentence I quoted. I can't tell if there are known vulnerabilities that require a separate domain etc, or if a separate domain just makes it less likely to have have a security breach.

And the other questions like "...require...firefox.." still leave me scratching my head.

So hopefully someone can clear this up, otherwise, I am left with a completely setup wiki that I can't tell the world about because it might put our other systems at risk.

-- EricWoods - 20 Feb 2007

I really don't see what kind of security differences there can be between a normal domain and a subdomain. It is all up to your Apache configuration, nothing to do with TWiki AFAIK.

As for the browser requirement, I think it's more towards the presentation layer, i.e. CSS and possibly Javascript implementations. This has something to do with how browsers adopt standards. Though some may argue that IE is inherently insecure as compared to other browsers, but that's not up to the web application to decide.

The only risk I find about TWiki is the effectiveness of anti-spam plugin(s). There is a BlackListPlugin though.

-- KwangErnLiew - 20 Feb 2007

I confess that I am quite new to administrating TWiki or any wiki, but looked over the SecuringYourTWiki doc and I think I can provide some light on your questions.

First off, I think the SecuringYourTWiki advise regarding separate domains had more to do with protecting other applications you run from being attacked by security issues on the TWiki side, rather than protecting your TWiki per se from attacks.

I am not 100% sure what client side domain scripting context separation means (googling does not seem to bring up much useful other than the wiki topic), but I suspect it has to do with the browser isolating javascript codes based on domain of originating web site, so that javascript from www.a.b.com cannot access anything (javascript or related) the browser may have stored from www.d.e.com. I assume an attack would look something like:

1. I visit the fictitious twiki.org/store page and order some nice TWiki related merchandise, supplying credit card numbers, etc.
2. I then visit some topics on one of the webs in twiki.org. Some malicious person editted a topic and put some nasty javascript or similar

embedded in the topic, and it runs in my browser, and because the domain is the same the javascript has a fair amount of access to what the browser stored (e.g. cookies) related to the purchase, and might be able to use that information to use my account to buy more TWiki related merchandise and ship to the hacker's address.

Presumably if my browser had good domain context separation, if the TWiki store was at http://www.twiki.com ;-), the above attack would fail. I do not know enough about it to know whether subdomains would provide similar protection, and I suspect the answer is browser specific. You may be able to set the web browser to deny based on the web browser being used (e.g. using SetEnvIf on User-Agent and allow with env= arg in Apache), but some users would find that rude. Better just warn users not using sufficiently secure browsers (any browser) to not connect to anything secure in same browser session they connect to your wiki.

But basically, I think the issue being discussed is protecting other applications hosted on the same domain. Because it is easy for strangers to edit content on wikis, sort of by definition, wikis become a "host" for XSS attacks. Most browsers should offer some protection if the wiki is in a different domain from the site being attacked, (not sure about subdomains), so this should mostly be an issue if you have more sensitive applications in the same domain.

-- TomPayerle - 29 Mar 2007

Tom, yep. thats the client side domain scripting context separation

-- SvenDowideit - 24 Apr 2007

Closing this after more than 30 days inactivity...

-- PeterThoeny - 02 Jun 2007

Change status to: AskedQuestions AssignedQuestions AnsweredQuestions ClosedUnanswered