Security pitfalls of using JSON in transaction confirmation

[abacabadabacaba]

Currently, when an app issues a transaction, a user is presented with a confirmation dialog. This dialog shows transaction call data, encoded as JSON. The assumption is that if a malicious app issues a transaction that does something that the user would not want to do (e.g. send all of the user's tokens), the user will see this and refuse to confirm.

I claim that this is not true. There is a number of ways an attacker can produce a JSON encoding that will confuse the user and mislead them about what is actually encoded. Here is an example: suppose that an input has a single field named amount, which is a number. So,

{
    "amount": 100
}

represents a call with amount set to 100. Now, look at this one:

{
    "аmount": 100                                                                 ,"\u0061m\u006f\u0075nt":1000
}

At the first glance, the value is 100. However, if you look more carefully, you will notice that the actual value is 1000.

This example is very primitive, and also quite obvious because the entire input is pretty small. In the real cases, when there are multiple fields, a sophisticated attacker may construct confusing inputs such that it is much more difficult to notice that something is not right, especially for the users who are not experts. Here are some of the techniques that can be used for that:

• Confusing field names Generally, when deserializing JSON values, unrecognized fields are ignored. An attacker can include fields that don't really exist but such that the user may think that they do, confusing the user. For example, if the real field is amount, an attacker may include the field sendAmount. Then, an attacker can include the real field later, possibly using one of the techniques listed below to hide it.
• Misspelt field names and values An attacker may deliberately misspell field names, preventing them from being recognized. Similarly, an attacker can misspell important values (e.g. destination account ID).
• Using spaces to create confusing layout Like in the example above, an attacker can use spaces to push the important parts somewhere where the user is unlikely to see them.
• Similarly-looking characters (homographs) Many characters in Unicode look the same or almost the same. For example, the character “ looks very similar to a quotation mark but is not recognized as such by JSON, so it can be used to mislead the user as to where a string value begins or ends.
• Invisible characters There are characters that are invisible, such as zero-width space. Invisible to the user, that is.
• Special characters Some characters are weird. For example, right-to-left override forces the following characters to be displayed in the reverse order, completely confusing the user.
• Unicode escapes JSON allows Unicode escapes (like \u1234), which can be used to hide the actual keys and values.

By combining all these techniques, an attacker may be able to make the user sign something that they would not want to. The best way to fix this is to get the schema of the call from some trusted source (e.g. from the contract being called) and to display the values according to this schema. For example, if the schema specifies the field name to be amount and its type to be number, the confirmation could display the name from the schema and the value re-formatted as a number, thus preventing all of the attacks listed above.

[vgrichina]

Well the idea over the time is definitely to parse the stuff in arguments before presenting it to user. However it is logistically hard to implement everywhere at once. Like e.g. Ledger app is extremely slow to release update and we cannot do anything about it. Given that we don't even have token standard approved – it'll take a while before we can show more specific info for token transfers in Ledger app.

[vgrichina]

The best way to fix this is to get the schema of the call from some trusted source (e.g. from the contract being called) and to display the values according to this schema.

this is generally not viable for hardware wallets

[vgrichina]

• Confusing field names Generally, when deserializing JSON values, unrecognized fields are ignored. An attacker can include fields that don't really exist but such that the user may think that they do, confusing the user. For example, if the real field is amount, an attacker may include the field sendAmount. Then, an attacker can include the real field later, possibly using one of the techniques listed below to hide it.
• Misspelt field names and values An attacker may deliberately misspell field names, preventing them from being recognized. Similarly, an attacker can misspell important values (e.g. destination account ID).

not sure how this isn't a problem with any other format unless you actually hardcode UI for specific type of the call. Misspelled accounts are a problem even if format has strict schema.

• Using spaces to create confusing layout Like in the example above, an attacker can use spaces to push the important parts somewhere where the user is unlikely to see them.
• Similarly-looking characters (homographs) Many characters in Unicode look the same or almost the same. For example, the character “ looks very similar to a quotation mark but is not recognized as such by JSON, so it can be used to mislead the user as to where a string value begins or ends.
• Invisible characters There are characters that are invisible, such as zero-width space. Invisible to the user, that is.
• Special characters Some characters are weird. For example, right-to-left override forces the following characters to be displayed in the reverse order, completely confusing the user.
• Unicode escapes JSON allows Unicode escapes (like \u1234), which can be used to hide the actual keys and values.

By combining all these techniques, an attacker may be able to make the user sign something that they would not want to. The best way to fix this is to get the schema of the call from some trusted source (e.g. from the contract being called) and to display the values according to this schema. For example, if the schema specifies the field name to be amount and its type to be number, the confirmation could display the name from the schema and the value re-formatted as a number, thus preventing all of the attacks listed above.

We can detect these tricks and highlight to user they are likely getting scammed. Thanks for highlighting these, I think they also going to be problem with say account names (or any other strings) even if format has schema, so we need to be ready.

[vgrichina]

Just to clarify: using JSON in transaction confirmation is solely "better than nothing" approach, vs what is intended to be long-term. Standard operations like custom token transfer will definitely have to get task-specific UI.

Or at least task-specific subformat – like if we are passing token amounts with 18 zeros – it actively doesn't help eyeballing it's valid.