This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"Encodings in which a series of bytes in the range 0x20 to 0x7E can encode characters other than the corresponding characters in the range U+0020 to U+007E represent a potential security vulnerability:" What this doesn't mention is that some ASCII-compatible encodings like Shift-JIS have harmless substitutions, such as replacing the backslash with the yen sign, which is OK because it is not used much (if at all) in HTML.
Per https://bugs.webkit.org/show_bug.cgi?id=24906 that is false.
Yes, some platforms do hack fonts so U+005C has the glyph of Yen sign.
When it happens at the font-level the vulnerability is not the same, because all encodings are similarly affected.
(In reply to comment #3) > When it happens at the font-level the vulnerability is not the same, because > all encodings are similarly affected. And my point is that it is not a real vulnerability, which is why I am trying to get the standard changed.
Your point is about the encoding doing a substitution, but as I pointed out the encoding does no such substitution.
(In reply to comment #5) > Your point is about the encoding doing a substitution, but as I pointed out the > encoding does no such substitution. On Windows only, where they use hacked fonts instead.
Backslash has special meaning in JS and CSS, which are normally embedded in HTML, so using a character set where that byte has a different meaning could indeed lead to vulnerabilities.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Anytime this happens it can lead to a vulnerability, because code that expects something to do one thing may find it does another.
mass-move component to LC1