As designed xF2.2.2: Some pdf attachments downloaded as content-type "application/octet-stream"

Scandal

Scandal

Well-known member
Affected version
2.2.2
Do you have any idea why some pdf attachments are downloading as content-type "application/octet-stream"?
This has the result the file to not be able to be opened by the OS (Windows, Android, iOS).

I don't know why this occurs, since my addons are not affecting the attachments part. I use xenForo 2.2.2 (the problem appears also on xF2.2.1 and I upgraded today just in case that would be fixed, but it is not).
 
The short answer is that this is intentional and may have security implications if it were changed.

Only specific file extensions are sent with a non-generic MIME type (application/octet-stream) and not marked as downloaded. When content is displayed inline (particularly with a correct MIME type), there are situations where this can trigger JS execution and it will potentially be done in the context of your domain, which opens up an XSS vector.

There is a small amount of discussion about this here, though it is older:

security.stackexchange.com

XSS via PDF when Content-Disposition: Inline?

There are kind of two questions here: Is it possible to have XSS in a PDF file when the Content-Disposition: is "inline"? If it is possible, does the pdf get access to the cookies for that domain ...
security.stackexchange.com security.stackexchange.com
 
Given that you're suggesting it happens in multiple OSes (and presumably browsers), combined with your comment that it happens to some PDFs only, it would certainly seem to point to an issue with the PDF. This particular approach has existed for PDFs (and most other non-image file types) since XF 1.0. This absolutely shouldn't cause issues with downloads in Chrome on Windows for example (though it won't display the PDF inline initially; it has to be opened after downloading).

There is a potentially relevant change in 2.2 due to service workers, though that has issue was specific to iOS from what I recall. XF actually exempts using service worker fetches for URLs with /attachments/ or /download (roughly speaking) in them for this reason. So if you're using a non-standard attachment serving URL, this could potentially be skipped, but any issue here should be OS/browser-specific and would almost certainly apply to all PDFs (and not just some).
 
Top Bottom