[MAGNOLIA-4395] Security filters should set 401 or 403 more appropriately Created: 26/Apr/12  Updated: 27/Apr/12  Resolved: 27/Apr/12

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 4.5.2
Fix Version/s: 4.5.3

Type: Bug Priority: Neutral
Reporter: Magnolia International Assignee: Daniel Lipp
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by JRDVX-2 Figure out auth/callback issues Resolved
duplicate
duplicates MAGNOLIA-4389 URISecurityFilter#isAllowed does not ... 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   

Currently, both URISecurityFilter and ContentSecurityFilter inadequately set a 403 http status when a user doesn't have access to a given resource. The problem lies in the fact that it doesn't distinguish between anonymous and logged-in access. An anonymous request should most likely end up with a 401 code ("needs authentication"), whereas when the user is already logged in, a more correct return code would be 403 ("not authorized"). While this might lead to some security concerns (one can discover the existence of protected content), it also leads to basic authorization simply not working with some client. Browsers, for example, will only display the auth dialog when receiving a 401, not a 403 - or so it seems, anyway.
If there really are security concerns about this change, it could also be made optional (on/off).



 Comments   
Comment by Magnolia International [ 26/Apr/12 ]

Sorry, hadn't seen MAGNOLIA-4389 yet, great ! I think the same should be applied to ContentSecurityFilter ?

Comment by Magnolia International [ 27/Apr/12 ]

See MAGNOLIA-4389

Comment by Jan Haderka [ 27/Apr/12 ]

Since there's more then one filter manipulating response code, I'd see it as more prudent and easier to maintain to have such behavior (swapping 401 for 404) in separate filter should anyone need such functionality.
Also it seems to me a bit as violation of http spec so I would not want to have this coded in filters that are always mandatory to execute.

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