Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

HTML from DAM delivered with MIME type application/save

Avatar

Level 2

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.

1 Accepted Solution

Avatar

Correct answer by
Level 10

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

View solution in original post

3 Replies

Avatar

Correct answer by
Level 10

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

Avatar

Level 1

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

Avatar

Level 1

A very informative answer. Thank you Sham!