Closed Bug 1171758 Opened 6 years ago Closed 6 years ago
Persistent xss is possible on Firefox
OS: Unspecified → FreeBSD
Hardware: Unspecified → All
I can reproduce the steps in comment 0 when using the standard Bugzilla UI (i.e.not glob's new one) and when logged in (because otherwise the URL is not autolinkified). Here's the potentially problematic code, on BMO only, in edit.html.tmpl: [% IF NOT is_safe_url(bug.bug_file_loc) %] onclick="return confirm( 'This is considered an unsafe URL and could possibly be harmful. ' + 'The full URL is:\n\n[% bug.bug_file_loc FILTER js FILTER html %]\n\n' + 'Continue?')" [% END %]> If Firefox has suppressed popups, confirm() dies or throws an exception or something, and the onclick handler ends, and the click is processed. The STR seem pretty involved to me, and seem to require multiple levels of framing, so I wonder quite how much of an issue this is? Gerv
Isn't anyone going to work in this issue ? Has it been confirmed ?
I think this is probably WONTFIX due to the incredible complexity of getting the POC to work, and the multiple user steps that are required. If we don't WONTFIX it, then we need to figure out whether we can detect if popups are suppressed in advance, or detect that a popup has failed to be shown, and handle that situation. NI dveditz: thoughts? Gerv
(In reply to Gervase Markham [:gerv] from comment #4) > I think this is probably WONTFIX due to the incredible complexity of getting > the POC to work, and the multiple user steps that are required. What complexity ? All what you gotta do is block those alert and click in the link inside the iframe that's all.
Right - that involves multiple user actions. Firstly, they have to visit the attack attachment. Then, they have to decide to block the alerts. Then, they have to choose to click the dodgy-looking URL inside the <iframe>. This is hardly drive-by. Gerv
thanks for this report mario, you never cease to bring interesting ways to exploit systems :) this patch treats a confirm exception as a failure, as suggested by mario.
Attachment #8624218 - Flags: review?(dkl)
Comment on attachment 8624218 [details] [diff] [review] 1171758_1.patch Review of attachment 8624218 [details] [diff] [review]: ----------------------------------------------------------------- r=dkl
Attachment #8624218 - Flags: review?(dkl) → review+
Somebody knows what would be the appropriated w-sec for this bug ?
@AlBillings: Any updates related bug bounty decision? Thought those decisions used to be done weekly, why is this taking that long ?
Hey Mario, We have a work week this week - that may be why :-) Gerv
Summary: Persistent xss is possible on Firefox → Persistent xss is possible on Firefox(BUG=3)
Summary: Persistent xss is possible on Firefox(BUG=3) → Persistent xss is possible on Firefox
@Byron Dude, just wanted to organize the bugs I reported since I've got some other interesting bugs to report. Why did you change them back ?
(In reply to Mario Gomes from comment #23) > @Byron Dude, just wanted to organize the bugs I reported since I've got some > other interesting bugs to report. Why did you change them back ? that sort of information doesn't belong in the bug's summary. depending on what you're trying to achieve the whiteboard field may be a better field (or a saved search, or bug tagging, or a bookmark).
To ssh://email@example.com/webtools/bmo/bugzilla.git a5f0c0c..09b4735 master -> master
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
glob: re comment 25-- I thought that's what tags like "off-topic" are for?
Thanks for the bounty! :D
(In reply to Daniel Veditz [:dveditz] from comment #27) > glob: re comment 25-- I thought that's what tags like "off-topic" are for? i'm not sure if the contents of that thread belongs in public, so i erred on the side of caution and made it private. but, yes, generally the off-topic tag is suitable.
You need to log in before you can comment on or make changes to this bug.