Item1685: CSRF securing mechanisms anticipate the intranet installation of Foswiki

In intranets with Single-Sign-On-environment and a secure webapplication portal, Foswiki 1.x cannot be installed in a normal way. In this environment you need to call each link to Foswiki with the name of the portal server, not the Foswiki server. The XSS securing mechanisms prohibit integration in the webapplication portal, which is a precondition for activating a server.

This securing mechanisms can be switched off, and I did it in my way - but with every update of Foswiki, this has to be done again.

I wish there were an expert Configuration setting to switch on "Intranet Webportal Security" and using DefaultUrlHost as only value for calls to the scripts.

A further Enhancement: In a secure intranet installation as I described, the configure script should only be callable by members of the AdminGroup. All other securing mechanisms (.htaccess or in httpd.conf) are forbidden by the webportal policy.

-- WolfgangRaus - 04 Jun 2009

I do not understand this bug report.

• What do you mean with "XSS securing mechanisms"? I do not recall we have a setting or feature that is called that.
• What do you mean with "call each link to Foswiki with the name of the portal server and not the Foswiki server. Do you talk about the domain name that you setup?
• You say that you can switch it off, but at each update you have to do it again. What is it you switch off and what is overwritten with the patch upgrade packages? Configure settings are not overwritten so are you hacking the code or???

On the enhancement - there is no AdminGroup defined anywhere when you run configure for the first time. So we cannot use groups to protect configure.

-- KennethLavrsen - 05 Jun 2009

• not XSS, I meant CSRF - I should not type abbreviations when two people are talking to me... - changed in the summary field. I beg your pardon. I disgraced myself.
• no, not the domain name. The Foswiki server has an apache setup of https and is listening only to the webapplication portal server. The prefix for each Foswiki URL has to contain the webapplication server name, the application, the role, and then scriptpath, web, topic. E.g., a "normal url" like http://foswiki.org/bin/edit/Tasks/Item1685 would look as: https://security.intern.wien.gv.at/buchwiki/admin/bin/edit/Tasks/Item1685 (this is not the real webapplication portal server name). I set the prefix for {ScriptUrlPath} and {PubUrlPath} dynamically in my LoginManager, but the setting for {DefaultUrlHost} is without effect on this point.
• Shortly to give no bad hints for occasional readers: Yes, I hacked the code. In Foswiki.pm, sub new, I set the critical variable to {DefaultUrlHost} after the if - else.

On the Enhancement - what, if there were an expert setting of "Only AdminGroup can call configure", when set, configure is checking this requirement?

-- WolfgangRaus - 05 Jun 2009

OK. Now I understand the issue.

Yes that creates some problem and it has nothing to do with the recent fixes we did in 1.0.5. That was what confused me.

I know many have a problem with the {DefaultUrlHost} and {PermittedRedirectHostUrls}

It will not work with setting {PermittedRedirectHostUrls} to https://security.intern.wien.gv.at/buchwiki/admin or similar?

Normally this is what you do when you have multiple URLs that lead to a server. You can set {DefaultUrlHost} to http://lavrsen.dk and then define {PermittedRedirectHostUrls} to http://www.lavrsen.dk,https://lavrsen.dk,https://www.lavrsen.dk to allow all 4 combinations.

If not I guess a think we miss is to allow wild cards in the {PermittedRedirectHostUrls}

-- KennethLavrsen - 05 Jun 2009

I tested all combinations of {DefaultUrlHost} and {PermittedRedirectHostUrls}, but it did not work: I got only the local Foswiki server name in the links. The problem is not to go to my Foswiki server, but to go any further... the css was not loaded because it was called with URLs to the local server, any link on the surfed page leads only to the local server and was therefore not valid.

-- WolfgangRaus - 05 Jun 2009

I made an upgrade to 1.0.6 and built in the proposal IntroduceForceDefaultUrlHostToggle. Seemed to work, but you cannot edit a topic: at save, you get the message "...has received a suspicious change request from your browser....". Clicking on OK, the topic ist not saved, clicking on cancel, the topic is also not saved.

-- WolfgangRaus - 06 Aug 2009

Back to 1.0.5, after applying the patch from IntroduceForceDefaultUrlHostToggle, edit & save works. The problems I had with 1.0.6 have to do with the Validation Method - set to "none", the process goes to an infinite redirection loop (says my "reverse proxy"). - The patch distro:5bb5b172f678 (see Tasks.Item1830) was no solution.

-- WolfgangRaus - 06 Aug 2009

The infinite redirection loop is described in Tasks.Item1766.

-- WolfgangRaus - 06 Aug 2009

Update: it works with 1.0.6! But only if:

• the patch from IntroduceForceDefaultUrlHostToggle is installed (or an adequate "workaround" is hacked)
• {UseClientSessions} = 1
• {Validation}{Method} = 'strikeone'.

Editing an existing topic, the results are:

{UseClientSessions}	{Validation}{Method}	Result
0	strikeone	validation message and no saving of the topic (without a message, normal return to viewing it...)
1	strikeone	no validation message, topic is saved
0	none	validation message, infinite loop
1	none	validation message, infinite loop

Note that the login procedure is done via an self-written intranet login manager based on https header data.

-- WolfgangRaus - 07 Aug 2009

Judging from Wolfgang's results above this is confirmed. Anyone with the skills, please go ahead....

-- CrawfordCurrie - 26 Jun 2010

ForceDefaultUrlHost is now part of core. But the other issues still need addressing.

-- GeorgeClark - 19 Feb 2015