4 ms·

Question: I guess this is good way to access possible malicious web sites, how does it work in background what happens with server? I mean except obvious Testi

Question: I guess this is good way to access possible malicious web sites, how does it work in background what happens with server? I mean except obvious Testing purpose usage, as many other tools give (Puppeteer, Selenium, WebDriver ...).

graderjs 5y ago
I guess there's a couple of cases to consider. The first is a malicious website that uses ph/fishing or some other social engineering type attack. Unless that attack also included the need to download some sort of payload file to create a back door or whatever this additional barrier would not provide any protection against social engineering type attacks. Another case is where there's a link in email to download a payload file that's like a word document or PDF that contains some sort of exploit that will you know initiate it take over on the user's computer. I guess a lot of them will be protected again by using a barrier like this because those files are downloaded to a separate server and then converted into images and then displayed back over the web so the client only receives an image of each page of that document and the document itself is never executed except that it's converted to images. Another case is a malicious website that uses a browser zero day or other type of exploit that enables remote code execution or sandbox escape in a browser. In that case you probably be protected by using this barrier because the only thing you're getting from the remote website is pixels of screenshots and any exploit that occurs will execute on the remote server. Here are the weaknesses is in the current setup. In order to successfully take over the remote server the exploit needs to escape the browser sandbox achieve remote code execution and achieve privilege escalation. I'm sure that's possible so it's not totally secure with respect to the server itself being pawned and then of course everybody who's using the server becomes vulnerable. So by no means is it perfect and from that point of view it's quite weak but from the point of view of the other cases it's quite a strong barrier. On the server every browser instance runs in its own temporary user. That user is no login user whose processes and home directory only exists for the duration of the browser session. And that user has limits on the amount of memory and CPU and disk space it can use. So from that point of view this system is relying on existing Unix process isolation and user privilege isolation to provide a layer of security on the server. In addition to that the controller server of every browser instance is a separate process for each client, on that separate process is run under that temporary user assigned to that client. So each controller server only how's the privileges of that temporary user, it only talks to that client and to that browser and every public API endpoint is authenticated. In addition the internal chrome remote debugging ports are prevented from being accessed from the outside web and other iptables rules drop packets on Google compute engine internal network endpoints. The reason I didn't wrap each browser instance inside a docker container to add yet another barrier and require the chaining together of yet another exploit is because it was a trade-off and I don't think it was worth it between the extra effort and overhead of running inside docker versus running inside a lightweight operating system sandbox using cgroups and temporary users. With that being said I have a couple of ideas on improving security if that's needed. Firstly rather than using the latest Linux server I could use SELinux and add additional hardening. Secondly I could like I mentioned before wrap each browser instance in its own docker container to require a container escape exploit to be chained together as well. Thirdly I could fall back on the security of Google cloud to use instance level isolation and require a hypervisor escape to compromise anything but the temporary virtual private server. In other words each browser instance could run on its own tiny VPS. The con side of the trade-off equation in each of these has been: no demand for it, and high cost in terms of application performance, implementation time, additional complexity and or money. For instance running each browser on its own tiny VPS would incur both an additional complexity and implementation cost as well as cut the performance because on average the performance of a tiny VPS is less good than the amortized same amount of processes on a much larger machine. In addition to that VPS bandwidth scales with number of processors, and bandwidth is a key component of the performance equation in this application. Even at the same raw number of processes and amount of memory than a larger machine I guess the money cost would be higher to run multiple tiny machines, and it would certainly be higher when each instance was enlarged to match the amortized performance available using a larger machine. hopefully that answers your question I'm sorry if it wasn't totally related to what you're wanting to know. Tho at the same time I'm pretty sure someone else'll find that information useful. Thanks for asking.
- NiceWayToDoIT 5y ago
  Thank you for the extensive answer, as it is paid service, I would only suggest you pay a bit of money for someone on 99Design to fix your styles. I would love to read more about architecture but as it is commercial product, I understand that is kind of trade secret. How much time did you spend developing all this? And resource wise how hungry is it? (Servers, Memory, CPU...) Edit: Wait a sec, I just saw this is part of open source demo of ViewFinderJS, bit confused now, is it commercial or opensource? How do you prevent someone of other 8000ish will not create a bit same and steal your thunder so to say?
  - graderjs 5y ago
    I agree about styles, thanks. Did not think of 99Design. Good idea! Much easier than me doing it :) Far better too, haha :) 2 years development in total so far. Not totally full time since roughly end of 2018 It's very resource lightweight for what it is. This is mainly due to how node and chrome work. When they don't do anything, they literally don't do anything. And chrome headless is normally pretty low CPU for everything. The node servers are very simple, there's not much that's thread blocking. It's a commercial service, but a couple of components are open-source. The browser you use in this demo and in the paid service is based on the ViewFinderJS open-source project, but it's more advanced, and is like the "pro" version of that.
    - NiceWayToDoIT 5y ago
      It is nice idea, and there are ways how this can be used/monetized. Good luck I hope you make it!

