[ 
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 codepoint 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 -- 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 codepoint in 
> question is a surrogate pair.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to