Edit: Sitecore Support has confirmed this behaviour as a bug and provided a patch that so far seems to work fine. The patch overrides the method for rendering media links from RTE fields to also include the hash value thus not firing a media request protection error anymore.
The patch number is 438674 for those who need to request this from Sitecore Support.
In the release notes of Sitecore 7.5 rev 141003 you can read about a new security feature called Media Request Protection:
The new media request protection feature restricts media URLs that contain dynamic image-scaling parameters so that only server-generated requests are processed. This ensures that the server only spends resources and disk space on valid image scaling requests.
If you don’t know about Sitecore’s image resizing feature there are good posts about this and the Media Request Protection change on Sitecore Promenade and on seanholmesby.com.
In short it works like this: To use these querystrings the media request also must append a hash value that can only be generated by the Sitecore server, otherwise the querystrings are ignored and you get an error in your Sitecore log file.
However, when enabling this feature (and it is enabled by default) something happens that can be described like this:
To cut a long story short: The Media Request Protection feature is way too agressive. Not only does it strike down on querystrings regarding image scaling, but also on querystrings such as “la” (for specifying language). Furthermore it doesn’t just apply to images. PDF files are also passed through the feature.
And now we reach the point where this feature turns into a bug.
If you create an internal link to a media item such as a PDF using the Rich Text editor, this link won’t include the necessary hash value and thus generates errors in your log file.
This happens on a clean install of Sitecore 7.5 like this:
Save and publish. Now when clicking the link to the PDF file on the published page, this lands in your log file:
14:36:45 ERROR MediaRequestProtection: An invalid/missing hash value was encountered. The expected hash value: 810CD0685B09545533E20038F16018B95DE7BD84. Media URL: /~/media/Files/cms_tuning_guide_sc70-a4.ashx?la=en, Referring URL: http://sc75rev141003_clean/
The cause of this particular behavior is the “la=en” querystring which is generated by Sitecore’s own editing tool.
I’ve reported this to Sitecore Support and await their solution. Meanwhile I’m considering deactivating the Media Request Protection feature, but possible workarounds also include overriding the media request protection feature code itself or overriding the link provider to include the hash value for the media item. I’ll write another post about this if I decide to venture in that direction.
Coresighted 
I’m not 100% sure what are you will get by disabling this feature? I was involved in delivering the initial implementation to Sitecore and while I agree that the logging that Sitecore have added later is too aggressive – as in logging an error where there is none – the functionality and security hardening persists.
This feature is designed to get in the way of only the resize attacks and will still give you the original image or file when it spots a problem. By disabling it you will be leaving your client website exposed to crashes and denial of service attacks for the mere purpose of having your logs clean.
At the very least please look at my original implementation and see if that does the job for you https://github.com/AdamNaj/Cognifide.SiteCore.ImageGuard
LikeLiked by 1 person
Thanks for your comments Adam. Very nice to have some more background as well as technical resources. I couldn’t have hoped for any better response. Will keep the feature turned on, but I’m quite critical towards how the incorrect errors in the log have not been caught by Sitecore during their product testing. Sitecore Support have reproduced the issue and will respond after more investigation.
LikeLike
Nice post, very helpful
Thanks,
Yogesh
LikeLike
Yeah, this still happens in 8.1. It’s very annoying that URLs to Images in Rich-Text fields still lack a hash – so the image is served (though not displayed) at full scale – and that there’s then an entry in the log about it.
LikeLike
Were you able to get an answer from Sitecore? Is there some patch to disable this feature for non image media items (ex: disable for PDFs)?
This makes a lot of sense for images but for PDFs or other non scalable items because it causes some unintended problems related to caching in proxies. It seems some proxies check if the parameter changed and irrespectively of the item having changed or not, the hash remains the same, so a proxy server doesn’t always refresh its cache. Have you faced this situation?
Thanks and great article.
LikeLike
Were you able to get an answer from Sitecore? Is there some patch to disable this feature for non image media items (ex: disable for PDFs)?
This makes a lot of sense for images but for PDFs or other non scalable items because it causes some unintended problems related to caching in proxies. It seems some proxies check if the parameter changed and irrespectively of the item having changed or not, the hash remains the same, so a proxy server doesn’t always refresh its cache. Have you faced this situation?
Thanks and great article.
LikeLike
I’m interested in this answer too as we get many pdf and zip hash warnings as they have no hash at all. It’s a Sitecore 8.2 solution.
LikeLike
I’m interested in an answer to this last question too. We get many WARN logs because of missing hashes on pdf and zip files, which makes no sense at all. Affecting Sitecore 8.2
LikeLike
I got a patch that didn’t work that well unfortunately. I’m planning to reopen the issue with Sitecore Support as soon as I have enough time. As for now I’m accepting the log errors. 😦
LikeLike