How are websites on Dappy more secure than legacy websites ?
Dappy is a blockchain based web applications distribution network, and a browser that implements the associated protocol. In contrast with legacy web browsers, Dappy browser includes by default high protection and strict policies with respect to what a web application is allowed to do, which servers it is allowed to reach. In this article we will explain how it works, and why it is a much more secure way to distribute web applications on Dappy rather than legacy web.
To facilitate the understanding of this article, you may want to get familiar with dapps and IP applications, the two main applications on Dappy.
Note: the features described are already implemented, functional and used by many web applications deployed on the Dappy beta network.
A website, sometimes called web application, is a HTML document distributed by a server through the internet network and the HTTP protocol, or HTTP + SSL (with encryption) protocol. This HTML document often includes some javascript code. HTML, CSS (style) and javascript code can be interpreted by web browsers. Javascript code and execution is a powerful tool, it can manage content disposition, create user interfaces, capture user interactions, read in local storage, send data to any server, load external content, some specific HTML tags can also load some external content.
In legacy web, the Domain Name System is an attack vector, but once the website is loaded, illegitimate interference, thefts, hacks by malicious third parties can still occur.
Subresource corruption
A web application sometimes need to load external libraries from a different domain, a javascript from cdnjs.com, or an google analytics script are two examples. The web developer has no control over this code, he must trust the third party that this code does - and will always do - what it is expected to do. If the final server gets hacked, or the DNS chain is somehow corrupted, a malicious hacker can do whatever he wants with the user’s personal data. A simple way to avoid it is to use checksum (integrity check), but lots of developers still don’t use it, or are not aware of it (according to a swiss report, only 3,40% of web applications that use subresources do integrity check).
# Not good
<script src=”https://cdn.com/library.js"></script>
# Better
<script src=”https://cdn.com/library.js" integrity=”sha384-oqVuAfXRK”></script>
# Even better
<script src=”https://mydomain.com/library.js" integrity=”sha384-oqVuAfXRK”></script>Another recommendation is to host all the code that is used by the web application on the same domain and server, this recommendation is also not always followed, even for websites that deal with sensitive or high value applications.
If a hack occurs through subresource corruption, the hacker will be able to retrieve data from cookies, local storage, browser DB or user actions, and send it to any arbitrary server on the web (probably a server he owns). It is not the case in Dappy we will see why later.
Browser extensions
A browser extension has access to the javascript context and can execute arbitrary code. Extensions can inject ads in the user’s browsing context, this has been seen in hundreds of extensions on chrome browser for example. A more harmful way to exploit these capabilities is to steal private or very sensible data that is input, or stored by users in various websites (bank ID, social networks passwords etc). Website owners have no control over which extension has the right to execute. Most websites do not need extensions, the web developer will probably just hope that users do not install extensions that might turn out to be harmfull.
If an extension is successfully used for malicious purpose, the consequences are the same as above, catastrophic for many web applications.
Web applications policy in the Dappy browser
Dappy is a browser that does not use the Domain Name System (DNS), but a name system based on the blockchain and therefore decentralized. This is not the topic of this article so we will not extend on that, see this article about Dappy and DNS, and this article about dapps and IP apps . Dappy browser, as legacy browsers do, deals with HTML files and with javascript execution.
Unlike legacy browsers, Dappy provides very strict policy regarding what server can be reached by the javascript for XHR calls, or third party content (subresources) loads. The execution context of a web application is constrained by default, and the owner of a name (the entity that would own amazon.com or apple.com in legacy web) can eventually reduce these constraints. It is the opposite of the web standards that are wild west by default (often for backward compatibility reasons), and can eventually be tightened by the server that is reached.
Notice that in Dappy, the name owner is the ultimate authority that governs what the browser will allow the web application to do. In legacy web it is the web server that can eventually send instructions, often through HTTP headers.
A given web application (ex: myapp) is only allowed to reach a set of servers (can be none), those servers are recorded at the name level. The list of server addresses (IP address, host name and SSL certificate) is attached to the name that is stored on a blockchain platform, therefore the name owner is in control of this. Moreover when a server is declared, the IP address must be provided, making it possible for Dappy browser not to rely on the Domain Name System which constitutes also an attack vector in many cases.
For example, you own the name myapp on the Dappy Name System (blockchain), of course you want to link it to your server so people can access it, if you don’t have any third party content dependency for other domains or servers, you declare your name with one associated server the following way:
# Stored on the blockchain
{
“name”: “myapp”,
“servers”: [{
“ip”: “12.12.12.12”
“cert”: “ — — — — — BEGIN CERTIFICATE xxxxx”,
“host”: “myapp.com”,
}]
}When the application is loaded on Dappy (could be an IP application or a dapp), the browser will only allow traffic to go to this server, and kill all the other requests. Dappy browser will also perform the necessary operations so that a request addressed to myapp.com (the legacy DNS URL of your application), is in fact transparently sent to 12.12.12.12, with appropriate host name and certificate (encrypted SSL). Your server simply won’t notice anything, but this paradigm in fact does not use the Domain Name System at all. The DNS layer, is again removed in favor of a decentralized, more robust and secure alternative (see Dappy network). Web applications on Dappy do not use the Domain Name System.
# This in Dappy does not use the DNS neither certificate authorities, but does a SSL encrypted request to the corresponding IP address directly
<script src=”https://mydomain.com/library.js" integrity=”sha384-oqVuAfXRK”></script>Also Dappy browser does not provide extension marketplace (yet ?) but when it eventually does, it is highly probable that the name owner (you), will have to declare which extension is allowed to connect to your website.
This is one of the features that makes the Dappy ecosystem generally more robust, and a solution of choice for businesses or organizations that have high security and accuracy requirements.
If you want to know more, discuss this feature or other features with us, you can reach us on Discord, and also read documentation from the website.
See you around :)
Raphaël
Credits
Bertil Chapuis, Olamide Omolola, Mauro Cherubini, Mathias Humbert, Kévin Huguenin. An Empiri-cal Study of the Use of Integrity Verification Mechanisms for Web Subresources. The Web Conference(WWW), Apr 2020, Taipei, Taiwan. pp.34–45
Steven Van Acker, Daniel Hausknecht, Andrei Sabelfeld, Measuring Login Webpage Security, Chalmers University of Technology
