218018 2020-10-21 05:52:46 -0700 Error handling for ISO-2022-JP is incorrect 2020-10-21 16:04:04 -0700 1 1 1 Unclassified WebKit DOM WebKit Nightly Build Unspecified Unspecified RESOLVED DUPLICATE 218046 https://bugs.webkit.org/show_bug.cgi?id=218046 P2 Normal --- 1 annevk webkit-unassigned achristensen beidson darin mmaxfield oldest_to_newest 1700156 0 annevk 2020-10-21 05:52:46 -0700 See tests added and corrected in https://github.com/web-platform-tests/wpt/pull/26158. In particular it seems 0x0E, 0x0F, and 0x1B are not treated as errors which could lead to XSS in badly constructed sites. (I think a similar problem applies to form submission, but I didn't write tests for that.) (There's also some specification changes for this: https://github.com/whatwg/url/pull/558 and https://github.com/whatwg/encoding/pull/238.) 1700339 1 darin 2020-10-21 13:14:56 -0700 Strange, Alex’s new code in TextCodecCJK::iso2022JPDecode has code like this: if (byte <= 0x7F && byte != 0x0E && byte != 0x0F && byte != 0x1B) { m_iso2022JPOutput = false; result.append(byte); break; } m_iso2022JPOutput = false; return SawError::Yes; Sure looks like that would treat it as an error. Wonder why that’s not working. Or maybe Anne is testing an older version of Safari that used the ICU decoder? 1700373 2 darin 2020-10-21 13:53:06 -0700 Oh, is this encode rather than decode? 1700442 3 achristensen 2020-10-21 16:04:04 -0700 *** This bug has been marked as a duplicate of bug 218046 ***