[MGNLRES-281] FTL and YAML files are exposed over the /resources URI2RepositoryMapping Created: 14/Jul/16  Updated: 29/Mar/22  Resolved: 20/Sep/16

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: 2.4.6
Fix Version/s: 2.4.8, 2.5

Type: Bug Priority: Critical
Reporter: Bence Vass Assignee: Ilgun Ilgun
Resolution: Fixed Votes: 1
Labels: security, support
Remaining Estimate: 0d
Time Spent: 1d 7.75h
Original Estimate: Not Specified

Attachments: PNG File config-details.png    
Issue Links:
Relates
relation
is related to MGNLRES-284 Exposed files via new resources module 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
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Sprint: Basel 62
Story Points: 8
Team: Nucleus

 Description   

In order to use the processed resources app, one has to enable the URI2RepositoryMapping for the resources workspace. Since 5.4 the resources workspace contains FTL and YAML files, and these are exposed to the website user over the mapping.

The new resourcing has security checks in place exactly for this reason (hardcoded in ResourcesServlet for yaml, ftl, class, java).

Please add equivalent security checks to the processed resources app.

Proposed Solution

Proposal can be found at https://wiki.magnolia-cms.com/pages/viewpage.action?pageId=125176642



 Comments   
Comment by Richard Unger [ 14/Jul/16 ]

Well found. This is a serious security issue, as YAML definitions can contain potentially secret values like API-Keys, etc... Just on principle, as good security requires minimizing information disclosure, FTL and YAML files should not be exposed.

Comment by Florian Fuchs [ 25/Jul/16 ]

Not only FTLs, but also other files leak information about the system e.g. http://demopublic.magnolia-cms.com/.resources/README.txt

Comment by Jan Haderka [ 29/Jul/16 ]

Actually you are mixing multiple things in this issue.

URI2RepositoryMapping for resources workspace pointing to /resources/ is enabled by resources module not by processed resources and doesn't allow rendering of the raw resources (e.g. ftl or yaml).

We will investigate what happens when you install processed resources and see that no raw templates or configuration leaks.

As for what Florian pointed out, /.resources is not URI2RepositoryMapping but a servlet mapping for ResourcesServlet. Servlet ootb deny serving plain content of any ftl, java,class or yaml files, but all else is allowed. IF you want to hide txt files, simply configure bypass for the servlet. Nothing to do with processed resources (BTW processed resources module is not installed on demo).

Comment by Jan Haderka [ 10/Aug/16 ]
  • the log message should not be warn but debug. You don't want others to fill up your log files just because they are stanning urls
  • tho most likely, there should be security audit log message produced about incident
  • list of restricted/allowed resources should be configurable
  • as pointed out above excluding just yaml/ftl/java/class could not be enough
  • consider allowing configuration of the list via magnolia.properties
Comment by Jan Haderka [ 10/Aug/16 ]

... building up on what i wrote before and making sure it's absolutely clear: in difference from original implementation that was whitelisting all and explicitly blacklisting some types, we should do the opposite and blacklist everything and only explicitly allow some types (css, js, htm, html).

Comment by Espen Jervidalo [ 10/Aug/16 ]

mgeljic had another proposal which I like even more. Serve resources based on a directory-convention and disallow everything else..

templates/
dialogs/
(resources|res) <- allowed

Comment by Jan Haderka [ 10/Aug/16 ]

resources folder would have been fine if that was something we came up with originally, doing this now would break existing installations requiring people to move the files. I don't think it's acceptable as that would generate major work for anyone updating to given version.

Comment by Mikaël Geljić [ 11/Aug/16 ]

Yeah, though I was not making any assumption about what this would look like (For one I was never fond of a resources sub-dir on that level).

Just saying neither blacklisting nor whitelisting is a silver bullet for exposing/hiding resource types—we'll never list all potential types one may use, be it video formats, svg, or what have you, it's just too arbitrary or irrelevant; even if we raise "it's configurable" as a magic wand, it could rather be circumvented by design imo (backend vs. frontend resource files).
Anyway, it's nothing we'd change in a haste at all, current situation is generally ok, while it still is possible to do more fine-grained URI security.

That debate apart, back to the original issue about the URI2Repository mapping:

  • The resources workspace only contains yaml/ftl if you've got something either installed in legacy ways (or migrated from inplace-templating and no yet cleaned up) or hotfixed (only case for yaml). And if you don't, then nothing is exposed.
  • URI2ResourcesRepositoryMapping never filtered anything out; yet I don't mind if we do so ootb or leave it to implementors for those "backend types" newly introduced into that workspace.
Comment by Christoph Meier [ 03/Oct/16 ]

ilgun - What was the final solution?
What should we mention on the Release notes? and on the docs pages?

Generated at Mon Feb 12 06:49:10 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.