Item12839: REST scripts should individually assert their security requirements

pencil
Priority: Security
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Engine
Component: FoswikiUIRest
Branches: trunk
Reported By: GeorgeClark
Waiting For:
Last Change By: GeorgeClark
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:

-- 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
 

ItemTemplate edit

Summary REST scripts should individually assert their security requirements
ReportedBy GeorgeClark
Codebase trunk
SVN Range
AppliesTo Engine
Component FoswikiUIRest
Priority Security
CurrentState Closed
WaitingFor
Checkins distro:3c9273556ae7 distro:11cb9dc7b951 distro:e15bfdb12cf8 distro:910e74f2cad9 ClassificationPlugin:fdd24b8ca9a2 BlogPlugin:03ac2475ed01 CaptchaPlugin:8e41623f2535 DBCachePlugin:53c47b9ba37b HarvestPlugin:2636b29e68fb ImagePlugin:bdecdc3bd4fe JQGridPlugin:5093febf14fb distro:0dc19499e463 NewUserPlugin:b8a1be3311f0 PageOptimizerPlugin:730e88832217 RenderPlugin:41c33d25118f SolrPlugin:2813bd727378 TopicInteractionPlugin:645f7053337d TrashPlugin:c6b6f2de41be distro:553171682fe6 AntiWikiSpamPlugin:a4ddc8265f4f UpdateAttachmentsPlugin:2e3b5a4f18e0 CaptchaPlugin:d30d304e3c32 distro:a0ac38fc55a2 distro:32102752b962 UpdateAttachmentsPlugin:3c7d4ce50057 distro:2a8965e0f5d5 distro:ac57338dfe21 distro:c40f57ef6c63 distro:8a9c7131eaeb distro:04b677b5b738 distro:b09798ab80f8 distro:488d664c7425
TargetRelease major
ReleasedIn 2.0.0
CheckinsOnBranches trunk
trunkCheckins distro:3c9273556ae7 distro:11cb9dc7b951 distro:e15bfdb12cf8 distro:910e74f2cad9 ClassificationPlugin:fdd24b8ca9a2 BlogPlugin:03ac2475ed01 CaptchaPlugin:8e41623f2535 DBCachePlugin:53c47b9ba37b HarvestPlugin:2636b29e68fb ImagePlugin:bdecdc3bd4fe JQGridPlugin:5093febf14fb distro:0dc19499e463 NewUserPlugin:b8a1be3311f0 PageOptimizerPlugin:730e88832217 RenderPlugin:41c33d25118f SolrPlugin:2813bd727378 TopicInteractionPlugin:645f7053337d TrashPlugin:c6b6f2de41be distro:553171682fe6 AntiWikiSpamPlugin:a4ddc8265f4f UpdateAttachmentsPlugin:2e3b5a4f18e0 CaptchaPlugin:d30d304e3c32 distro:a0ac38fc55a2 distro:32102752b962 UpdateAttachmentsPlugin:3c7d4ce50057 distro:2a8965e0f5d5 distro:ac57338dfe21 distro:c40f57ef6c63 distro:8a9c7131eaeb distro:04b677b5b738 distro:b09798ab80f8 distro:488d664c7425
masterCheckins
ItemBranchCheckins
Release01x01Checkins
Topic revision: r46 - 19 Jul 2015, GeorgeClark
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