User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0 Build ID: 20140605174243 Steps to reproduce: Created a new bug Added an attachment of type HTML that contained JavaScript. Opened the attachment through Bugzilla website Actual results: Bugzilla opened attachment executing the embedded JavaScript. Please see bug 1112500 or open below link https://bug1112500.bugzilla.mozilla.org/attachment.cgi?id=8537683 Expected results: HTML Files should be stripped of JavaScript, alternatively do not allow the upload of HTML filetypes

This is intentional as users need to be able to upload content that actually demonstrates browser bugs. This is the reason we provide a mechanism for hosting attachments on a separate domain name, and encourage that to be used, so that the same-domain origin policies for javascript will enforce not being able to use XSS from those attachments.

Hi Dave, I don’t believe this is a duplicate of 38862 or that the fix for 38862 resolves the issue I’m trying to raise. Hosting the attachments on a different domain mitigates some of the potential attack vectors, but not all of them. It will prevent XSS attacks on bugzilla.mozilla.org, and malicious users stealing session/cookie info from that domain but will not prevent attacks on the Bugzilla attachment domain (<bugID>.bugzilla.mozilla.org). As a high level example, this vulnerability could still be exploited to re-direct users to malicious websites, seemingly coming from Bugzilla and using the Bugzilla URL in the Referrer Header. Another Attack Vector may be a username and password phishing attack. Whereby this vulnerability could be used to create a fake Bugzilla Login Page that asks users to re-authenticate before being navigated to the selected attachment. It could then send these details to a malicious user’s email account. There is also the potential for it to be used in combination with other vulnerabilities in the main Bugzilla.Mozilla.org website, such as CSRF or Reflected XSS. These vulnerabilities usually rely on coaxing the victim into navigating to a malicious website which sends the attack. In this instance the Bugzilla attachment domain would be the malicious website and would be seen as a trusted by the user. Please let me know if you require any further information or would like more detailed examples of these attacks. Cheers, Dan

Part of the issue here is that this is not really a "new" bug. We know of the issues here already and have decided on our current solution/setup as the best compromise for how we want to do attachments in bugzilla.

Whether it is a new bug or not, I don't know? Is it still a legit issue that hasn't been resolved, I would say yes. Whichever way you look at it, a site that Mozilla hosts provides an avenue for people to attack users of BugZilla. There is nothing stopping me from creating an attachment containing a beef hook on a public BugZilla Bug, and compromising multiple of your users. Surely a more secure approach would be to at least force download of attachments rather than opening/executing them within the browser? At least in this instance the user has an escape and is accepting the risk of downloading said attachment.

(In reply to DanDan from comment #4) > Surely a more secure approach would be to at least force download of > attachments rather than opening/executing them within the browser? for a system used to track browser development, this would be a massive roadblock to productivity.

The Security of your Users versus Usability . . . I wouldn't say dl'ing a HTML file before viewing it is a 'massive roadblock'. Maybe it would slow you guys down depending on the number of bugs you're working on a day, but to the average user? Maybe different rules for different user roles? I dunno. Anyway, up to you guys. I will stop pestering you now :)

(In reply to DanDan from comment #6) > I wouldn't say dl'ing a HTML file before viewing it is a 'massive > roadblock'. It is when a lot of the bugs treat being loaded from the local file system as entirely different than being loaded from the web. The net result is that we then need to upload the bug to *another* web server to verify the issue or fixes of it.

Fair enough, entirely up to you guys :)