Develop Reference

Scan and access local file directory in Firefox and IE?

I'm doing some research on whether or not it's possible for a web app (meant to be used and distributed internally) to scan and read files from a local directory (on user machine). I came across a couple of terms as following:
NPAPI: no longer supported by majority of web browser
ActiveX: IE only
Sandbox: Chrome uses this kind of technology, plus it's not fitting to the requirement so I have to look elsewhere
I feel like ActiveX might be the only option even though I haven't actually written any ActiveX control before (not sure if it's possible).
Also the goal is to support more than one kind of web browser, so other than IE I thought Firefox might be capable of achieving the requirement, since no search result so far said otherwise.
Could someone please give me some pointer? I just need to know if it's at all possible to build a ActiveX control or Firefox extension to scan and read files from a local directory. If it is, then what is the downside other than security vulnerability.

Protect against browser extension injected Javascript code

Browsers allow extensions to inject code, manipulate the DOM, etc.
Over the years, I have noticed lots and various uncaught errors (using window.onerror) on a website (app) I am watching, generated by unknown browser extensions on Firefox, Chrome and Internet Explorer (all versions).
These errors didn't seem to be interrupting anything. Now I want to increase the security of this website, because it will start processing credit cards. I have seen with my own eyes malware/spyware infecting browsers with modified browser extensions (innocent browser extension, modified to report to attackers/script kiddies) working as keyloggers (using trivial onkey* event handlers, or just input.value checks).
Is there a way (meta tag, etc.) to inform a browser to disallow code injection or reading the DOM, standard or non-standard? The webpage is already SSL, yet this doesn't seem to matter (as in give a hint to the browser to activate stricter security for extensions).
.
Possible workarounds (kind of a stretch vs. a simple meta tag) suggested by others or off the top of my head:
Virtual keyboard for entering numbers + non textual inputs (aka img for digits)
remote desktop using Flash (someone suggested HTML5, yet that doesn't solve the browser extension listening on keyboard events; only Flash, Java, etc. can).
Very complex Javascript based protection (removes non white listed event listeners, in-memory input values along with inputs protected with actual asterix characters, etc.) (not feasible, unless it already exists)
Browser extension with the role of an antivirus or which could somehow protect a specific webpage (this is not feasible, maybe not even possible without creating a huge array of problems)
Edit: Google Chrome disables extensions in Incognito Mode, however, there is no standard way to detect or automatically enable Incognito Mode and so a permanent warning must be displayed.

Being able to disable someone's browser extension usually implies taking over the browser. I don't think it's possible. It would be a huge security risk. Your purpose maybe legit, but consider the scenario of webmasters programatically disabling addblockers for users in order to get them to view the advertisments.
In the end it's the user's responsability to make sure they have a clean OS when making online banking transactions. It's not the website's fault that the user is compromised
UPDATE
We should wrap things up.
Something like:
<meta name="disable-extension-feature" content="read-dom" />
or
<script type="text/javascript">
Browser.MakeExtension.MallwareLogger.to.not.read.that.user.types(true);
</script>
doesn't exist and i'm sure there won't be implemented in the near future.
Use any means necessary to best use the current up to date existing technologies and design your app as best as you can security wise. Don't waste your energy trying to cover for users who souldn't be making payments over the internet in the first place

UPDATE (2019-10-16): This isn't a "real" solution - meaning you should not rely on this as a security policy. Truth is, there is no "real" solution because malicious addons can hijack/spoof JavaScript in a way which in not detectable. The technique below was more of an exercise for me to figure out how to prevent simple key logging. You could expand on this technique to make it more difficult for hackers... but Vlad Balmos said it best in his answer below - Don't waste your energy trying to cover for users who souldn't be making payments over the internet in the first place.
You can get around the key logging by using a javascript prompt. I wrote a little test case (which ended up getting a little out of hand). This test case does the following:
Uses a prompt() to ask for the credit card number on focus.
Provides a failsafe when users check "prevent additional dialogs" or if the user is somehow able to type in the CC field
Periodically checks to make sure event handlers haven't been removed or spoofed and rebinds/ warns the user when necessary.
http://jsfiddle.net/ryanwheale/wQTtf/
prompt('Please enter your credit card number');
Tested in IE7+, Chrome, FF 3.6+, Android 2.3.5, iPad 2 (iOS 6.0)

Your question is interesting, and thoughtful (+1'd), however unfortunately the proposed security does not provide real security, thus no browser will ever implement it.
One of the core principle on browser/web/network security is to resist from the desire of implementing a bogus security feature. Web will be less secure with the feature than without!
Hear me out:
Everything execute on the client-side can be manipulated. Browsers are just another HTTP clients that talks to server; server should never ever trust the computation result, or checks done in front-end Javascript. If someone can simply bypass your "security" check code executed in a browser with a extension, they can surely fire the HTTP request directly to your server with curl to do that. At least, in a browser, skilled users can turn to Firebug or Web Inspector and bypass your script, just like what you do when you debug your website.
The <meta> tag stopping extensions from injection does make the website more robust, but not more secure. There are a thousand ways to write robust JavaScript than praying for not having an evil extension. Hide your global functions/objects being one of them, and perform environment sanity check being another. GMail checks for Firebug, for example. Many websites detects Ad block.
The <meta> tag does make sense in terms of privacy (again, not security). There should be a way to tell the browser that the information currently present in the DOM is sensitive (e.g. my bank balance) and should not be exposed to third parties. Yet, if an user uses OS from vender A, browser from vender B, extension from vender C without reading through it's source code to know exactly what they do, the user have already stated his trust to these venders. Your website will not be at fault here. Users who really cares about privacy will turn to their trusted OS and browser, and use another profile or private mode of the browser to check their sensitive information.
Conclusion: If you do all the input checks on sever-side (again), your website is secure enough that no <meta> tag can make it more secure. Well done!

I saw something similar being done many times, although the protection was directed in the other way: quite a few sites, when they offer sensitive information in a form of text would use a Flash widget to display the text (for example, e-mail addresses, which would be otherwise found by bots and spammed).
Flash applet may be configured to reject any code that comes from the HTML page, actually, unless you specifically expect this to be possible, it will not work out of the box. Flash also doesn't re-dispatch events to the browser, so if the keylogger works on the browser level, it won't be able to log the keys pressed. Certainly, Flash has its own disadvantages, but given all other options this seems the most feasible one. So, you don't need remote desktop via Flash, simple embedded applet will be just as good. Also, Flash alone can't be used to make a fully-functional remote desktop client, you'd be looking into NaCl or JavaFX, which would make this only usable by corporate users and only eventually by private users.
Other things to consider: write your own extension. Making Firefox extension is really easy + you could reuse a lot of your JavaScript code since it can also use JavaScript. I never wrote a Google Chrome or MSIE extension, but I would imagine it's not much more difficult. But you don't need to turn it into an antivirus extension. With the tools available, you could make it so no other extension can eavesdrop on what's going on inside your own extension. I'm not sure how friendly your audience will greet that, but if you are targeting corporate sector, then that audience is, in a way, a very good one, as they don't get to choose their tools... so you can just obligate them to use the extension.
Any more ideas? - well, this one is very straight-forward and efficient: have users open a pop-up window / separate tab and disable JavaScript in it :) I mean, you could decline to accept a credit card info if the JavaScript is enabled in the browser - obviously, it is very easy to check. This would require some mental effort from the users to find the setting, where they can disable it + they will be raging over a pop-up window... but almost certainly this will disable all code injection :)

This wont work, but i'll try something around document.createElement = function(){};
That should affect client side scripts (greasemonkey)
You can also try to submit the current DOM using an hidden input
myform.onsubmit=function(){myform.hiddeninput.value=document.body.innerHTML;} and check server side for unwanted DOM elements. I guess using a server side generated id/token on every element can help here (as injected DOM node will surely miss it)
=> page should look like
<html uniqueid="121234"> <body uniqueid="121234"><form uniqueid="121234"> ...
So finding un-tracked elements in the POST action should be easy (using xpath for example)
<?php
simplexml_load_string($_POST['currentdom'])->xpath("*:not(#uniqueid)") //style
Something around that for the DOM injection issue.
As for the keylogging part, i don't think you can do anything to prevent keylogger from a client side perspective (except using virtual keyboard & so), as there is no way to discern them from the browser internals. If you are paranoid, you should try a 100% canvas generated design (mimicking HTML element & interaction) as this might protect you (no DOM element to be bound to), but that would mean creating a browser in a browser.

And just that we all know we cannot explicitly block the extensions from our code,
one another way can be to find the list of event listeners attached to key fields like password, ssn and also events on body like keypress, keyup, keydown and verify whether the listener belongs to your code, if not just throw a flash message to disable addons.
And you can attach mutation events to your page and see if there are some new nodes being created / generated by a third party apart from your code.
ok its obvious that you will get into performance issues, but thats a trade off for your security.
any takers ?

window.clipboardData is not part of Javascript?

In my search for a Javascript way to programmatically select WebView content, I encountered this Javascript code snippet, which uses a method named setData() in a member named clipboardData in the window object.
But when I tried to find documentation for it in a Javascript reference, clipboardData was nowhere to be found.
Why?
Isn't window.clipboardData not part of Javascript or DOM?

