Redmine

Right now, if you try to download an attachment with content type text/javascript with Redmine 3, it will be blocked by the CSRF protection of Rails. The user-visible response will be an HTTP 422.

This is because Rails thinks that these attachments are dynamic JavaScript resources and thus have to fall under the same origin policy. Unless the request is an AJAX (hxr) request, the downloads are blocked by the verify_same_origin_request after filter which is part of the CSRF protection. This behavior was added to Rails 4.1 in https://github.com/rails/rails/pull/13345.

The attached patch excludes the AttachmentController#download action from this protection, allowing to download javascript attachments. This change won't cause an XSS vulnerability in Redmine but technically allows a specific attack of external sites:

• Given the attacker (Mallory) knows the attachment download URL of a javascript attachment.
• Given a user (Alice) is logged in to Redmine in their browser with permission to download the attachment.
• If Mallory can trick Alice into visiting a Website which includes a <script> tag referencing the attachment, Alice's browser will download and execute the JS file as a classic CSRF. An attacker controlling the website might then be able to extract data from the executed script.

Unfortunately, there is not really a way around this if we want to support JS attachments (with the correct mime type) at all. Since JS attachments typically don't contain secrets though, this is probably acceptable. With the attached patch, we just fall back to the pre-Rails 4.1 behavior for attachments.

Note that this issue is not directly reproducible on Chrome as uploaded JS files are sent with application/javascript instead of text/javascript which doesn't trigger the rule in Rails.

The patch is only relevant for Redmine versions using Rails 4.1 or newer, i.e. Redmine 3. The issue was detected in Planio and fixed by our staff.