How to ensure that JavaScript page does not communicate - javascript

I created a small JavaScript application for which I reused some (quite large) JavaScript resources that I downloaded from the internet.
My application runs in the browser like other interactive web applications but works entirely offline.
However, I intend to enter some private information in the application which it shall visualize. Since I cannot ultimately trust the JavaScript pieces that I downloaded, I wonder if there is a JavaScript option to make sure that no data is downloaded and, in particular, uploaded to the web.
Note that I am aware that I can cutoff the local internet connection or perhaps change browser settings or use an application firewall, but this would not be a solution that suits my needs. You may assume that the isolation of a browser instance is save, that is no other, possibly malicious, web sites can access my offline JavaScript application or the user data I enter. If there is a secure way to (automatically) review the code of the downloaded resources (e.g. because communication is possible only via a few dedicated JavaScript commands that I can search for) that would be an acceptable solution too.

You should take a look at the Content Security Policy (CSP) (see here and here). This basically blocks every connection from your browser to any other hosts, unless explicitely allowed. Be aware that not all browsers support CSP, which leads to potential security problems.
Reviewing the library code might be difficult because there are many ways to mask such code pieces.

Find it yourself by watching your browser's network activity while your application is in action.
There are more than enough tools to do this. Also, if you know how to use netstat command line tool, it is readily shipped with windows.
Here is one cool chrome extension which watches the traffic of the current tab.
https://chrome.google.com/webstore/detail/http-trace/idladlllljmbcnfninpljlkaoklggknp
And, here is another extension which can modify the selected traffic.
https://chrome.google.com/webstore/detail/tamper-chrome-extension/hifhgpdkfodlpnlmlnmhchnkepplebkb?hl=en
You can set the filters and modify all requests/responses happening in your page.
If you want to write an extension to block requests yourself, check this answer out.

Related

Start a background process with javascript

In general I am aware that one cannot call system libraries or dll's from javascript in browser. But in many of the application's I see browser starting other processes. For example:
As soon as I open Google Plus, it starts the googletalkplugin.exe (from folder C:\Users\Jatin\AppData\Local\Google\Google Talk Plugin) in the background. (Can be viewed in Resource monitor)
The same with facebook video chat. For the first time, it asks me to install a plugin and later when I start a chat, it starts a process.
On torrent sites, they provide magnet links. Clicking on torrent magnet link, it opens my systems default torrent client.
In a way, the same with flash and applet.
How do browsers trigger another process and communicate with it? Is there any open standard I am missing?
Ultimately I wish to do video, audio recording with screencast. For screen-recording, Java applet looks like the only solution but applet has its own Issues.
The flash player and applets use plugins, which are native applications to the OS, (i.e. (mostly) not JavaScript), they are not extensions but plugins. For Chrome see chrome://plugins/ to see the list of installed plugins.
For writing a browser plugin, refer to How to write a browser plugin?
The torrent link is totally different, they are done by registering an url protocol to handle. In other words, you say to the computer that, from now on, I will run any urls which have protocol of torrent, i.e.: starts with torrent://. See: Uri Scheme
When the browser sees the uri, it knows that is not handling torrent protocol itself, so it delegates that to OS, which knows what to do with it.
If the browser did know how to handle that, it probably would not delegated that to OS. For example: Google Chrome can handle mailto: links just well without registering mailto protocol to be handled by OS.
You can do this by writing a plugin. It's possible to write plugins that work on most popular browsers, using the same C++ code, using a library called Firebreath
Naturally there is no pre-existing standard plugin that allows the page to start any external application, because that would be a massive security hole and no (sane) user would agree to install such a plugin.
You have to write a specific plugin with capabilities carefully limited to what you need, so the user can agree to let you use just those capabilities. Again, think about how another page might exploit those capabilities before going down this route.

How to check the authenticity of a Chrome extension?

