[MGNLIMG-225] Can't see image Created: 05/Jul/18  Updated: 30/Sep/21  Resolved: 30/Sep/21

Status: Closed
Project: Imaging
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: John Shankle Assignee: Julian Nodarse
Resolution: Obsolete Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 1h
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-7344 <X-Content-Options: nosniff> Returnin... 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:
Visible to:
Jason Wood, Julie Liu, Nat Guyton

 Description   

Hi,

 

Our security team is telling us that we have to add the following header to our Apache:

“X-Content-Options: nosniff”

After we added this header, certain image urls were no longer working. Specifically those images that were uploaded as jpg vs jpeg. That is because image/jpg is not a valid content type while image/jpeg is.

Looking at the following, the issue was identified, but doesn't seem to have been updated:

https://jira.magnolia-cms.com/browse/MGNLIMG-177

 

It seems this code is still outputting the content type based on properties from the jcr

final String contentType;
try

{ contentType = binary.getParent().getProperty(FileProperties.PROPERTY_CONTENTTYPE).getString(); }

catch (RepositoryException e)

{ throw new IllegalStateException("Can't get content-type from " + binary); }

imageResponse.setMediaType(MediaType.parse(contentType));

 

While the image does render from the servlet, this is causing for content type determination.

 



 Comments   
Comment by Julian Nodarse [ 06/Jul/18 ]

Hi John,
I am trying to see where you say that there is no update with the ticket mentioned. This issue was resolved with Magnolia versions 5.3.13 and 5.4.5. The Content-Type header is not set by ContentTypeFilter anymore since 5.4.5. The MIME type was incorrectly set according to the request extension. But now, it's the responsibility of renderers/servlets to set correct content type which is why you say that the image does render from the servlet correct ?

As for the header you are using, is your security team concerned about MIME type sniffing when an incorrect MIME type is used or is missing? Perhaps you can opt to use the contentType filter’s Validation properties. You can use these by adding them to the configurations in server/filters/contentType. The two properties to add would be @registeredExtensionsOnly and @validateContentType, and they must be set to true. I don’t think the issue is about the jpg/jpeg extension, but rather the use of that header. Perhaps it is a browser issue as well. Have you tested this across different browsers and versions of IE ?

Please see here to see more information on the MIME type mappings : Magnolia MIME Type Mapping

Comment by Nat Guyton [ 06/Jul/18 ]

The issue is that Magnolia is giving the Content-Type header for some images as image/jpg instead of image/jpeg.    image/jpg is not valid, and while some browsers accomodate that, IE 11 does not.

With X-Content-Type-Options: nosniff, the browser is instructed to follow whatever is in the Content-Type header, rather than try to figure it out, which is why it's suddenly an issue.

Comment by Julian Nodarse [ 06/Jul/18 ]

I've created a bug fix ticket for this. I will reach out again on here when I receive any updates on this.

Comment by Marta Kobus [ 30/Sep/21 ]

Hello,

This ticket is now marked as closed due to one of the following reasons:

  • A long period of inactivity
  • Uses an old or Beta version of an application, module, or framework that we no longer support
  • The issue is no longer reproducible or has been fixed in later versions

If you are still facing a problem or consider this issue still relevant, please feel free to re-open the ticket and we will reach out to you.

 

Thank you,

The Magnolia Team

Generated at Mon Feb 12 02:13:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.