I’ve noticed that there is some logic to override the mime type of
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
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
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?
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
signature.asc (197 Bytes)