Escape "<" and ">" when serializing attribute values #6362
Conversation
7dfae8b to
ac056b2
Compare
|
@zcorpan Thank you for nudging this along! Did you spend any time thinking about compat analysis? Mostly curious, I've never done any compat analysis.. |
|
@mozfreddyb I did think about it. I think static analysis is unlikely to find anything. What is possible is to add a use counter in Chromium (or equivalent in other engines) when the HTML serializer serializes an attribute value that contains "<" or ">". When the use counter reaches stable, the next HTTP Archive crawl will collect URLs from its data set of around 7 million pages, which can be queried with BigQuery. If there is an experimental implementation of this change, one can manually test those URLs and see if anything is obviously broken. If this quickly finds multiple things that are broken, then it likely is not a web compatible change. If nothing broken is found, then it might be web compatible, but obviously this wouldn't be a guarantee. The lack of complaints during the dev and beta period is probably a more convincing signal that it is web compatible. |
…in attribute values, a=testonly Automatic update from web-platform-tests HTML: tentative test for serializing <> in attribute values See whatwg/html#6362 -- wpt-commits: c5d4ba83796ad90ea175682d9e4477656fc5ddb5 wpt-pr: 51827
…in attribute values, a=testonly Automatic update from web-platform-tests HTML: tentative test for serializing <> in attribute values See whatwg/html#6362 -- wpt-commits: c5d4ba83796ad90ea175682d9e4477656fc5ddb5 wpt-pr: 51827
…in attribute values, a=testonly Automatic update from web-platform-tests HTML: tentative test for serializing <> in attribute values See whatwg/html#6362 -- wpt-commits: c5d4ba83796ad90ea175682d9e4477656fc5ddb5 wpt-pr: 51827
|
The Firefox/Gecko implementation was/is: https://bugzilla.mozilla.org/show_bug.cgi?id=1941347 |
Avoid a class of XSS attacks where markup goes through
a lossy parse-serialize-parse roundtrip and the original
attribute value is parsed in the data state.
This reverts 4eeb8a1.
Fixes #6235.
(See WHATWG Working Mode: Changes for more details.)
/parsing.html ( diff )