Discover more from h0wl's blog

The importance of Web UI security in decentralised applications

Abusing front-end to trick users into performing unintended interactions with the smart contract

Pawel Wylecial

Jan 25, 2023

What is Starknet.id

Starknet.id describes itself as:

All in one identity service on starknet

Basically users can create their Starknet identities and in addition to that buy/mint domains ending with .stark extension similar to ENS domains on Ethereum.

The web interface for managing Starknet identities and domains is available on mainnet or testnet and the code is hosted on GitHub.

Bug discovery

I was looking around the web application and noticed something weird on one of my test accounts I had a domain already registered.

Here’s the domain:

Unsurprisingly when searching for that domain it shows that it is already taken:

Please note that the domain name is passed via the query string in the URL. If we change its value to mixed upper and lower case characters we get an interesting result:

There are a couple of things here:

The value of domain parameter in the query string is WiNtErMuTe
The domain is shown as available to purchase
The domain is shown as all lower case in the UI availability bar

It’s not in the screenshot but after clicking ‘Register from L2’ the following value for domain is submitted to the smart contract:

Felt (field element) is a type specific to the Cairo language used in smart contract development for Starknet. After we decode the value of 9463262 (using e.g. this helper script) we receive the following value:

python3 ./decoding.py 9463262        
encoded: itrue

It appears that all the capital letters from the word WiNtErMuTe were silently removed before submitting the transaction. So how this could be abused in practice ?

Practical attack scenario

Mallory prepares a specially crafted URL like the one below
```
https://goerli.app.starknet.id/search?domain=vItalik
```
Notice the first letter ‘i’ is capital.
Mallory sends the link to an unsuspecting user, telling him that a popular/rare domain is available to buy.
Users views it and tries to buy

Due to specific encoding the transaction data is obfuscated and and looks like below so its really hard to tell by a regular user.
After transaction is approved the user ends up with a different domain than he thought he was buying and most likely not so good of a deal:
```
python3 ./decoding.py 809637103
encoded: vtalik
```

Fix

GitHub issue #102 - this is a variation of the described bug related to subdomains that I reported previously which created a false sense that someone else’s domain could be bought.

GitHub issue #103

I reported both bugs privately on 18 January 2023 directly to one of the project maintainers. The issues were fixed within hours from the submission both for testnet and mainnet.

Conclusion

Insufficient user input validation or encoding data on output may result in undefined behaviour and even potential loss of funds. In the described case impact is limited to trolling users into buying into ‘worthless’ NFTs however in general classic web application vulnerabilities can have a severe impact on Web3 applications. Cross-Site Scripting is a good example, especially stored ones that have a potential to be wormable - it could result in draining user’s wallets as for example described in this blogpost by Check Point. When creating decentralised application it is important not only to focus on the smart contracts security but also the front-end as it is also an attack vector.