W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > April 2009

[Bug 6774] <mark> element: restrict insertion by other servers

From: <bugzilla@wiggum.w3.org>
Date: Mon, 20 Apr 2009 10:23:29 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Lvqev-00063E-EN@wiggum.w3.org>

--- Comment #2 from Lachlan Hunt <lachlan.hunt@lachy.id.au>  2009-04-20 10:23:29 ---
(In reply to comment #0)
> ... I replied: "HTML5's role in a security breech would come if it grants
> permission to system designers, as I saw in this statement: 'Another example
> of the mark element is highlighting parts of a document that are matching
> some search string. If someone looked at a document, and the server knew that
> the user was searching for the word "kitten", then the server might return
> the document with one paragraph modified as follows: . . .
> . <mark>kitten</mark> . . . .' Section 4.6.7. That looks like permission for
> the server to interject markup into a byte stream.

I really do not understand the source of your confusion, but HTML5 certainly
does not give permission for any kind of security breach like you describe. 
The technique that the spec is discussing is something that people have already
implemented on their own servers, often using elements like <span> or <b>.

See, for example, this article that discusses how to obtain search terms from
the HTTP Referer header and dynamically modify the page using some PHP.  This
is entirely under the control of the site's developers.  There is no
unauthorised access by 3rd parties.


Besides, if a 3rd party could inject markup into a site, there are bigger
problems than just being able to insert the <mark> element, like the insertion
of <script> elements that many attackers already do today.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 20 April 2009 10:23:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:00:53 UTC