11337 2010-11-17 19:07:06 +0000 Some ASCII-compatible encodings have harmless substitutions 2011-08-07 11:36:39 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED WONTFIX P2 normal --- 1 yuhongbao_386 ian annevk ayg ian kennyluck mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 42592 0 yuhongbao_386 2010-11-17 19:07:06 +0000 "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. 42594 1 annevk 2010-11-17 19:14:36 +0000 Per https://bugs.webkit.org/show_bug.cgi?id=24906 that is false. 42595 2 yuhongbao_386 2010-11-17 19:18:49 +0000 Yes, some platforms do hack fonts so U+005C has the glyph of Yen sign. 42596 3 annevk 2010-11-17 19:25:23 +0000 When it happens at the font-level the vulnerability is not the same, because all encodings are similarly affected. 42597 4 yuhongbao_386 2010-11-17 19:27:24 +0000 (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. 42598 5 annevk 2010-11-17 19:30:06 +0000 Your point is about the encoding doing a substitution, but as I pointed out the encoding does no such substitution. 42601 6 yuhongbao_386 2010-11-17 19:35:31 +0000 (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. 42620 7 ayg 2010-11-18 22:13:48 +0000 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. 43680 8 ian 2010-12-31 04:05:17 +0000 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. 53808 9 mike 2011-08-04 05:17:32 +0000 mass-move component to LC1