[MAGNOLIA-1432] security: cache can go round security checks Created: 21/Mar/07  Updated: 24/Oct/13  Resolved: 27/Apr/07

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 3.0.2
Fix Version/s: 3.1 M1

Type: Bug Priority: Critical
Reporter: Philipp Bärfuss Assignee: Philipp Bärfuss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MAGNOLIA-5416 Add support for handling non-renderab... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

The filter are ordered as such
1. security check (only secure/unsecure uri --> no role based check or similar)
2. cache
3. cms filter (checks if the user can read the content)

If I login as superuser and trigger the cache for several pages, user logging in later can see the cached page independently of the acls.



 Comments   
Comment by Philipp Bracher [ 21/Mar/07 ]

A possible solution is to split the CMSFilter (extract SetHandleFilter and ContentSecurityFilter)

The chain would look like:
1. virtual uri mapping
2. security check (url based, should use roles and url acls)
3. set handel
4. security check
5. cache
6. cms rendering

CMSFilter should get refactored in a way that its code is exteranlized. In addition a servlet should be provided using the same code. Then you can use the CMSFilter or the CMSServlet depending on what your setup needs.

Comment by Philipp Bracher [ 22/Mar/07 ]

I (locally) separated the filters. I have some additional remarks

  • cache filter must be as such that you can have multiple instances in the chain (to avoid unnecessery checks in basic situations)
  • the second security check (the one controlling the acls) should consider that for anonymous user no sessions should be created
  • cache acl checks
  • use a single instance anonymous access manager
  • the sepparation must be as such
    1. virtual uri mapping
    2. security check (url based, should use roles and url acls)
    3. cache (for pages available for anonymous users --> no acl checks)
    4. set handle (resolve url to handle and repository name)
    5. security check (acl based checks)
    6. cache (for pages using acl based caching)
    7. aggregate
    8. render (this can be also a servlet)
Comment by Philipp Bracher [ 22/Mar/07 ]

remark: it is not the job of the acl filter to return 403 in case a page does not exist. It is the job of the cms/render filter.

this is very important since you don't know where the request ends (in the cms filter or other servlet/page)

Comment by Philipp Bracher [ 27/Apr/07 ]

You can define multiple cache filters now defining. You need to ensure to configure the bypasses properly to avoid double caching for example.

Generated at Mon Feb 12 03:26:52 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.