Bug 8027 - Handling of POST data overwrites unicode characters
Summary: Handling of POST data overwrites unicode characters
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.15.0
Assignee: Fredrik
URL:
Keywords: ossman_tester, prosaic
Depends on:
Blocks:
 
Reported: 2022-11-16 09:35 CET by Linn
Modified: 2022-11-22 16:22 CET (History)
1 user (show)

See Also:
Acceptance Criteria:
*Should provide an error message if an invalid character is inserted.


Attachments

Description Linn cendio 2022-11-16 09:35:16 CET
All our POST data should come in a valid format, i.e. only allowed characters. 

Right now, we are replacing invalid characters with '�'. These invalid characters are unexpected and not what we want, so it is better to give an error message when provided invalid characters.
Comment 3 Fredrik cendio 2022-11-21 13:43:26 CET
This is fixed now and this is the test command I used. 
curl -k -d "username=someuser&display=10&auth_cookie=%f0&launch_vnc=1" https://localhost:300/agent

The error message is expected to be 400. When %f0 is inputted in the request, it should give an error instead of invalid characters with '�'.
Comment 4 Pierre Ossman cendio 2022-11-22 09:45:57 CET
The same code exists in tlwebadm, so we should have the same fix there.

Perhaps time for a helper method?
Comment 5 Fredrik cendio 2022-11-22 14:47:39 CET
This line of curl can be provoked in the tlwebadmin:
curl -k -u username:password -d "order=x%fce" https://localhost:1010

The error message is expected to be 400. When %f0 is inputted in the request, it should give an error instead of invalid characters with '�'.
Comment 8 Pierre Ossman cendio 2022-11-22 16:22:02 CET
Works well. tlwebadm and tlwebaccess will now give me 400 for:

 * Blatantly invalid UTF-8 (e.g. a stray 0xf0)
 * ISO 8859-1
 * Surrogate code points (correctly encoded as UTF-8)
 * Invalidly large code points (correctly encoded as UTF-8)

But it will gladly proceed correctly with:

 * ASCII
 * Other latin characters encoded as UTF-8 (e.g. "ö")
 * Unicode replacement character
 * Private code points

Code looks good. Unit tests look good. Closing.

Note You need to log in before you can comment on or make changes to this bug.