[rt-users] Malicious MIME type handling

[Dominic Hargreaves]

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 http://i8jesus.com/?p=64,
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20100119/6cbc3c7c/attachment.sig>