You are here: Foswiki>Tasks Web>Item1685 (19 Feb 2015, GeorgeClark)Edit Attach

Item1685: CSRF securing mechanisms anticipate the intranet installation of Foswiki

Priority: Normal
Current State: Needs Developer
Released In: n/a
Target Release: n/a
Applies To: Engine
Component: FoswikiValidation
Reported By: WolfgangRaus
Waiting For:
Last Change By: GeorgeClark
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... wink - 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 would look as: (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, 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 or similar?

Normally this is what you do when you have multiple URLs that lead to a server. You can set {DefaultUrlHost} to and then define {PermittedRedirectHostUrls} to,, 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:

Editing an existing topic, the results are:
{UseClientSessions} {Validation}{Method} Result
validation message and no saving of the topic (without a message, normal return to viewing it...)
no validation message, topic is saved
validation message, infinite loop
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

ItemTemplate edit

Summary CSRF securing mechanisms anticipate the intranet installation of Foswiki
ReportedBy WolfgangRaus
Codebase 1.0.6, 1.0.5
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Engine
Component FoswikiValidation
Priority Normal
CurrentState Needs Developer
TargetRelease n/a
ReleasedIn n/a
Topic revision: r13 - 19 Feb 2015, GeorgeClark - This page was cached on 21 Oct 2021 - 17:49.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy