[MAGNOLIA-1744] Content can be changed on a public instance by executing links designed for the MgnlInterceptFilter Created: 18/Sep/07  Updated: 23/Jan/13  Resolved: 28/Sep/07

Status: Closed
Project: Magnolia
Component/s: security
Affects Version/s: 3.0.3
Fix Version/s: 3.0.4

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

Issue Links:
dependency
is depended upon by MAGNOLIA-1753 activation: latest security fix block... 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   

It is possible to change content on a Magnolia public instance by executing links like the following:

http://localhost:8080/public/home/partner.html?mgnlCK=1189687249674&mgnlIntercept=NODE_SORT&mgnlPathSelected=/home/partner/maincont/01&mgnlPathSortAbove=/home/partner/maincont/00

This link - for example - moves a content node inside the node hierarchy.

Maybe here is a good solution for this problem:

The main problem is that the user's authority isn't checked inside the MgnlInterceptFilter.
Inside the "doFilter"-Method the code should be changed like this:

if (isAuthorized(request, response) && Server.isAdmin())

{ ... }

This solution helps to prevent executing those "evil" links in the public instance.



 Comments   
Comment by Philipp Bracher [ 28/Sep/07 ]

I fixed the issue by setting the default permission to read.

In magnolia 3.1 we have now a much better security concept where you assign permissions to the anonymous role more clearly. In 3.1 we also distinguish between url and content protection.

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