Project

General

Profile

Actions

Defect #40647

open

Attachment Download fails due to Content Security Policy in Safari

Added by Christian Thieme 2 months ago. Updated 19 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Attachments
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

Description

Hello, recently an issue arised that attachment downloads (for instance PDF) don't work using Safari.

There is an error message in the Javascript console:

Blocked script execution in 'https://redmine.test.domain/attachments/download/1234/letter.pdf' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

It is triggered by the CSP in app/controllers/attachments_controller.rb

headers['content-security-policy'] = "default-src 'none'; style-src 'unsafe-inline'; sandbox"

but is not affecting Firefox or Chrome so it might be a Safari Bug.

Redmine: 5.1.1
Mac OS Version: Sonoma
Safari Version: 17.4.1


Files

Actions #1

Updated by Go MAEDA about 1 month ago

Confirmed the issue.

Actions #3

Updated by Go MAEDA about 1 month ago

I found the following change fixes the issue.

diff --git a/app/controllers/attachments_controller.rb b/app/controllers/attachments_controller.rb
index 90c3c7070..1819f058e 100644
--- a/app/controllers/attachments_controller.rb
+++ b/app/controllers/attachments_controller.rb
@@ -323,7 +323,11 @@ class AttachmentsController < ApplicationController
   end

   def send_file(path, options={})
-    headers['content-security-policy'] = "default-src 'none'; style-src 'unsafe-inline'; sandbox" 
+    if options[:type] == 'application/pdf'
+      headers['content-security-policy'] = "default-src 'none'; style-src 'unsafe-inline'" 
+    else
+      headers['content-security-policy'] = "default-src 'none'; style-src 'unsafe-inline'; sandbox" 
+    end
     super
   end
 end
Actions #4

Updated by Go MAEDA 27 days ago

  • Target version set to 5.1.3

Setting the target version to 5.1.3.

Actions #5

Updated by Holger Just 27 days ago

  • File sample.pdf added

The root cause of this (along with Safari being weird) is that we are always serving PDF files with content-disposition: inline (#22483), precisely to please the browser's builtin PDF viewers. For PDF files, the download behavior is thus different from all other filetypes.

Initially, Gregor proposed in #22483 to also provide an inline preview of PDF files (similar to images). Unfortunately, Jean-Philippe rejected this inline preview in #22483#note-14 at the time. Personally, I still believe that this would be the more elegant solution as then we could (from the user-perspective) have the consistent interface of an online preview and an actual download button (which would then also send the PDF with content-disposition: attachment). This would allow to avoid weakening the CSP just to please Safari's weird inline PDF viewer. At Planio, we use something quite similar for a long time now.

In any case, please note that removing the sandbox attribute may possible cause an XSS vulnerability if a raw malicious PDF file containing Javascript can be opened in the origin of a Redmine site (which may be possible due to the inline display. The various inline PDF viewers of browsers handle Javascript in PDFs differently internally, but they generally do not execute JS within the download origin (thus avoiding an XSS).

In any case, I do believe that this is an actual browser bug in Safari as it should not apply the PDF file's CSP for its inline reader component. Instead, the reader itself should respect the CSP of the file.

Both Firefox and Chromium / Chrome had similar bugs once which fixed by exempting their respective builtin PDF viewers from CSP restrictions. I believe that Safari should resolve this issue in the same way.

Actions #6

Updated by Holger Just 27 days ago

  • File deleted (sample.pdf)
Actions #7

Updated by Go MAEDA 19 days ago

  • Target version changed from 5.1.3 to 5.1.4
Actions

Also available in: Atom PDF