Browser-in-browser will make the site much safer.
First of all, I will explain that this technology is at an early stage of development, and I would like to discuss in this topic about its profitability and usefulness. Therefore, there is no prototype yet.
Most of the vulnerabilities in web sites are the result of an HTTP request change, URL spoofing or headers, and other unexpected server actions. A regular user should not be able to do this, but since a modern application consists of a client and a server, in reality the server does not have control over how the user uses the client side.
Because of this, "double validation" is ubiquitous - on the screen you need to show only the objects available to the user, plus you need to check on the server whether the user has access to this object.
')
Thus, the idea of SecureCanvas arose - to turn the site into a kind of ATM / terminal, where the user can only type and move the mouse. Instead of trying to intercept malicious requests, we simply transfer the game to another plane and reduce the attack surface to zero, allowing the user to do only what he should do - interact with the site.
Now when a user wants to download bank.com, this site is loaded in a virtual and cheap webkit instance in the cloud, and the synchronizer page is returned to the user. This page transmits all clicks and clicks to the cloud using a web socket, and in the cloud these actions are performed in a real browser. Thus, it is simply impossible to open the console, view requests or source code.
At first, the idea was to implement this on the basis of the VNC session and the canvas element, so that the cloud browser would return the image of the site itself. But this idea is doomed to failure - the quality of the picture is deteriorating, the fonts are smeared and the network delay is not pleasant to users. Therefore, a more promising approach is when the cloud browser sends special DOM snapshots of the page and diffs with previous snapshots (similar technology is used in React.js for other purposes).
Thus, the responsiveness of the site will remain at the same level - in front of you will be the same tangible and well-traced tags, but the background that you type or click will be transferred to the cloud browser and only there Javascript logic will generate requests to the real bank.com server and change the external page view.
There will also be a validator URL to protect against address spoofing. You can simply prohibit the use of your URL and download only the root address - this is ideal for online banks. You can sign each address HMAC, so only the name of the signature you can download the address you need (you can not open / private_info / 2 - SIGN without having a SIGN for this address, and SIGN is issued only after clicking on this link in the interface). Or the most convenient option is to load only the addresses that were loaded earlier (as a result of interaction with the interface).
The only thing SecureCanvas cannot protect against is interface-based vulnerabilities. If the attack can be carried out using only the interface of the site - enter 'or 1 = 1 in the username or conduct brutofors - then nothing will help this site.
The technology is absolutely realizable, it remains to solve the issue with the target audience (online banks and other financial services come to mind) and investments - we really need them. By the way, if the idea seemed nonsense (and I can understand you), first look at the technology shape , then for the $ 66M investment made in them. Yes, it is impracticable. Either that they will turn out to be useless. Since without AI it is impossible to understand which requests JS can generate and which not. By the way, the task they have is approximately the same - to prohibit "not intended" interactions with the site through total obfuscation of responses (security through obscurity is doomed to failure)
But SecureCanvas is realizable (not without difficulties, of course), and the benefits are visible to the naked eye even to ordinary people (“this is like a site inside the ATM, under a protective screen”). Let's dream or argue :)
Most of the vulnerabilities in web sites are the result of an HTTP request change, URL spoofing or headers, and other unexpected server actions. A regular user should not be able to do this, but since a modern application consists of a client and a server, in reality the server does not have control over how the user uses the client side.
Because of this, "double validation" is ubiquitous - on the screen you need to show only the objects available to the user, plus you need to check on the server whether the user has access to this object.
')
Thus, the idea of SecureCanvas arose - to turn the site into a kind of ATM / terminal, where the user can only type and move the mouse. Instead of trying to intercept malicious requests, we simply transfer the game to another plane and reduce the attack surface to zero, allowing the user to do only what he should do - interact with the site.
Now when a user wants to download bank.com, this site is loaded in a virtual and cheap webkit instance in the cloud, and the synchronizer page is returned to the user. This page transmits all clicks and clicks to the cloud using a web socket, and in the cloud these actions are performed in a real browser. Thus, it is simply impossible to open the console, view requests or source code.
At first, the idea was to implement this on the basis of the VNC session and the canvas element, so that the cloud browser would return the image of the site itself. But this idea is doomed to failure - the quality of the picture is deteriorating, the fonts are smeared and the network delay is not pleasant to users. Therefore, a more promising approach is when the cloud browser sends special DOM snapshots of the page and diffs with previous snapshots (similar technology is used in React.js for other purposes).
Thus, the responsiveness of the site will remain at the same level - in front of you will be the same tangible and well-traced tags, but the background that you type or click will be transferred to the cloud browser and only there Javascript logic will generate requests to the real bank.com server and change the external page view.
There will also be a validator URL to protect against address spoofing. You can simply prohibit the use of your URL and download only the root address - this is ideal for online banks. You can sign each address HMAC, so only the name of the signature you can download the address you need (you can not open / private_info / 2 - SIGN without having a SIGN for this address, and SIGN is issued only after clicking on this link in the interface). Or the most convenient option is to load only the addresses that were loaded earlier (as a result of interaction with the interface).
The only thing SecureCanvas cannot protect against is interface-based vulnerabilities. If the attack can be carried out using only the interface of the site - enter 'or 1 = 1 in the username or conduct brutofors - then nothing will help this site.
The technology is absolutely realizable, it remains to solve the issue with the target audience (online banks and other financial services come to mind) and investments - we really need them. By the way, if the idea seemed nonsense (and I can understand you), first look at the technology shape , then for the $ 66M investment made in them. Yes, it is impracticable. Either that they will turn out to be useless. Since without AI it is impossible to understand which requests JS can generate and which not. By the way, the task they have is approximately the same - to prohibit "not intended" interactions with the site through total obfuscation of responses (security through obscurity is doomed to failure)
But SecureCanvas is realizable (not without difficulties, of course), and the benefits are visible to the naked eye even to ordinary people (“this is like a site inside the ATM, under a protective screen”). Let's dream or argue :)
Source: https://habr.com/ru/post/248761/
All Articles