The Context:
You have a web server which has to provide an exclusive content only if your client has your specific Chrome extension installed.
You have two possibilities to provide the Chrome extension package:
From the Chrome Web Store
From your own server
The problem:
There is a plethora of solutions allowing to know that a Chrome extension is installed:
Inserting an element when a web page is loaded by using Content Scripts.
Sending specific headers to the server by using Web Requests.
Etc.
But there seems to be no solution to check if the Chrome extension which is interacting with your web page is genuine.
Indeed, as the source code of the Chrome extension can be viewed and copied by anyone who want to, there seems to be no way to know if the current Chrome extension interacting with your web page is the one you have published or a cloned version (and maybe somewhat altered) by another person.
It seems that you are only able to know that some Chrome extension is interacting with your web page in an "expected way" but you cannot verify its authenticity.
The solution?
One solution may consist in using information contained in the Chrome extension package and which cannot be altered or copied by anyone else:
Sending the Chrome extension's ID to the server? But how?
The ID has to be sent by you and your JavaScript code and there seems to be no way to do it with an "internal" Chrome function.
So if someone else just send the same ID to your server (some kind of Chrome extension's ID spoofing) then your server will consider his Chrome extension as a genuine one!
Using the private key which served when you packaged the application? But how?
There seems to be no way to access or use in any way this key programmatically!
One other solution my consist in using NPAPI Plugins and embed authentication methods like GPG, etc. But this solution is not desirable mostly because of the big "Warning" section of its API's doc.
Is there any other solution?
Notes
This question attempts to raise a real security problem in the Chrome extension's API: How to check the authenticity of your Chrome extension when it comes to interact with your services.
If there are any missing possibilities, or any misunderstandings please feel free to ask me in comments.
I'm sorry to say but this problem as posed by you is in essence unsolvable because of one simple problem: You can't trust the client. And since the client can see the code then you can't solve the problem.
Any information coming from the client side can be replicated by other means. It is essentially the same problem as trying to prove that when a user logs into their account it is actually the user not somebody else who found out or was given their username and password.
The internet security models are built around 2 parties trying to communicate without a third party being able to imitate one, modify or listen the conversation. Without hiding the source code of the extension the client becomes indistinguishable from the third party (A file among copies - no way to determine which is which).
If the source code is hidden it becomes a whole other story. Now the user or malicious party doesn't have access to the secrets the real client knows and all the regular security models apply. However it is doubtful that Chrome will allow hidden source code in extensions, because it would produce other security issues.
Some source code can be hidden using NPAPI Plugins as you stated, but it comes with a price as you already know.
Coming back to the current state of things:
Now it becomes a question of what is meant by interaction.
If interaction means that while the user is on the page you want to know if it is your extension or some other then the closest you can get is to list your page in the extensions manifest under app section as documented here
This will allow you to ask on the page if the app is installed by using
chrome.app.isInstalled
This will return boolean showing wether your app is installed or not. The command is documented here
However this does not really solve the problem, since the extension may be installed, but not enabled and there is another extension mocking the communication with your site.
Furthermore the validation is on the client side so any function that uses that validation can be overwritten to ignore the result of this variable.
If however the interaction means making XMLHttpRequests then you are out of luck. Can't be done using current methods because of the visibility of source code as discussed above.
However if it is limiting your sites usability to authorized entities I suggest using regular means of authentication: having the user log in will allow you to create a session. This session will be propagated to all requests made by the extension so you are down to regular client log in trust issues like account sharing etc. These can of course be managed by making the user log in say via their Google account, which most are reluctant to share and further mitigated by blocking accounts that seem to be misused.
I would suggest to do something similar to what Git utilises(have a look at http://git-scm.com/book/en/Git-Internals-Git-Objects to understand how git implements it), i.e.
Creating SHA1 values of the content of every file in your
chrome-extension and then re-create another SHA1 value of the
concatenated SHA1 values obtained earlier.
In this way, you can share the SHA1 value with your server and authenticate your extension, as the SHA1 value will change just in case any person, changes any of your file.
Explaining it in more detail with some pseudo code:
function get_authentication_key(){
var files = get_all_files_in_extension,
concatenated_sha_values = '',
authentication_key;
for(file in files){
concatenated_sha_values += Digest::SHA1.hexdigest(get_file_content(file));
}
$.ajax({
url: 'http://example.com/getauthkey',
type: 'post'
async: false,
success:function(data){
authentication_key = data;
}
})
//You may return either SHA value of concatenated values or return the concatenated SHA values
return authentication_key;
}
// Server side code
get('/getauthkey') do
// One can apply several type of encryption algos on the string passed, to make it unbreakable
authentication_key = Digest::<encryption>.hexdigest($_GET['string']);
return authentication_key;
end
This method allows you to check if any kind of file has been changed maybe an image file or a video file or any other file. Would be glad to know if this thing can be broken as well.

Web client cache

We are in process of building conceptual model of web-based audio editor. And the first trouble we met is client-side caching system. In my opinion as server-side programmer having huge cache on client side is perfect idea, because in many cases it takes of server load by excepting multiple loading of the same data. Furthermore such cache could be good candidate for buffer for providing per-track operations, like filtering.
Our flex programmer says that this is a great trouble and it is impossible in almost any cases. But I am in great doubt, cause I know that actual Google Chrome browser version can simple keep up to 2 Gb in localStorage. Moreover I've found this example of online track-editor and looks like its caching mechanism working pretty good.
Is it possible to cache some data (smth about 100-200mb) on the client side using flash and js?
You can use SharedObject to store the data.
I am pretty sure that default size limit is too low for your needs, so your app will need to ask user to accept your new limit:
http://www.macromedia.com/support/documentation/en/flashplayer/help/help06.html
SharedObject is more reliable than the browser cache, and you control it from your app.
If you are using html5 then you can store large data on client side using html5 inbuilt database.
also refer this link
What we did when writing a video editor. Well, actually, in Flash you can save files to the user's machine, with the restriction that it must be transparent to the user (i.e. the user initiates the action, goes through the OS dialog and saves the file as they would normally save anything they download), similarly, you can load in a file from a user's computer, with the restriction that the user must initiate the action (as in by clicking with a pointing device or pressing a key).
This has certain advantages over different local storage strategies, which are mostly opaque to users (people don't usually know how to erase cookies, SharedObjects or web storage that comes with more modern browsers, but they are pretty much capable of saving and deleting the files on their system). Furthermore, all other opaque local storages may have restrictions that less savvy users might not know how to overcome / may not be possible to overcome in general - these would be size, location and ownership.
This will still be a bit of hindrance for your audience, because every time they need to save a file, they have to go through the OS's dialog, instead of doing Ctrl+S / Cmd+S / C-x C-s... But given all other options, this, IMO, leaves the user with the most choices / delivers best experience.
Another suggestion - you could, in principle, come up with a browser-based "enhanced" version of your application, which users would install as a browser plugin (if that's an editor they are using on a regular basis - why not?), in which case you wouldn't be limited to the clumsy options provided by web technologies. Chrome and Mozilla-based browsers encourage such development, however it's not standardized. Still, since these two browsers run on virtually any OS, that doesn't sound particularly as locking in your users into a certain platform...

Least complicated way to get full file paths with Javascript

This has been asked a lot of times already: I need to get the full file path via a web-page. The use case is an application running on the same machine as the browser (i.e. the application starts a local HTTP server and fires up the browser.) File-paths are of course valid and the same for both client/server now. The use case it that the user selects a file and then the server process does some computation on it, and the input files are typically large (read: several GiB in size.)
The easiest thing would be to directly access the path using , but for security reasons, this is disabled. I'm looking now for the least intrusive workaround to this problem. The target browser in question is Chrome. I'm fine if the user has to click "accept" once on some security warning, as long as I can ensure that it won't appear again.
Do I have to write an extension, NSPlugin, can I use some special header magic to mark my page as "local", is there some security setting I can set? The less the client has to do the better, and I would prefer some "click here to allow access ..." solution above everything else. Can I directly install an extension from the server process that would do this (after the user clicks accept?)
Is it possible to do this with a Java applet/Flash? That would be the easiest solution, and clients are guaranteed to have Flash installed (as it is bundled in Chrome...)
You can create Java applet for tasks like this and self-sign it. User will have to allow it to run, but then you will be able to access applet's function that will return file path string via Javascript.
Clearly file io on the client's system is forbidden from JavaScript. If this wasn't the case it would be absolutely trivial to hack every web browser that visits your website.
Battlefiled 3 is controlled though the browser. To do this EA wrote a browser extension for the top three browsers. But that's resource intensive. If you just care about chrome you can use an addon, and for that i suggest using the NPAPI.
And as MOleYArd said, Java is a good solution and probably more common than an extension or addon.

How to assign a view object to an XUL tree widget without enablePrivilege

I see that enablePrivilege is deprecated in Firefox. I am trying to adapt my intranet code base to this.
The most critical place is assigning the 'view' of a 'tree' element. This requires elevated privs, though I really don't understand why. Is there another way to do this that does not require the elevated privileges? Will a way to do this be provided before enablePrivilege goes away?
The application is not an extension but a signed JAR file that runs as content.
Looking through bug 546848, Mozilla doesn't plan to allow websites with elevated privileges any more. This functionality introduces security risks that are simply not worth it (similarly to remote XUL in general). The proposed solution would be using a Firefox extension to do any special actions that might be needed. Ideally, you would move your entire web application UI into an extension and only leave the server as a backend. But I guess that this solution would require too much effort on your side. A simpler solution would be a single-purpose extension that receives a message from your website and sets the tree view.
Interaction between privileged and non-privileged pages describes how this communication could be implemented. Your website would set a property _myTreeView on the <tree> element and dispatch an event on it. The extension would receive the event, verify that event.target.ownerDocument.defaultView.location.host is your intranet website (important, allowing any website to trigger your extension would be a security hole) and then set event.target.view = event.target.wrappedJSObject._myTreeView. See XPCNativeWrapper documentation on why wrappedJSObject is necessary here.

Categories

Resources