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)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: oueki, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

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
Blocks: 301375
Component: Security → HTML: Parser
Product: Firefox → Core
QA Contact: firefox → parser
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.
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
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
(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.)
Severity: normal → enhancement
Summary: <meta http-equiv> should be restricted to the document <head> per HTML5 → Ignore <meta> tag outside of <head> (XSS mitigation)
Keywords: testcase
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.
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.
> 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)
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 ago16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: