Bug 520511 (CVE-2009-3010) - CVE-2009-3010 firefox/seamonkey: XSS due to data: URIs in refresh header
Summary: CVE-2009-3010 firefox/seamonkey: XSS due to data: URIs in refresh header
Alias: CVE-2009-3010
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://web.nvd.nist.gov/view/vuln/det...
Depends On:
TreeView+ depends on / blocked
Reported: 2009-08-31 20:54 UTC by Vincent Danen
Modified: 2019-09-29 12:31 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-09-05 18:53:34 UTC

Attachments (Terms of Use)

Description Vincent Danen 2009-08-31 20:54:05 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-3010 to
the following vulnerability:

Name: CVE-2009-3010
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3010
Assigned: 20090831
Reference: MISC: http://websecurity.com.ua/3315/
Reference: MISC: http://websecurity.com.ua/3386/

Mozilla Firefox 3.0.13 and earlier, 3.5, 3.6 a1 pre, and 3.7 a1 pre;
SeaMonkey 1.1.17; and Mozilla 1.7.x and earlier do not properly block
data: URIs in Refresh headers in HTTP responses, which allows remote
attackers to conduct cross-site scripting (XSS) attacks via vectors
related to (1) injecting a Refresh header that contains JavaScript
sequences in a data:text/html URI or (2) entering a data:text/html URI
with JavaScript sequences when specifying the content of a Refresh
header.  NOTE: in some product versions, the JavaScript executes
outside of the context of the HTTP site.

Comment 1 Vincent Danen 2010-12-21 19:09:20 UTC
According to this description, we should be shipping fixed versions (3.6.13), however I don't see any reference of this CVE name on upstream's web site, so I'm not sure.

http://xforce.iss.net/xforce/xfdb/52999 indicates that there is no upstream remedy, but that can also be due to upstream not noting this issue anywhere that I can find.

I don't know if that means this is resolved upstream, isn't an issue after all, or if this CVE was assigned to something that already had a CVE name.

Does anyone know?

Note You need to log in before you can comment on or make changes to this bug.