Bug 218018 - Error handling for ISO-2022-JP is incorrect
Summary: Error handling for ISO-2022-JP is incorrect
Status: RESOLVED DUPLICATE of bug 218046
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-21 05:52 PDT by Anne van Kesteren
Modified: 2020-10-21 16:04 PDT (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Anne van Kesteren 2020-10-21 05:52:46 PDT 
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.)
Comment 1 Darin Adler 2020-10-21 13:14:56 PDT 
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?
Comment 2 Darin Adler 2020-10-21 13:53:06 PDT 
Oh, is this encode rather than decode?
Comment 3 Alex Christensen 2020-10-21 16:04:04 PDT 

*** This bug has been marked as a duplicate of bug 218046 ***