"Bugzilla's URL field allows javascript: and data: URLs. It's convenient, but it's a security hole." This bug has been cloned from bug 250730, because that bug contains information which should not be revealed at this time. Gerv

*** Bug 250730 has been marked as a duplicate of this bug. ***

checked in on trunk: Checking in template/en/default/bug/edit.html.tmpl; new revision: 1.47; previous revision: 1.46 Checking in template/en/default/bug/show-multiple.html.tmpl; new revision: 1.20; previous revision: 1.19 2.18 branch: Checking in template/en/default/bug/edit.html.tmpl; new revision: 1.40.2.5; previous revision: 1.40.2.4 Checking in template/en/default/bug/show-multiple.html.tmpl; new revision: 1.15.2.1; previous revision: 1.15 2.16 branch: Checking in template/en/default/bug/edit.html.tmpl; new revision: 1.7.2.7; previous revision: 1.7.2.6 Checking in template/en/default/bug/show-multiple.html.tmpl; new revision: 1.3.2.3; previous revision: 1.3.2.2

:( why disallow data: urls? they are a very convenient way to add small testcases to a bug. what's the security problem with them?

data: URLs inherit the domain and security context of the page that links to them, IIRC.

(In reply to comment #6) >data: URLs inherit the domain and security context of the page that links to >them, IIRC. So does uploading testcases to Bugzilla...

...which is why I filed bug 38862.

OK. This made bugzilla A LOT less usable for me -- I make very heavy use of data: testcases. Since I can't access bug 38862 (in spite of being in the security group, eh?), I really don't see what all the noise is about. Even if there is a problem there, tt seems to me like we're making bugzilla less usable for people who know what they're doing, while not solving any real problems, since attachments still behave exactly like they used to. I'd like to ask pretty please that we locally back this out until we've decided that we're locking down bugzilla for good (including fixing whatever bug 38862 is). At that point, I'd really appreciate a way to put a data: or javascript: URI into the attachment form or something and have it be auto-converted to an appropriately safe (in whatever way bug 38862 plans to do it attachment). Note that there is the added point that the "URL" text LOOKS a lot like a link even though it isn't one (see bug 314319 comment 2), which makes the whole situation even worse.

I filed bug 314321 on at least improving the UI for this to not suck quite so much if we decide to change nothing.

Why cripple bugzilla this way? If I set a bug's URL to a javascript: or a data: URL (as I've done often), let it work. I'm in editbugs, I may even own the bug, I ought to be trusted. Since not all such URLs are evil, trust has to depend on the person setting the field. Distrust people, not URI schemes. /be

Brendan, this bug could reveal security-sensitive and marketing-sensitive bugs to attackers, and many many accounts (some of which are pseudonymous) have editbugs. I like bz's idea of treating javascript: and data: URLs in the URL field like attachments once bug 38862 is fixed.

(In reply to comment #12) > Brendan, this bug could reveal security-sensitive and marketing-sensitive bugs > to attackers, and many many accounts (some of which are pseudonymous) have > editbugs. By all means, fix bugzilla to resist attacks across bugs. If the rogue who has editbugs has access to a bug directly, then we have other problems. > I like bz's idea of treating javascript: and data: URLs in the URL field like > attachments once bug 38862 is fixed. How would they be "like attachments"? Would you synthesize an HTML page with a link to the given URL? /be

> By all means, fix bugzilla to resist attacks across bugs. That would require putting every bug at a different hostname (e.g. http://bug-276907.bugzilla.mozilla.org/), so it doesn't seem like the right solution to me. > How would [javascript: and data: URLs in the URL field] be "like attachments"? Bugzilla could parse the data: URL, send you the mime type part as a Content-Type header, and send you the rest as content. Or it could give you an HTML page that links to and/or redirects to the data: URL.

(In reply to comment #14) > Bugzilla could parse the data: URL, send you the mime type part as a > Content-Type header, and send you the rest as content. Or it could give you an > HTML page that links to and/or redirects to the data: URL. Please do something like the latter. We need the ability to demonstrate bugs in these URLs themselves, and since bugzilla has supported setting the URL field directly to such an URL for years, it should not break such URLs totally. It's ok if the result of clicking on that link goes to another page, in which the link must be clicked. But how do you then avoid the security issue behind this bug? Or do you just put warnings in the in-between page? /be

By putting attachments at a different hostname, or putting each attachment at its own hostname, and doing a one-way transfer of authentication. See bug 38862.

/me notes that you can copy the URL out of the URL field and paste it into your URL bar and hit enter

Perhaps we put add a javascript confirm() for data: and javascript: URLs? (presumably these URLs are safer if javascript is disabled!)

I don't like that idea, because it's easy to disguise an evil javascript: URL as a benign one.

I have to ask. What's the proposed ETA for any of the stuff we're discussing here? That is, how long will the current rather painful situation obtain?

OK, the URL link is back on bmo (locally hacked) with a popup alert that gives you additional data about the URL before you click on it (who last changed it, a scrollbar to view the entire thing, etc). You can try it out by clicking the URL link on this bug. I'll file a new bug to get it pushed upstream, but it'll need work (the popup only really works will in Gecko browsers at the moment).

Dave, thanks! Time to work on training myself to click in those two spots quickly. ;)

(In reply to comment #21) >OK, the URL link is back on bmo (locally hacked) with a popup alert s/insure/ensure/ please