I've recently read the chromium sandbox architecture overview and the multi process architecture high level design.
The developers claim they run the tabs and web apps in a privileged external process for 2 main reasons:
1) Prevent the browser from crashing in case a tab or a web app crashes.
2) Various security reasons.
The security reasons I read about were mostly about changing the user's system configuration via Win32 API.
Now let's assume I develop a web browser that uses Webkit and V8 JS Engine and does not allow browser extensions and flash to be executed from within the browser.
Furthermore let's assume that application crashes are not an issue.
1) What advantages do I gain by implementing the sandbox architecture?
2) Can pure Javascript code access the memory\file system or invoke any unwanted windows API function?
3) What are the other security concerns I'm not aware of?
People have been hacked though web browsers for years, this is a silly question. Of course JavaScript can be used to gain access to the shell. This is the basis of browser based exploitation. Not only JavaScript, but malformed HTMl and CSS are also commonly used to corrupt memory and gain remote code execution. WebKit is new, and it has a lot of security problems. Keep WebKit Up to date, or you will be hacked.
It should be noted that JavaScript runs within a sandbox that jails it from accessing important resources on your machine or other websites, we call this the same origin policy. Google introduced another sandbox for Chrome to try and prevent remote code execution as a method of defense in depth, security in layers.
Related
I'm beginner to MEAN stack, while studying NodeJS, I'm came up with the following statement that's taking my mind
Node.js is a very powerful JavaScript-based framework/platform built
on Google Chrome's JavaScript V8 Engine.
but what exactly does it mean by
built on Google Chrome's JavaScript V8 Engine.
and if it's built on Chrome's JS V8 Engine, why does it works on Firefox as well?
MEAN stack, reorganized from back to front:
MongoDB: data persistence, stores data for later retrieval
Node.js: web application server, responds to requests from clients
Express: web application framework, reduces Node boilerplate
Angular.js: browser framework
So Node.js does not "work on Firefox" (it doesn't work on Google Chrome either): its a server-side technology. Think of it as a replacement for Python/Ruby/Java in that role. So it can/does respond to requests from all sorts of clients (like Google Chrome and Firefox).
What the "built on V8" means is that it uses the same JavaScript interpreter/just-in-time compiler as Google Chrome. But the similarities with chrome pretty much stop there: Node has no rendering engine/css parser/DOM but does have things you need in a server like an HTTP library and a filesystem API.
Also, and I mean no offence: we all started where you are, the fact that you are even asking the question (which again is not a bad thing!) means that building on a stack like MEAN is over your head. The documentation is going to assume that you know things you seem to not know. I strongly recommend furthering your understanding of JavaScript and Node through some tutorials and barebones test apps before trying to throw databases and frameworks into the mix.
In order for a programming language to be executed by a computer, it needs to be translated into a format the machine can understand (generally termed machine code). Javascript is no different. When your browser is presented with Javascript code on a website, something needs to compile or, in the case of Javascript, interpret the instructions into machine code.
V8 is the program that was developed by Google to do exactly that. When you use Chrome and it detects Javascript on a page, it passes it to V8 to run the compilation and then your computer executes the resulting code.
V8 was open sourced by Google. The creator of Node, Ryan Dahl, modified the source code so that V8 could be used outside of Chrome and inside an operating system like Linux or MacOS. That is what is meant by your first quote.
The important thing to note here is that you do not execute your Node programs in a browser but rather with the actual computer you are using. There's no correlation between V8 and Firefox, Safari, IE, etc. All of those browsers have their own Javascript interpreters.
Ok let's get through this:
Node.js is a very powerful JavaScript-based framework/platform built on
Google Chrome's JavaScript V8 Engine.
JavaScript is a programming language used in internet browsers. It was invented in 1995 by NetScape, I think, and has been submitted to a certification organization called ECMA in 1996.
ECMA has taken the original idea of JavaScript and made a standard called ECMAScript which each JavaScript implementation should follow. You see, JavaScript is not a language that just exists somewhere in the ether - each internet browser comes with it's own implementation of the language - this means that JavaScript usually only works in internet browsers such as Mozilla, Safari, Opera or Chrome for example. (Internet Explorer also comes with an implementation of ECMAScript but they call it JScript for licensing reasons I believe)
The implementation of JavaScript that comes with Google Chrome runs on the powerful V8 engine which is written in a language called C++. V8 interprets your JavaScript code and provides it all the variable types, manages memory etc. The great thing about V8 is that it is open-source and can be embedded in any other C++ program.
So the creators of Node had the idea of taking V8 and enhancing it by adding features that a server needs to serve websites - reading files, responding to requests, routing etc. This means that it is now possible to program the server-side implementation of a website using JavaScript thanks to the Node.js application that interprets your code and essentially translates it to C++ and later machine code further down the line. The important distinction is that Node.js DOES NOT run in your browser! It runs on a server much like when you code the back-end using PHP and apache.
V8 Engine is an interpreter for Javascript used in Google Chrome.
The statement that NodeJS is built on top of this engine means that it uses this interpreter for it's own thing, so it can also be used on the server, not just in the desktop environment (like in Google Chrome).
NodeJS is a separate application that you can communicate with over the internet, it's like Apache, Nginx or similar, but it's not used for one thing only (like the ones mentioned), but it's mostly used for making web-server like applications.
Node uses the same JS "engine" that runs chrome.
An engine in this case, is a piece of software that compiles, or "translates" your JS code into machine code; or the 0s and 1s your computer can understand.
This compilation is a complex process, and there are a few different approaches to solving it, for example google's v8 or mozilla's spidermonkey. Each of these support the entire JS standard (to a certain extent), i.e any JavaScript code can run on them.
When you run a node server, it runs on a machine that acts as a server. The code is not run on the user's machine at all; hence it doesn't matter which browser is used to view your content.
In the MEAN stack, it's angular code that runs on the user's computer. However, it is written in JavaScript, which can be run on any javascript engine.
Node.js is JavaScript on the server. For example, you can start a Node.js server on http://localhost:8000/, and you can access it with Chrome or Firefox.
Using Node.js (which uses V8), servers can be written in JavaScript rather than PHP or Ruby.
Actually NodeJS is cross platform server side framework. You might know as it is best suited for I/O bound and Data Streaming Applications, it uses Google Chrome's JavaScript V8 Engine for above mentioned purposes
So it's independent of browser and platform.
So not sure if this would be the correct place to ask these but I know I could perhaps get some answers.
I am getting into Meteor and now would like to make some desktop apps. I was going to go the route of just making a native Mac app. But then I found the app wunderlist and its open source making use of the tidesdk.
Anyways I was hoping to get some feedback just in general about these frameworks (pros/cons etc). I don't really have a conceptual understanding of what they do. (or what the main difference between the two is).
I notice you can do routing in them. How is this working exactly? Because there is no URLs or client/server side.
Another thing I was wondering is if it would be possible to use MeteorJS on the desktop in a similar way?
Thanks.
Working with TideSDK is quite easy. We are working to make the experience great for developers. You are essentially just creating an HTML5 app in a special Resources folder. In most cases you can drop an HTML5 app directly into the Resources folder, point to the index.html using TideSDK's configuration and have it running in minutes. TideSDK can be used to run clients, servers, processes, and workers. I tend to work with frameworks such as backbone.js where routing is baked into a single page app.
At the core of TideSDK is WebKit, the core technology that powers the Safari and Chrome web browsers. We use three different ports of WebKit in TideSDK, one to reach each platform (Windows, Mac, Linux). On OSX, we can also use the native WebKit. The APIs of TideSDK provide native UI capabilities (that we are enhancing over time). These include native windows, system trays, menus, and dialogs. You can also interact with the clipboard. We have networking and database capabilities, system notifications, and more. We patch Webkit to allow the interpretation of python, php or ruby in the DOM in script tags and are able to bridge objects between languages. Our API's really allow your to reach the resources of your system including interacting with its filesystem.
It would be fun to run meteor in TideSDK. It is currently possible to run node.js within TideSDK using an appropriate startup process so I cannot see an issue running meteor so that it can run client and server within an app.
If you need your apps to reach Apple's AppStore, TideSDK is the only framework that I am aware of that has this potential. Competitive frameworks use ports of WebKit that are not native to the Mac such as the Chrome port (appjs) or the QT port (Sencha Ion). Apple's scan of an app based on these ports will reveal the use of "private APIs". Therefore, you would could not enter the AppStore marketplace with an app based on these. TideSDK is different and can use the native WebKit implementation on OSX. More about this capability will be revealed in the upcoming TideSDK-1.4.0 release. Our upgraded WebKit will also bring the HTML5 capabilities right up to date with the trunk of WebKit. Many of our users are waiting for this important update.
With WebKit eliminated as a barrier to the AppStore, the last issue facing a developer is Apple's sandboxing and entitlement to the resources of the system. We are looking at possible solutions to aid developers with sandboxing requirements. Some apps will be suitable for sandboxing and others will not. That said, if your goal is AppStore compliance, you will need to work with restrictions Apple has in place. I hope this helps.
I am trying to develop a web page that will allow user to edit registry settings in windows system. Can i achieve it with client side scripting language.? If yes please suggest me language to do.
Can we do it with jQuery or any other type of library.
Due to obvious security concerns, this is only possible in Internet Explorer(!). This is not a jQuery library, but an activeX control; so it's quite unpleasant to use.
You have been warned, so here is the documentation :
http://technet.microsoft.com/en-us/library/ee156602.aspx
Fortunately is impossible to access the registry from a web app: the only way you have is through an ActiveX control but I would not go down this road.
have a look at the below
Access registry from a web aplication
Far from ideal but ...
If you serve up a ".hta" file (HTml Application) from your web server, Windows will run it as a program outside of IE and give it the privileges of the PC user. It will be in a separate window and there won't be any browser features (Back/Refresh/Address bar etc).
Even then, modern versions of Windows will prompt the user with security warnings if a HTA is launched from anywhere other than a local drive.
I know this thread is old, but I am not sure I like any answers for this problem. Instead of trying to access the Registry directly through Javascript, try writing a Java Applet and talk to the java applet using Javascript. Then in the JavaApplet you can write some JNI code to write a native dll to do what you need. It isn't a direct solution to your problem, but it will allow you to do what you need across multiple browsers. The downside is that you can't use it on browsers that do not support running a Java Applet, such as a mobile platform.
This method will also require you to sign your Java Applet. This is how you get around the security issues. The user will have to accept the applet the first time to give the security access.
In my web page, I have to start a desktop application on the client's computer if it's installed. Any idea how I can do this?
If the application is MS Office or Adobe Reader, I know how to start them, but the application I want to start is a custom application. You can not find it on the internet.
How can I open the application?
Basically it's not possible to achieve unless an application registers a protocol that will trigger it. If it does that all you need to do is to provide a link using this protocol
yourcustomapp://some.parameters
Another way the 3rd party app can integrate with the browser is if it hooks to it as a plugin. This is how flash apps work etc.
If the app you are trying to launch does not support something like that it's going to be close to impossible to achieve what you want.
The browser sandbox prohibits you from executing local resources, for good reason - to thwart a website destroying your box with malicious code. I've been researching the same functionality.
The only solution I've found is to build an extension in Mozilla Firefox which can launch your app. Extensions live outside the sandbox so they can execute local resources. See this page for how to do that. You may be able to do it cross-browser using crossrider, though I haven't had success with that yet.
You could alternatively build a thick client populated from a web service, and launched from the browser through an extension as mentioned above. This is what I'm doing to get around the sandbox. I'm using local XUL for this.
See my question for additional discussion.
First off - you can't do it using javascript in any sort of a portable mechanism.
If the application is ms office or adobe reader,I know how to startup them
No you don't - you know how to send a document, which the browser associates with these applications and invokes them supplying the name of the local copy of the response. You can't just start the programs.
You just need to do the same for your app - invent a new mime type (the major type would be 'application' and by convention, non-standard minor types are prefixed with 'x-', so you might use application/x-hguser) then associate that mimetype with the relevant program browser side.
i.e: You need to explicitly configure each browser
I already encouter that problem in some complex production environnements.
I do the trick using the following code :
function launch(p_app_path)
{
var oShell = new ActiveXObject("WScript.Shell");
oShell.Run('"' + p_app_path + '"', 1);
}
In IE options > Security > Customize the level > ActiveX controls and plugins > Initialization and script ActiveX controls not marked as safe for scripting, set the value to Ask or Active.
It isn't a security problem when your website is enclosed into a specific security context.
And as they say, it's not worth it to build a gas plant.
JavaScript alone can't do this. (No, not even with MS Office or Adobe Reader.) Thankfully.
There are a number of old ways, including using ActiveX, which may work for your needs. As others have pointed out while typing this, you can customize responses based on the mime type or the protocol, etc.
Any way you look at it, you're going to need control over the end users' browser. If you're in a close environment where you can dictate policy (users must use a specific browser, with a specific configuration), then you're going to need to do that. For an open environment with no control over the end users, you're out of luck.
I'm actually having a lot of success right now with SiteFusion. It's a PHP client/server application framework that serves out XUL/JavaScript applications from a server deamon running in Apache. You access applications from a very thin client in XULRunner, or potentially off a web page using extensions. Clients can execute on any platform, and they're outside of the browser sandbox so you can access local resources such as executables. It'a a fairly elegant solution, their website provides great examples and documentation, and their forum is very responsive. I actually found a minor bug in passing arguments to local executables, posted a question about the forum, and it was fixed by the chief developer in under 15 minutes. Very impressive, overall!
I would like to know how browser allow viruses to pass through to our computers. Response we receive is a text response.. Only executable thing in the response is JavaScript which does not have much privileges, what makes browser favor certain files to be passed to computer?
The short list:
Browser plugins. ActiveX* in general and Flash in particular are notorious for having holes.
Buffer overflows. Forming either HTML pages or Javascript in a specific way can lead to being able to write anything you want into memory... which can then lead to remote execution.
Other errors. I recall bugs in the past where the browser could be tricked into downloading files into a known location, then execute them.
*Google is working on expanding this particular kind of hole to other browsers with Native Client.
Things like ActiveX controls allow native code to be executed on local machines with essentially full privileges. Most viruses propagate through known security holes in unpatched browsers and don't use Javascript directly.
Browser bugs and misconfiguration can allow sites that should be in the "Internet" (secure) security zone execute code as if they were trusted. They can then use ActiveX components to install malware.
Exploiting software bugs. Commonly, when rendering images, interpreting html/css/javascript, loading ActiveX components or Flash files.
Once a bug is exploited, the procedure is to inject "shell code" (a chunk of native compiled code), into the process memory to get executed.