HTML from DAM delivered with MIME type application/save | Community
Skip to main content
Level 2
October 16, 2015
Solved

HTML from DAM delivered with MIME type application/save

  • October 16, 2015
  • 3 replies
  • 1451 views

I have some raw HTML files in DAM that I've activated.  In the DAM asset view, it's indicating "text/html" as the asset type.  When I visit the URL of the activated asset, the http response delivers content-type application/save.

text/html is defined as a mime type in the Sling Mime type service.

Are there default configurations around /content/dam/* forcing this?

Thoughts?

Thanks in advance.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Sham_HC

Starting with 5.6 we decided to try to get the author-side XSS[1] free as well. This means it should not be possible for an author to upload unfiltered HTML or JS anywhere to the repository - and this includes the DAM. We understand that customers want to store HTML/JS in the DAM, so the compromise was to serve these files with content-disposition: attachment so they will not be executed in the browser. Though the 'author' works within the company and has to be trusted at the same time have to deal with attacker-model of the 'disgruntled employee' and hence the SafeBinaryGetServlet to make you aware & use at your own risk. Remove the black listing of "text/html" from [2] should resolve the issue.

[1] http://en.wikipedia.org/wiki/Cross-site_scripting

[2] http://<host>:<port>/system/console/configMgr/com.day.cq.dam.core.impl.servlet.SafeBinaryGetServlet

3 replies

Sham_HC
Sham_HCAccepted solution
Level 10
October 16, 2015

Starting with 5.6 we decided to try to get the author-side XSS[1] free as well. This means it should not be possible for an author to upload unfiltered HTML or JS anywhere to the repository - and this includes the DAM. We understand that customers want to store HTML/JS in the DAM, so the compromise was to serve these files with content-disposition: attachment so they will not be executed in the browser. Though the 'author' works within the company and has to be trusted at the same time have to deal with attacker-model of the 'disgruntled employee' and hence the SafeBinaryGetServlet to make you aware & use at your own risk. Remove the black listing of "text/html" from [2] should resolve the issue.

[1] http://en.wikipedia.org/wiki/Cross-site_scripting

[2] http://<host>:<port>/system/console/configMgr/com.day.cq.dam.core.impl.servlet.SafeBinaryGetServlet

cq-frankie
October 16, 2015

I am also experiencing the same problem on a 5.6.1 instance.

cq-frankie
October 16, 2015

A very informative answer. Thank you Sham!