You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Trifecta does not generally check that the string values it receives in POST requests are valid UTF-8, instead passing along the bytes as-is. SQLite will for the most part do the same. However, nlohmann's json will not, and cannot per JSON spec; instead, it will throw on invalid sequences, causing any GET endpoints that try to include bad UTF-8 in their JSON responses to fail.
For robustness, it may be better to already refuse POST requests that have these invalid values, before storing the values in the database. Actual browsers will not make these kinds of requests.
An example that does not require authentication, but which does need direct access to Trifecta (so without nginx), would be the following:
After this request, the admin panel's sessions table would now include the attacker-provided X-Real-Ip value, but this is invalid. The app logs:
/all-sessions: exception for An error occurred: [json.exception.type_error.316] invalid UTF-8 byte at index 1: 0x28
And the UI appears broken:
Other examples would be e.g. putting invalid UTF-8 into post titles, image captions, user-agent headers, email addresses, and so on, but those would require authentication.
The text was updated successfully, but these errors were encountered:
Note that if exceptions are thrown with messages that contain invalid UTF-8, this will cause the process to abort: the exception handler tries to turn the exception into JSON, which then throws.
For instance, if you have an admin session, you can do:
Attemping to set password for user �(
/change-password: exception for An error occurred: Tried to change password for user '�(', but does not exist
terminate called after throwing an instance of 'nlohmann::json_abi_v3_11_2::detail::type_error'
what(): [json.exception.type_error.316] invalid UTF-8 byte at index 55: 0x28
zsh: IOT instruction (core dumped) ./build/trifecta --rnd-admin-password=continue
Of course, admin users can POST to /stop anyway which has roughly the same effect, so as far as I can tell this does not really let users do anything they couldn't do before.
Trifecta does not generally check that the string values it receives in POST requests are valid UTF-8, instead passing along the bytes as-is. SQLite will for the most part do the same. However, nlohmann's json will not, and cannot per JSON spec; instead, it will throw on invalid sequences, causing any GET endpoints that try to include bad UTF-8 in their JSON responses to fail.
For robustness, it may be better to already refuse POST requests that have these invalid values, before storing the values in the database. Actual browsers will not make these kinds of requests.
An example that does not require authentication, but which does need direct access to Trifecta (so without nginx), would be the following:
After this request, the admin panel's sessions table would now include the attacker-provided
X-Real-Ip
value, but this is invalid. The app logs:And the UI appears broken:
Other examples would be e.g. putting invalid UTF-8 into post titles, image captions, user-agent headers, email addresses, and so on, but those would require authentication.
The text was updated successfully, but these errors were encountered: