The context: I'm writing JavaScript to run an executable and tweak some registry entries on the client machine. I've signed the .JAR using SignTool and my company's Authenticode certificate, but running the script produces a dialog saying:
There is no mention of the root certificate authority (in this case Comodo, I believe), so I could just as well have generated a self-signed certificate to put the company name string in the dialog.
My question is: is this all the user is meant to see? This example page at jar:http://www.mozilla.org/projects/security/components/signed-script-demo.jar!/signed-script-demo.html shows the same dialog, but there's still a lack of any "examine this certificate" link or mention of a root CA.
Are there any recent resources for writing signed scripts? The mozilla pages are mostly several years old and many reference now-defunct documentation at developer.netscape.com.
-- Martin
The code that runs those signed jars and elevates privileges hasn't changed in years either, so that documentation should be correct. The code hasn't really been touched because nobody on the web uses that stuff. Yes, I'm aware of the chicken-egg problem here with the crappy UI.
You could try filing a bug with Mozilla about this, but I'm not sure it'd get worked on (but patches would likely be welcomed).
We were forced to use signed scripts to access our Firefox addon from JavaScript. I wrote my experience about it here.
Shortly:
encapsulate your privileged logic in separate HTML+JS page
make this page do actual work on page load
sign it and put to server (you need packaging, custom content-type, etc.)
on usual (unsigned) pages: load signed page into hidden IFRAME and interop with it using JavaScript callbacks
Related
tl; dr: Is it possible without installing additional software on the client (e.g. proprietary protocol handlers, browser plugins etc.) to link to a document's WebDAV URL on a web page and have the browser starting the associated application (in my case limited to MS Office or LibreOffice) and having the application reading the document directly from the WebDAV URL? My usage scenario is limited to MS Office documents, but it is important that the solution also works if LibreOffice instead of MS Office is installed on the client as the application configured to handle MS Office documents.
The most obvious solution to simply place a link to the WebDAV URL on the web page does not work. The browser does not realize that it is not a plain HTTP URL and shows its regular 'do you want to download or open this file' behaviour. If I open the document from the browser, the browser still downloads the document to a temporary folder and starts the associated application in such a way that the downloaded document is opened from the temp folder. The relevant difference is that if you edit and save the document, it is only saved back to the temp folder on the client and not saved to the original WebDAV URL as intended.
I find it a little bit strange that I seem to be the only one having this problem, I have at least not found much information or discussion when searching the net.
I few close, but not quite fitting solutions are:
The WebDAV AJAX library from IT Hit. The library offers a JavaScript API to do exactly what I need. If I ignore that the library is quite expensive, it does however require additional software to be installed on the client, which in my case is not acceptable.
Confluence is according to the documentation offering the functionality I request, also without installing additional software on the client, but I have found no details on how it is actually solved technically.
MS Office installs by default protocol handlers, which allows me to use URLs like ms-word:ofe|u|https://my.webdav.server/path/to/doducment.docx on the web page. Some discussions on the internet seem to indicate that LibreOffice is supposed to support these URLs, but my tests show that it is not the case, not even under Windows.
LibreOffice installs (at least under Windows, allegedly not under Linux) a protocol handler for vnd.libreoffice.command. I could alternate between ms-word:ofe|u| and vnd.libreoffice.command and almost achieve what I am looking for, but there is no JavaScript API to query the installed protocol handlers, so I have no way to check which office suite is installed on the client machine and decide which of the two protocol handlers I can use.
Anyone out there with a better suggestion how to achieve this?
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.
Is there a way to identify and block JS files/events that are not part of your domain?
Like assume, if I'm writing a extension for chrome and I put following code in my JS
$('div').on('click', function(){ alert("yup"); });
is there a way for a website to handle this case?
Edit 1:
After discussion with #Clive, I realized that all extension/application should run in sandbox and should not be able to access events/elements outside the scope.
Case
A chrome extension have a keypress event on input[type=text] and input[type=password]. Now this extension runs in background, so there JS files are always available. Hence if you open facebook and login to your account, this extension will capture data and can send it to its server.
My Case
Two user was getting alert messages multiple times. Initially we thought its a part of our code and checked all JS files. But then realized, both user had same extension and so we diagnosed that extension's JS file and found alert in it. Now we were lucky, no damage was done, but it still posses a possible security threat.
Short answer: No.
Long answer:
Chrome extensions run their code in a separate space from your site's code, so they don't interact at all. The best you could do is prevent DOM edits. Luckily chrome extensions already run in a sandbox and have to explicitly ask for permissions for the domains that they inject code in and those domains are all listed when you install an extension. The only other way for extensions to interact with a page is through the activeTab permission which is a one time allowance on a specific user action. If you are using an extension that you think is malicious, you can always just read the code since JS is naturally open source. It really all boils down to a matter of trust. Installing something is explicitly trusting that thing to not mess up your stuff. This applies to all programs. If you don't trust an extension, then don't install it. A sandbox can only prevent so much while still letting extensions do something.
I found the some strange <script/> tags on a site:
<script src="chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl/document_iterator.js"></script>
<script src="chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl/find_proxy.js"></script>
...
I haven't been able to find much information on this, but I highly doubt this is actually related to Google Chrome since this site in particular is still using <table>s for layout, and the source in question was retrieved with curl not a graphical web browser.
So,
What on earth is this?
What is chrome-extension://
Why is it using lifbcibllhkdhoafpjfnlhfpfgnpldfl as a directory name
Why is it pretending to be valid URL to a javascript file?
Why would I need find_proxy or document_iterator
Solved. As far as I know...
chrixian was right, It seems that only on this and a few select other pages, someone had re-saved them from Chrome's source-view with the Skype extension installed.
Thanks everyone for all your help, +1's for all! enjoy!
That is actually Skype Click to Call chrome extension.
Manage and view it using this link
chrome://extensions/?id=lifbcibllhkdhoafpjfnlhfpfgnpldfl
If you are using cURL to get the page, you're getting the HTML as it exists on the server--so I think a safe assumption would be: the author of the page initially saved the page from Chrome, he had an extension installed that inserted these script tages and lastly he didn't remove the script tags for one reason or another before putting the page on the server.
This is added by chrome as the page loads, to inject the extension's Javascript code into the page, so it can access the HTML document.
The Skype extension causes it by inserting all kinds of junk in webpages that you visit.
Do you have the Skype browser extension installed for Chrome?
Just disable the extension.
Chrome, like Firefox, provides developers with an easy API to extend the functionality of the web browser without needing to actually download and build the browser to do so.
They also provide a robust delivery system. In Google's case, it's the Google Chrome Web Store.
Extensions are installed locally on your computer, and use long strings as directory names to reduce the risk of collisions with another extension. In other words, if you and I both named our extensions "mycoolextension", then there would be a problem if a person tried to install your extension and my extension. The long string helps prevent collisions such as this.
The chrome-extension:// protocol is used by the browser to make requests to these local resources. Chrome extensions are developed using HTML5, JavaScript, and CSS, along with an API exposed to allow the local JavaScript to perform actions it would not normally be able to do on the Internet.
When you see these in the Chrome developer tools, it's just the extension doing it's thing, whatever that may be.
If you're seeing these, then you likely installed some extensions from the Chrome Web Store. To view them, go to the Tools menu and select "Extensions". This will show you a list of all installed Chrome extensions and apps.
To learn more about extension development, see the Getting Started Tutorial.
Also, as someone else mentioned, you're using the Skype Call Extension. However, an app using that directory name doesn't appear in the first page of the search results. It might be worth doing some more research to make sure you got that extension from a legitimate source, whether that be Skype or the Chrome Web Store.
If you're seeing it in Chrome developer tools for every request you make, it means it has access to all your websites, which could be benign, like if they're just making phone numbers clickable, or it could be malicious, if it's scraping your bank account info and shipping it off to some third party server. :)
It's a Chrome extension, and chrome-extension:// is a URL for extensions to address their contents via Javascript.
lifbcibllhkdhoafpjfnlhfpfgnpldfl is the unique identifier for the extension. I can't find it with a search, but apparently it might be Skype.
It's not pretending... it is a valid URL. The Javascript file is located in the extension. If you were to look on your harddrive you'd probably find that very file in the extensions folder.
The functions its calling probably are some sort of detection used by the extension to see if it needs to enable itself.
See this for some additional information:
Checking if user has a certain extension installed
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.