Closed
Bug 450981
Opened 17 years ago
Closed 16 years ago
Ignore <meta http-equiv> tag outside of <head> (XSS mitigation)
Categories
(Core :: DOM: HTML Parser, enhancement)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: oueki, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(1 file)
|
427 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080813032636 Minefield/3.1a2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080813032636 Minefield/3.1a2pre
Because There is the Refresh or redirect function for the <meta> tag. If the pages have been injected by such tag outside the <head> tag, it may cause the security issue.
Reproducible: Always
Updated•17 years ago
|
Comment 2•17 years ago
|
||
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta says meta elements must be inside a head element. I don't know whether that statement is about documents or user agents, though.
Note that what is "inside the head" is not always obvious from reading a page's source code. For example, http://www.google.com/intl/en/privacy.html uses <meta> without an explicit <head>, yet the DOM shows the META element as a child of a HEAD element. See
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#optional.
I think this bug report should not be security-sensitive.
Comment 3•17 years ago
|
||
Confirming based on the what-wg/html5 spec. The HTML 4.01 spec is ambiguous: meta is discussed between head and body but not explicitly declared to be head-only
The what-wg spec says <meta http-equiv=""> and <meta charset=""> have to be in the head, but <meta name=""> can still be anywhere metadata is wanted. For example you might have a list or table of books, and you need the ISBN handy but don't want to clutter the display with it. You could do something like
<li class="book">
<meta name="ISBN" content="xxxxxxxx">
<a href="">My Life With Mozilla</a> by Buffy, the heartwarming
story of a cardboard cutout's years with an internet startup.
</li>
IE7 and Safari both behave exactly the same with this test document. Changing behavior is going to break things so we need to be open about the change and why. Unhiding the bug.
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.1?
Summary: Firefox should not apply the <meta> tag outside the <head> tag. → <meta http-equiv> should be restricted to the document <head> per HTML5
Comment 4•17 years ago
|
||
The spec says "When a meta element is inserted into the document, if its http-equiv attribute is present and represents one of the above states, then the user agent must run the algorithm appropriate for that state, as described in the following list: [...]". At no point does it say that the user agent is to check _where_ the <meta> element is.
HTML5 covers both user agent requirements and authoring requirements. The requirements are always stated very literally. "The <foo> element must be in the <bar> element" means just that the <foo> element has to be in a <bar> element, it does _not_ mean that anything happens if a <foo> element is inside a <bar> element or not inside one. On the other hand, "the user agent must..." gives a requirement for the browser.
Thus this bug is INVALID. It's wrong for documents to have <meta> elements outside of the <head>, but that has no bearing on what browsers are to do.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Comment 5•17 years ago
|
||
(note that if it is thought that this could be changed to avoid XSS bugs, as initially suggested, then I would suggest bringing this up in the WHATWG or HTMLWG lists, so that the spec can be changed. I doubt that this change could be made without breaking pages, though.)
Updated•17 years ago
|
Severity: normal → enhancement
Summary: <meta http-equiv> should be restricted to the document <head> per HTML5 → Ignore <meta> tag outside of <head> (XSS mitigation)
Comment 6•17 years ago
|
||
Afaict, in list item nr. 22, the browser can do what it wants.
Mozilla also allows javascript: and data: urls. Perhaps those should be disallowed, at least.
Comment 7•17 years ago
|
||
I assume you mean item 22 in
http://www.whatwg.org/specs/web-apps/current-work/#refresh
That only applies to meta refresh, which is only one of several ways to XSS with a <meta> tag.
Comment 8•17 years ago
|
||
> Thus this bug is INVALID. It's wrong for documents to have <meta> elements
> outside of the <head>, but that has no bearing on what browsers are to do.
I don't follow. If it's wrong and the browser wants to enforce it for whatever reason (as an XSS mitigation in this case) why is it invalid? Maybe it'll be wontfix if we think it'll break too many sites, but invalid? Seems worth considering as an enhancement.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: Ignore <meta> tag outside of <head> (XSS mitigation) → Ignore <meta http-equiv> tag outside of <head> (XSS mitigation)
Comment 9•17 years ago
|
||
Hixie thinks this will break too many sites. Any site with text before "<head>", and a meta http-equiv charset, for example.
WONTFIXed per the HTML5 spec. If you disagree, please file a bug against the HTML5 spec in the W3C's Bugzilla.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•