[
https://issues.apache.org/jira/browse/GUACAMOLE-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Percival updated GUACAMOLE-1972:
--------------------------------------
Description:
When accepting input from the browser, Guacamole will try and convert the
UTF-16 buffer provided by Javascript into UTF-8 bytes. However the parser does
not take into account surrogate pairs -- meaning that any Unicode codepoint
greater than U+FFFF (e.g. most of the emoji range) will be wrongly treated as
two UTF-16 characters, resulting in an invalid byte sequence being sent to the
server.
The proposed fix is to use `String.prototype.codePointAt` instead of
`String.prototype.charCodeAt`, along with validation that the character in
question is a surrogate pair.
was:
When accepting input from the browser, Guacamole will try and convert the
UTF-16 buffer provided by Javascript into UTF-8 bytes. However the parser does
not take into account [surrogate
pairs|[https://en.wikipedia.org/wiki/UTF-16#Code_points_from_U+010000_to_U+10FFFF]]
- meaning that any Unicode codepoint greater than U+FFFF (e.g. most of the
emoji range) will be wrongly treated as two UTF-16 characters, resulting in an
invalid byte sequence being sent to the server.
The proposed fix is to use `String.prototype.codePointAt` instead of
`String.prototype.charCodeAt`, along with validation that the character in
question is a surrogate pair.
> Client incorrectly handles Unicode codepoints greater than U+FFFF
> -----------------------------------------------------------------
>
> Key: GUACAMOLE-1972
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1972
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-client
> Reporter: Scott Percival
> Priority: Minor
>
> When accepting input from the browser, Guacamole will try and convert the
> UTF-16 buffer provided by Javascript into UTF-8 bytes. However the parser
> does not take into account surrogate pairs -- meaning that any Unicode
> codepoint greater than U+FFFF (e.g. most of the emoji range) will be wrongly
> treated as two UTF-16 characters, resulting in an invalid byte sequence being
> sent to the server.
> The proposed fix is to use `String.prototype.codePointAt` instead of
> `String.prototype.charCodeAt`, along with validation that the character in
> question is a surrogate pair.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
