I’ve noticed that there is some logic to override the mime type of
HTML attachments ($TrustHTMLAttachments config) to avoid javascript
XSS attacks in RT.
This was flagged up by a user who was, not unreasonably, confused that
this meant that HTML attachments just resulted in the browser displaying
the raw source.
Now, let me start by saying that my practical knowledge of some of the
more recent XSS issues is by no means comprehensive, but it struck me
that as well as being confusing for the user, this protection is rather
incomplete. There are number of other content types that could supply
“active” content (application/javascript and friends for example - although
it appears that my browser doesn’t attempt to execute javascript delivered
as application/javascript on its own).
I’m led to believe that a better way of serving up as user supplied
(untrusted) files to add a Content-Disposition: attachment header.
This would mean that (in firefox at least) the user would only be
offered the ability to download the file; they could then view the
file without active content by visiting a file:/// URL).
Searching for articles on this subject shows that this isn’t a panacea
(eg I8jesus.com is for sale | HugeDomains,
http://www.foregroundsecurity.com/flash-origin-policy-issues.html)
but I’d have thought that this approach is worth considering.
Has anyone else at Best Practical or in the community been thinking
more about these problems? Should I file a bug relating to this
behaviour suggesting a change from the Content-Type mangling to the
addition of the Content-Disposition header?
Cheers,
Dominic.
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
signature.asc (197 Bytes)
I’ve noticed that there is some logic to override the mime type of
HTML attachments ($TrustHTMLAttachments config) to avoid javascript
XSS attacks in RT.
Sorry, I’ve been on Jury Duty since this came in and there was a small
internal miscommunication about who was going to get a reply out to you.
You’re on the money. When this code path was put together, there were
far fewer MIME types that we needed to worry about. We actually got a
report about this just a couple weeks ago and should have an improvement
out in the next version of RT 3.8.
-Jesse
I’ve noticed that there is some logic to override the mime type of
HTML attachments ($TrustHTMLAttachments config) to avoid javascript
XSS attacks in RT.
Now, let me start by saying that my practical knowledge of some of the
more recent XSS issues is by no means comprehensive, but it struck me
that as well as being confusing for the user, this protection is rather
incomplete. There are number of other content types that could supply
“active” content (application/javascript and friends for example - although
it appears that my browser doesn’t attempt to execute javascript delivered
as application/javascript on its own).
I’m led to believe that a better way of serving up as user supplied
(untrusted) files to add a Content-Disposition: attachment header.
How does New config for AlwaysDownloadAttachments · bestpractical/rt@dde5b99 · GitHub look for this
to you?
Best,
Jesse
signature.asc (197 Bytes)
I’ve noticed that there is some logic to override the mime type of
HTML attachments ($TrustHTMLAttachments config) to avoid javascript
XSS attacks in RT.
Now, let me start by saying that my practical knowledge of some of the
more recent XSS issues is by no means comprehensive, but it struck me
that as well as being confusing for the user, this protection is rather
incomplete. There are number of other content types that could supply
“active” content (application/javascript and friends for example - although
it appears that my browser doesn’t attempt to execute javascript delivered
as application/javascript on its own).
I’m led to believe that a better way of serving up as user supplied
(untrusted) files to add a Content-Disposition: attachment header.
How does New config for AlwaysDownloadAttachments · bestpractical/rt@dde5b99 · GitHub look for this
to you?
Looks like a fine patch, and pleasantly simple. I look forward to
seeing it in a release 
Cheers,
Dominic.
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
signature.asc (197 Bytes)