Isn’t frontend delivered to the browser through query calls, is it?
If so, then the frontend can be hacked by a malicious replica for example, to steal money in a swap dapp.
How to protect users of my dapp from this? How to protect myself from this attack in the dapps that I use?
The “Response Verification” answers your question and resolve your security concern.
See documentation:
@peterparker I didn’t read this long “Response Verification” document in full, but the question remains: Can’t a malicious owner of a HTTP gateway skill all steps of verification and present the user a different site without any verification headers?
Modern browsers, AFAIK, don’t check verification headers, so it can go unnoticed, can’t it?
@NathanosDev can answer better than I can. My understanding is that you can either choose to install a proxy on your end to verify the certification or trust the boundary node proxy to perform the certification validation for you. In both cases, malicious actors would be detected.
Why should I trust it?
Isn’t the boundary node proxy controlled by some random Internet user?
For example:
As mentionned there is a proxy you can install on your hand.
There used to be a service worker that would detect improper files, but I think that has been deprecated. There was a proxy you can run at one point but I have’t heard much about it lately.
Just to clarify the service worker wasn’t a bullet proof solution either since the gateway could simply serve a frontend that replaces the service worker without the service worker being able to block it. (There’s a W3C discussion regarding this).
From above W3C discussion you can also see that even if you could block forced service worker updates from a server, new users would still receive the malicious frontend.
The only cryptographically secure way would be to run your own local gateway that was introduced somewhere on this forum.
The previous replies cover it already quite well and I just try to summarize it:
I need to start one step earlier: What allows you to access a dapp hosted on the IC directly from your browser is the HTTP gateway. At a high-level, the HTTP gateway transforms the HTTP request coming from your browser into a query call and the response from the canister back into an HTTP response.
When this translation happens, the HTTP gateway has to somehow check that the query response has not been tampered with by a malicious node. The key to that is response verification: basically, the query responses come with a certificate signed by the subnet ensuring that no malicious node can tamper with them. You can find a high-level description of that here.
At this point, all is good, if you trust the HTTP gateway. The boundary nodes are one such gateway. However, it is not the only one and you can run your own HTTP gateway locally using the IC HTTP proxy (announcement and code). Why should you trust it? You can verify the code and run that exact code on your machine. You are in full control and can access dapp frontends without having to trust anyone.
The service worker was another implementation of the HTTP gateway. However, we decided to drop that as it didn’t improve security as compared to running the HTTP gateway on the boundary nodes, but came with a lot of downsides for the devs. If you want to know more check this thread.