No, it's not part of any standard. Except for IE, most browsers don't allow clipboard access because of security concerns (you don't want arbitrary webpages reading something sensitive information that you put into your clipboard).

I believe only IE lets you access the clipboard. Older versions of other browsers used to, but this has been switched off by default as a security measure. Users can explicitly turn it on via settings/options/preferences, but this is obviously not ideal in most situations.
The workaround is to use a flash object on the page. Since Flash 10 added more security layers, user interaction is also required now with the flash object (e.g. a click rather than say onload event).
I found and implemented the good work from the well written article at the bottom of my answer. He explains the issue in more detail, with links to official statements from Adobe/Mozilla and supplies a usable and a downloadable example, and the source code to the fla. This is handy if you want to reskin/redesign his button.
I have tested successfully on Windows7 using latest (as at 7/7/2011) Chrome/Safari/RockMelt/FF/IE7/IE8/IE9 and MacOSX(SL) Safari/FF.
The only downside is that it uses flash which is mostly fine except for some mobile platforms and a small portion of (ab)normal users. Also I found you need to access over http (a web server), opening and using the demo page via the file system (i.e. double clicking the html file in Explorer) won't work.
Thanks for sharing Rahul, awesome job.
http://www.rahulsingla.com/blog/2010/03/cross-browser-approach-to-copy-content-to-clipboard-with-javascript

Is it possible to remember the filename from a fileupload field and then later launch that file via javascript?

I have a HTML file upload field from which I'm reading the file name of the file that the user specifies. The actual contents of the file is never uploaded.
At a later stage, is it possible to construct a link using this file name information so that if the user clicks on this link, the original file is launched into a new browser window? If not, what are the reason for disallowing this behaviour?
The purpose of such a feature is to store links to documents that are available on a mapped local drive or a network share.

Most likely, no.
T.J.'s Crowder answer is correct but do note that on virtually all modern browsers that will work only if the webpage you are viewing (with the input type=file) is itself a file:///.
From your question it appears to be some kind of internal company website, which most likely will have its own web server.

You'll notice that in newer web browsers your client-side code will not actually be able to read the complete pathname of a file chosen by a user. That's a security measure. IE8 provides you with some sort of obviously fake directory name, while Firefox and the Webkit browsers just strip off everything other than the file name.
Thus, I don't think you'll be able to do what you want, at all.
edit: info from msdn: http://msdn.microsoft.com/en-us/library/ms535128%28VS.85%29.aspx

New answer
Since Andreas pointed out (quite kindly!) that my old answer (below), while correct, was almost certainly useless, I thought I'd take another swing at it with something I only learned about a few days ago: The new File API from the W3C.
You won't be able to make much use of this now (except on Firefox 3.6 or above), but before too long it'll find its way into modern browsers. It actually gives you access to local files, as long as the user has explicitly selected the file for you (via an input type="file" element). You still can't see their paths, but you can open and read them from the browser (yes, really). So you could open a new window, open the file, and write the contents to the new window. Whether that will really do what you want is another question (you'll have fun writing binary files to a new window, for instance, even though the File API lets you read them just fine), but hey, it's there.
Old answer
(Although you can do the below, Andreas points out that it won't work on just about any browser unless the page the link is in is also served via a file:// URL. So, not much use then.)
You should be able to use a file:// URL for that, e.g., c:\test.txt becomes file:///C:/test.txt. Then the link just uses the URL and the target="_new" attribute telling the browser to open a new window/tab, e.g.:
<a href='file:///C:/test.txt' target='_new'>link to test.txt</a>

Html file upload preview by Javascript

I want to show a PREVIEW kind of thing for an post , so took details by JS
but problem comes when it comes to <input type="file" , it's not giving full path to the file
Ex:
if I do
$("#image").val();
it only give "Sunset.jpg" not C:\Documents and Settings\All Users....\Sunset.jpg
any idea how to get that detail value?

Although, as others have already pointed out, you cannot learn the full path to the file in JavaScript, perhaps a completely different approach to the problem might still work for you.
You could upload the photo automatically as soon as the visitor has picked it (the behavior you see in GMail, among other applications), so it's residing on your server even as the visitor continues interacting with your page. At that point, showing a preview is as simple as serving one yourself from your own (now server-side) copy of the image.

This if for security reasons, so you cannot read files from the users system using JavaScript.
If you happen find a workaround, there will probably be security patches released by browser vendors sooner rather than later. I know because in earlier versions if IE, it was possible to read the full path and hence display a preview, at least if the file was an image. I used that in a CMS UI, but of course that nifty feature was ruined by an IE service release :-/
In general the file upload control is somewhat of a "black box" for security reasons. You have only very limited access to scripting and styling it. This is so you can't snoop or upload files without the user knowing, or so you cannot trick the user into uploading files with a deceptive interface.

This is now possible as of Firefox 3.6
https://developer.mozilla.org/en/DOM/FileList
Though the code they show does not seem to work in Chrome, so I'm guessing even the HTML5 JavaScript API for things like this has yet to be standardized.

This is a security feature. You cannot change or get the entire path in secure browsers, so what you want to do, cannot be done. If you use something like Flash, Silverlight or Java, then it should be relatively easy.

As far as I know, there is no way to do what you want to do in javascript. Its a pretty big security issue - having filesystem access in a browser.
There are a few browser plugins (java/flash/gears) that may allow you to do this sort of thing. I know with gears you can get the user to select a file - and open it to read the content using JS.