Overall security testing of the app

[EvgeniiaVak]

Try to find a way to hack our website. The aim of this issue is to explore different attacks so that we know (not hope) that we build a safe trading platform. If we happen to be among the first live DEXes on Radix we will be the first to get attacks, potentially ruining our reputation if hackers are successful.

Radix boasts that it handles a lot of security concerns for developers. That is all nice and dandy but we are a DEX - a place where people exchange money, we are responsible for it to be not exploitable (or at least try to).

We have an interesting situation on a boundary of web2 and web3 tech stacks - we are not completely web3 app, we depend on AlphaDEX API which has lots of web2 components to it. But we (DeXter itself) have only a static website and don't have any server-side capabilities (all our code is exposed to the browser).

This is an epic issue, please create and list here in the description new sub-issues for each possible attack direction.

---

• [ ] define who controls what (double check the current holder's security)- when and how to transition to multisig

[EvgeniiaVak]

Wallet stays logged in with a new build

A suspicious thing that I noticed while compiling the build, that might potentially mean a security breach source, if for example somebody takes our code, changes it a little bit, pretends it our page but does something nasty under the hood. Here are the steps to reproduce the same thing at e7cda3341eb870f6147e72f18c38679f7983d7b1 :

1. build the site: npm run build (it will create the out folder that contains the website)
2. serve the website somehow, for example with npx serve out
3. connect to radix via the extension and wallet app
4. shut down the website and rebuild (npm run build) with something new in the code( I inserted in src/app/layout.tsx just under the NavBar:

               <button
                 onClick={() => {
                   console.log("clicked");
                 }}
               >
                 JUST TO TEST
               </button>

5. serve the new version and observe the connected button is still logged in with the same persona

This feature is very useful during development, but maybe can be turned off somewhere in the radix dapp toolkit for production builds. Maybe it's not an issue if we host with https on traditional servers, probably it won't stay logged in if the hacker just steals the code and hosts some other domain?.. Needs more investigation some day. Also what if we host on something like IPFS?

[EngineerCharlie]

probably it won't stay logged in if the hacker just steals the code and hosts some other domain?

I can confirm, that when changing the localhost port with identical code the wallet does not stay logged in on the different port, but does stay logged in when coming back to the correct port. This is from switching between serving on 3000 and 3001.

However, there is no indication that you've signed into to the same dApp definition address with a different URL.

[EngineerCharlie]

A suspicious thing that I noticed while compiling the build, that might potentially mean a security breach source, if for example somebody takes our code, changes it a little bit, pretends it our page but does something nasty under the hood.

If someone creates a phishing website pretending to be DeXter, we are essentially relying on the Wallet's inbuilt security measures. The key one will be in the dApp definition. From the "Manage dApp Definition" dashboard page:

Linked Websites

Configuring your dApp Definition with the websites your dApp uses is a requirement of the Radix Wallet so that it it can catch “fake” websites claiming to be part of your dApp. Option to add a "trusted" URL below, URL must start with https

From setting up you dapp definition:

Linked websites - Here, you can claim ownership of your dApps website(s) for authenticity. This is confirmed by looking up an expected .well-known/radix.json file at the claimed website origin. This will be required for your dApp to successfully send requests to the Radix Wallet at mainnet, but this is currently ignored on RCnet v3. More information about configuring the well-known file on your website is coming soon.

So my understanding here (though I'm unable to test) is that someone impersonating the website with a different URL would not be able to use the DeXter dapp definition address at all, meaning the wallet would simply not give them the option to sign in.

So an attacker could still impersonate the whole DeXter front end, but the wallet would prompt them that this is the first time using the fake dapp address (as opposed either staying logged in or reminding them when the last time they interacted with the dapp was).

Where does this leave us?

Our security with regards to phishing all comes down to the built in defences of the Radix Wallet, and a tiny bit of user familiarity with how the workflows of the wallet should go. I guess we should address the education aspect in the gitbook?

In terms of an attacker somehow changing the front end on the actual dexter URL, the RDT does not appear to provide functionality to assess whether a websites source code has changed. There are still some protections afforded by the wallet (ie the transaction manifest), but fundamentally an attacker could use the DeXter dapp address but create a malicious transaction with fake tokens/a limit order to a fake component.