[MAGNOLIA-5292] Make Magnolia respond to only registered extensions Created: 27/Jun/13  Updated: 06/Dec/16  Resolved: 26/Aug/15

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 3.0 Final
Fix Version/s: 5.3.11, 5.4.2

Type: Improvement Priority: Major
Reporter: Jaroslav Simak Assignee: Evzen Fochr
Resolution: Fixed Votes: 1
Labels: support
Remaining Estimate: 0d
Time Spent: 4.5h
Original Estimate: Not Specified

Issue Links:
Relates
relates to MAGNOLIA-6626 Generated links do not have always th... Closed
relation
is related to MGNLIMG-115 Images are displayed regardless of it... 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)
Date of First Response:
Sprint: Sprint 7 (Kromeriz)
Story Points: 3

 Description   

The content can be accessed with any extension e.g.
http://localhost:8080/magnoliaAuthor/demo-project.zzzzzzzzzzz
or
http://localhost:8080/magnoliaAuthor/demo-project.htmlasdfsd

Due to this fact the security scans can see source code disclosure vulnerability in images or other resources.

Out of the box Magnolia installation should instead check extensions against those registered under config:/server/MIMEMappings and allow only no extension or registered extensions to be used.

To allow for backward compatibility, this behaviour should be configurable.



 Comments   
Comment by Roman Kovařík [ 03/Sep/13 ]
  1. ContentTypeFilter returns 404 if no extension is defined and server/defaultExtension property is not defined.
  2. Added new server property supportUnknownExtensions - ContentTypeFilter returns 404 on unknown extension when supportUnknownExtensions is set to false (default is true and the behaviour is same as in previous versions)

TODO: create DOCu ticket after review

Comment by Magnolia International [ 03/Sep/13 ]

This can't and doesn't work. A request to / is perfectly valid and should not be 404, until the virtual URIs are applied. All integration tests will fail once Hudson starts kicking in.

Comment by Magnolia International [ 03/Sep/13 ]

Disabling this new property by default won't help, the redirect on / should still happen regardless of wether we enable or disable unknown extensions.

Comment by Roman Kovařík [ 04/Sep/13 ]

Reverted to move this functionality into separate filter.

Comment by kees de koning [ 24/Feb/14 ]

Can anyone tell me how to apply this?
I have an installation of 4.5.10, does that mean that this option is included?
What do I have to configure where to make sure that domain/path/file.js will only be returned by that URL, and not by domain/path/file.zip, domain/path/file.html and domain/path/file.bogus?
I tried adding supportUnknownExtensions=false to the contentType filter, but that doesn't make any difference
thanks, Kees

Comment by Jan Haderka [ 24/Feb/14 ]

Hi Kees,

this issue is currently solved only for DMS 1.5.3 (MGNLDMS-218) and Imaging 2.2.4 (MGNLIMG-115, Imaging 2.2.4 was part of Magnolia 4.5.12 release), so as long as your file is coming from DMS or available only over Imaging module it should work as of Magnolia 4.5.12, but if your file is stored in resources or in a website (or any other workspace), the issue still exists.

HTH,
Jan

Comment by kees de koning [ 26/Feb/14 ]

That's a bit of a bummer... we did get a security violation reported on .js files in resources. Any resolution coming up soon?

Comment by Jan Haderka [ 26/Feb/14 ]

What kind of violation? Can you share the report? Perhaps over support if you don't want to make it public.
It should be possible to setup virtual uri mapping for resources that would redirect all else to 404.

Comment by Philip Mundt [ 26/Aug/15 ]

In your current solution you add a lot of logic to determine the mimeType to the method info.magnolia.cms.filters.ContentTypeFilter#setupContentTypeAndCharacterEncoding(String, HttpServletRequest, HttpServletResponse). When the mimeType is null, you return null. But the return value is supposed to be the character encoding. You proceed to check whether the character encoding is null and then respond with "Unsupported extension"!

I'd rather have you create a private method that does the mimeType check and if it returns null then we respond with a bad request. ATM we would have to call it twice, because setupContentTypeAndCharacterEncoding() expects the extension and not the mimeType.

Maybe you can come up with a nicer solution!?

Two more things:

  • useKnownExtensionsOnly should rather be registeredExtensionsOnly or similar
    • I actually like the one in the comment above supportUnknownExtensions=true however this turns the boolean logic around (double check with Jan)
  • The commit message needs improvements. Please make the first line short and precise (what was fixed), then add an empty line (if needed) and proceed with a bullet list, e.g.:
    MAGNOLIA-5292 add new property to ContentTypeFilter 'useKnownExtensionsonly' with default false, if set to true, filter stop filter chain and send SC_BAD_REQUEST for extensions not set in MIMEMapping would become:
    MAGNOLIA-5292 Make Magnolia respond to registered extensions only
    
    * Add new property to ContentTypeFilter "<name-of-prop>" that defaults to "<value>"
    * When set to true and the request encounters an unknown extension it will stop the filter chain
      and respond with a SC_BAD_REQUEST
    

    Or similar...This way, you see a short and precise msg in the short git log, but when needed, you can also read the whole message (When skipping the empty line, git will show all bullet points in one line, making the git message unreadable again).

Comment by Evzen Fochr [ 08/Sep/15 ]

Newly add property /server/filters/contentType@registeredExtensionsOnly that can be set for ContentTypeFilter. Default value is false.
If set to true magnolia will respond with 400 to requests with extensions that are not registered in MIMEMapping. (no extension is taken as .html)

Comment by Florian Fuchs [ 08/Sep/15 ]

What will happen, if you call https://demopublic.magnolia-cms.com/about.c ?

Comment by Evzen Fochr [ 08/Sep/15 ]

Same as till now, because .c is registered (if you do not remove it from MIMEMApping). But for future see MAGNOLIA-6348 here we will be checking if requested extension corresponds with response.

Comment by Christoph Meier [ 08/Sep/15 ]

Documentation:

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