Item12839: REST scripts should individually assert their security requirements

AllowGuestsToUseRESTAsDefault has been partially implemented.

rest has been removed from AuthScripts but it has not had the default security assigned during registration tightened up.

-- GeorgeClark - 02 Apr 2014

This is trunk only, Foswiki 1.1.9 is is not impacted.

-- GeorgeClark - 04 Apr 2014

authenticate => 1 handlers can't be called from the cmdline atm even though the user is admin.

-- MichaelDaum - 18 Apr 2014

Please see my comments at AllowGuestsToUseRESTAsDefault about the new {InsecureREST} flag.

-- MichaelDaum - 28 May 2014

yeah That needs some cleanup. This was first pass of that work.

• The default of the flag should be unchecked. eliminating the warnings.
• Site uses it only if plugins are not working and they need to revert to Foswiki 1.1.x behavior.

-- GeorgeClark - 28 May 2014

Have to reactivate this task item again as the recent check-in now requires all REST handlers to specify allowed http methods as well as validation ... which wasn't the case before. For now we only talked about allowing guests to use rest and as a consequence require a properly defined authentication for REST handlers. Now all handlers must defined:

Had a good chat with George about the issue see http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2014-05-29,Thu&sel=56#l52

State of argument is:

• most rest handlers will break now as they rarely require POST or validation
• some rest handlers were found that actually require POST and validation, yet they worked without (SubscribePlugin has been one example)
• current situation is that nearly all rest handlers in plugins have been reviewed to properly specify authentication under the impression that they specify whether WikiGuest is okay to call them or not
• but not so for http_allow and validate ... these still rely on defaults on the core code
• core defaults may vary depending on the newly invented {LegacyRESTSecurity} switch: they are either new-school (maximum restrictive) or old-school (least restrictive)
• users may now come into a situation where they might be tempted to switch on {LegacyRESTSecurity} for a newly installed plugin not working under the new rest regime
• however in doing so other plugins already installed now get different defaults ... however they may have relied on new-school rest security, i.e. POST to be required, as they inflict changes in the system
• so half of the plugins may only work properly with {LegacyRESTSecurity} enabled ... which puts the system back into danger as other rest handlers are now accessible via GET again even though they better shouldn't
• two ways to resolve this:
  1. remove {LegacyRESTSecurity} switch and implement new defaults; at the end of the day defaults are there to stay hard-coded; that way plugins can rely on them to be there
  2. require plugins to fully specify all three of the security flags and print a security error warning to the logs when they don't do so during registerRESTHandler

The issue will be discussed on the next release meeting.

-- MichaelDaum - 29 May 2014

In order to keep this moving forward, I've restored the most restrictive secure defaults, and added two warning messages

+'WARNING: your rest handler does not specify http_allow, validate and/or authenticate.   LegacyRESTSecurity is enabled.  This handler may be insecure and should be examined:';

-or-

+'WARNING: your rest handler does not specify http_allow, validate and/or authenticate. Foswiki has chosen secure defaults:';

I've also fully specified 3 plugin's rest handlers:

• JQueryPlugin
• NatEditPlugin
• UpdatesPlugin

-- GeorgeClark - 29 May 2014

MailerContribPlugin is the last rest handler needing full specification. This can be closed once that's done.

-- GeorgeClark - 04 Jun 2014

Commenting is disabled while not logged in