Item1921: CSRF: {Validation}{Method} = 'strikeone' Confirmation Dialog messes up retarded execution macros

Short description

The new CSRF security feature of 1.0.6 which asks for confirmation when saving a topic (see: WhyYouAreAskedToConfirm) can mess up topic content.

How to reproduce

So far we encountered this problem when using retarded macros, e.g. a CALC embedded in a SEARCH. To provoke the CSRF Confirmation Dialog, in our case isn't enough to use the browsers back button after a topic was saved and save it again.

Example

Create a test topic with the following content:

%SEARCH{
"form.name ~ '*UserForm'"
type="query"
web="Main"
separator=", "
format="$percntCALC{$PROPERSPACE($topic)}$percnt"
}%

• After saving you will see a comma separated list of users, with spaced-out names.
• Now go back in your browser, save again and click OK in the Confirmation Dialog.
• Now the list of users will only feature the WikiNames without spaces.
• A click on Raw View will show you, that the embedded CALC vanished:

%SEARCH{
"form.name ~ '*UserForm'"
type="query"
web="Main"
separator=", "
format="$topic"
}%

Another nice example is (if you have ForEachPlugin installed):

%FOR{"counta" start="1" stop="10" step="1"}%
   * $percntCALC{$SETIFEMPTY(ind,0) $SETM(ind, + $counta) $GET(ind)}$percnt
%NEXT{"counta"}%

This will result in

%FOR{"counta" start="1" stop="10" step="1"}%
   *   ERROR: syntax error, at EOF
%NEXT{"counta"}%

Strange, isn't it?

System Info

• most recent Debian packages
• {Validation}{Method} is set to strikeone

Debugging

• Setting {Validation}{Method} to embedded doesn't mess up the content, but the Confirmation Dialog seems to be invoked on any save
• Setting {Validation}{Method} to none will also invoke the Confirmation Dialog, see Item1805

I wonder to what extent there might be a connection to Item1766, where also the validation method is discussed...

-- PhilippLeufke - 13 Aug 2009

My current workaround is going back to embedded validation, with the patch provided in Item1830, which makes the dialog disappear.

But still I feel the issue with the Dialog is urgent, as it modifies topic content and the user might not even notice.

-- PhilippLeufke - 19 Aug 2009

Thanks, Philipp, for the complete instructions on reproducing this problem.

This has to be related to parameter caching in the confirmation page, in which case I wouldn't expect selection of the validation method to make any difference; as long as the confirmation dialog appears, you should see the same behaviour.

Can anyone confirm this on trunk?

-- CrawfordCurrie - 19 Aug 2009

Another problem I encountered today regarding the Confirmation Dialog is related to CommentPlugin (here in combination with ActionTrackerPlugin). Unfortunately I can not reproduce this as I don't know what caused the invocation of the Confirmation Dialog. The procedure was:

• A html form (using FormPlugin) was used to register a new action for ActionTrackerPlugin by use of CommentPlugin in a way that the new action gets submitted to a database topic. All of this normally works flawlessly.
• In this very case after submitting the form, the Confirmation Dialog was shown.
• Confirming with "OK" resulted in creation of a new topic containing the action data. The topic name was the redirection ID as far as I interpret it (here: 8e35c4823103be6a466b487e1d5ed7b0)

This appeared while using the embedded validation.

As I don't understand why in this single case the Confirmation Dialog was invoked, I cannot boil down the problem to make it reproducible for you. Sorry.

-- PhilippLeufke - 19 Aug 2009

I can repeat the "disappearing calc" example on trunk (rev 4684), only when {Validation}{Method} is strikeone. I saw that the CSRF "confirmation required" page contains the text to be saved as a hidden field named text. That field contains is the text that is actually saved, so the "corruption" happens when producing the "confirmation required" page.

-- MichaelTempest - 19 Aug 2009

If I comment out the commonTagsHandler dispatch in Foswiki::expandMacros, the 'text' field looks like this:

<input type='hidden' name='text' value='&#37;SEARCH{
&#34;form.name ~ &#39;&#42;UserForm&#39;&#34;
type&#61;&#34;query&#34;
web&#61;&#34;Main&#34;
separator&#61;&#34;, &#34;
format&#61;&#34;%CALC{$PROPERSPACE($topic)}%&#34;
}&#37;

' />

Foswiki::QUERYPARAMS calls expandStandardEscapes, which converts $percnt to %, which exposes the %CALC%, which the SpreadsheetPlugin's commonTagsHandler dutifully processes.

So if I take out the call to expandStandardEscapes in QUERYPARAMS, the problem goes away.

However, the problem might be that $ should be encoded as $ - so I can also make the problem go away by changing the validate template to use "safe" encoding of QUERYPARAMS, and adding $ to the safe-encoding regex in Foswiki::_encode.

-- MichaelTempest - 20 Aug 2009

The escapes processed by expandStandardEscapes are things like $n and $percnt, all of which use $. So - should the default behaviour of QUERYPARAMS be to expand the standard escapes, or not?

-- MichaelTempest - 21 Aug 2009

After some discussion, we decided that QUERYPARAMS should not call expandStandardEscapes.

• VarQUERYPARAMS does not document this.
• The unit tests do not test for it.
• None of the standard uses in Foswiki's templates depend on it. Instead they may be broken by expanding standard escapes (like validate.tmpl, as described in this bug).

-- MichaelTempest - 26 Aug 2009

I seem to be getting these dialogues at least once per day and, it seems the topic is never quite the same again afterwards if it contains any GluePlugin or html entities. Looks like whitespace is being mangled, and the characters in the raw text that are encoded into HTML entities in the hidden textarea in the confirmation dialogue, are indistinguishable from legitimate HTML entities that were deliberately placed in the original raw topic text.

So after hitting okay, you get data loss. Incidentally this is almost always with a reprev save, so you can't go back a verison.

Suggest we force a new version when these dialogues occur, unless my use-case is too unlikely for average users? Would then appreciate a config option to this effect.

Will work on providing robust reproduceable test cases.

-- PaulHarvey - 23 Sep 2009

This bug reports and its original issue has been closed and a version of Foswiki released with this in its release note.

Can I kindly ask you to open a new bug item to the specific new problem?

And as a note, saving a new revision when you go through a validation screen is not a good solution. You may end up saving a controversal version you did not want saved.

-- KennethLavrsen - 23 Sep 2009