graderjs 5y ago

I guess there's a couple of cases to consider. The first is a malicious website that uses ph/fishing or some other social engineering type attack. Unless that attack also included the need to download some sort of payload file to create a back door or whatever this additional barrier would not provide any protection against social engineering type attacks. Another case is where there's a link in email to download a payload file that's like a word document or PDF that contains some sort of exploit that will you know initiate it take over on the user's computer. I guess a lot of them will be protected again by using a barrier like this because those files are downloaded to a separate server and then converted into images and then displayed back over the web so the client only receives an image of each page of that document and the document itself is never executed except that it's converted to images. Another case is a malicious website that uses a browser zero day or other type of exploit that enables remote code execution or sandbox escape in a browser. In that case you probably be protected by using this barrier because the only thing you're getting from the remote website is pixels of screenshots and any exploit that occurs will execute on the remote server. Here are the weaknesses is in the current setup. In order to successfully take over the remote server the exploit needs to escape the browser sandbox achieve remote code execution and achieve privilege escalation. I'm sure that's possible so it's not totally secure with respect to the server itself being pawned and then of course everybody who's using the server becomes vulnerable. So by no means is it perfect and from that point of view it's quite weak but from the point of view of the other cases it's quite a strong barrier. On the server every browser instance runs in its own temporary user. That user is no login user whose processes and home directory only exists for the duration of the browser session. And that user has limits on the amount of memory and CPU and disk space it can use. So from that point of view this system is relying on existing Unix process isolation and user privilege isolation to provide a layer of security on the server. In addition to that the controller server of every browser instance is a separate process for each client, on that separate process is run under that temporary user assigned to that client. So each controller server only how's the privileges of that temporary user, it only talks to that client and to that browser and every public API endpoint is authenticated. In addition the internal chrome remote debugging ports are prevented from being accessed from the outside web and other iptables rules drop packets on Google compute engine internal network endpoints. The reason I didn't wrap each browser instance inside a docker container to add yet another barrier and require the chaining together of yet another exploit is because it was a trade-off and I don't think it was worth it between the extra effort and overhead of running inside docker versus running inside a lightweight operating system sandbox using cgroups and temporary users. With that being said I have a couple of ideas on improving security if that's needed. Firstly rather than using the latest Linux server I could use SELinux and add additional hardening. Secondly I could like I mentioned before wrap each browser instance in its own docker container to require a container escape exploit to be chained together as well. Thirdly I could fall back on the security of Google cloud to use instance level isolation and require a hypervisor escape to compromise anything but the temporary virtual private server. In other words each browser instance could run on its own tiny VPS. The con side of the trade-off equation in each of these has been: no demand for it, and high cost in terms of application performance, implementation time, additional complexity and or money. For instance running each browser on its own tiny VPS would incur both an additional complexity and implementation cost as well as cut the performance because on average the performance of a tiny VPS is less good than the amortized same amount of processes on a much larger machine. In addition to that VPS bandwidth scales with number of processors, and bandwidth is a key component of the performance equation in this application. Even at the same raw number of processes and amount of memory than a larger machine I guess the money cost would be higher to run multiple tiny machines, and it would certainly be higher when each instance was enlarged to match the amortized performance available using a larger machine. hopefully that answers your question I'm sorry if it wasn't totally related to what you're wanting to know. Tho at the same time I'm pretty sure someone else'll find that information useful. Thanks for asking.

NiceWayToDoIT 5y ago
Thank you for the extensive answer, as it is paid service, I would only suggest you pay a bit of money for someone on 99Design to fix your styles. I would love to read more about architecture but as it is commercial product, I understand that is kind of trade secret. How much time did you spend developing all this? And resource wise how hungry is it? (Servers, Memory, CPU...) Edit: Wait a sec, I just saw this is part of open source demo of ViewFinderJS, bit confused now, is it commercial or opensource? How do you prevent someone of other 8000ish will not create a bit same and steal your thunder so to say?
- graderjs 5y ago
  I agree about styles, thanks. Did not think of 99Design. Good idea! Much easier than me doing it :) Far better too, haha :) 2 years development in total so far. Not totally full time since roughly end of 2018 It's very resource lightweight for what it is. This is mainly due to how node and chrome work. When they don't do anything, they literally don't do anything. And chrome headless is normally pretty low CPU for everything. The node servers are very simple, there's not much that's thread blocking. It's a commercial service, but a couple of components are open-source. The browser you use in this demo and in the paid service is based on the ViewFinderJS open-source project, but it's more advanced, and is like the "pro" version of that.
  - NiceWayToDoIT 5y ago
    It is nice idea, and there are ways how this can be used/monetized. Good luck I hope you make it!