[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: |
|
||||||||||||||||
| 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. 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 ] |
|
| 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? |
| Comment by Jan Haderka [ 24/Feb/14 ] |
|
Hi Kees, this issue is currently solved only for DMS 1.5.3 ( HTH, |
| 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. |
| 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:
|
| Comment by Evzen Fochr [ 08/Sep/15 ] |
|
Newly add property /server/filters/contentType@registeredExtensionsOnly that can be set for ContentTypeFilter. Default value is false. |
| 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 |
| Comment by Christoph Meier [ 08/Sep/15 ] |
|
Documentation: |