views:

757

answers:

7

Is there a way to load and run an EXE file on the client side, after a webpage has been loaded ? [with java script or HTML ]

A: 

No, this would be a security hole. Web applications are only written using HTML/Javascript and sometimes other technologies like Flash which are deemed safe enough to run in browsers. (Even though they also sometimes have security holes.)

Roger Pate
+1  A: 

This shouldnt be done, if a user wants to run an exe from your site they will happily download it then run it, however if the site is trying to automatically run an exe when someone visits the site that would be a huge security vulnrability.

What is it the exe does? This may be possible to do with javascript or even server side. Other options if you really want clients to run executables would be to look at something like .net click once deployment where you can publish an executable to your site and clients can then download and install from the site, this comes with the advantages of things like automatic updates.

Gavin Draper
+1  A: 

Short Answer - Yes it can be done. Long answer - No it can't be done and its terribly bad practice.

Let me explain.

Security is the deciding factor, you can write just about anything in JavaScript, including code to launch executable, but most browsers will not allow you to launch an exe - because its obviously a huge security risk.

My suggestion, do things in a conventional way, if you require better client side support, use an applet or even active-x (but I would avoid this).

JL
+1  A: 

There (are||used to be) several JS interfaces for this, which are most likely blocked with modern browsers, for obvious security reasons.

So either your clients trust you and install you [FF/IE/Safari/etc.] extensions or ...

However, as for the FF extension way see my answer at this thread

in short:

External application launching according to this post can be done as follows:

var file = Components.classes["@mozilla.org/file/local;1"]
                     .createInstance(Components.interfaces.nsILocalFile);
file.initWithPath("c:\\myapp.exe");
file.launch();

For IE you can try to run this

<script lang='vbscript'>
    set WshShell = WScript.CreateObject("WScript.Shell")
    WshShell.Run "C:\program files\program\program.exe"
</script>
Tzury Bar Yochay
Or rather `try { set WshShell = WScript.CreateObject("WScript.Shell") }` because that will only work in the "My Computer" zone or have completely disabled the security settings.
Piskvor
upvoted your comment. you are absolutely right. though this all approach is not to be considered as a way to solve problem anymore.
Tzury Bar Yochay
+2  A: 

In MSIE, it's possible to use ActiveX for that - but the user has to allow your ActiveX control to be installed/executed. If you're looking at some environment under your control (e.g. your company), this could be a way. Have worked with a legitimate "remote install" feature like this, long ago; nowadays, it's easier to ask the user to download and execute the installer (not browser-dependent, and users have learned how to do this (gasp!)).

If you mean "with JS/HTML from the browser", that's called "arbitrary remote code execution" and is a pretty serious security hole. So, thankfully, that's not possible (would you want any website to run format c: on your computer? Thought so).

Piskvor
+2  A: 

Something to look into is Java Web Start.

This is a Java-only technology, obviously, but it essentially allows you to start a local application from a Web page, and to do so in a somewhat more secure manner than firing up an arbitrary .EXE .

A side benefit is that it allows you to deploy application updates to all users simply by updating the repository copy on your site - updates are pulled automagically.

Carl Smotricz
+1  A: 

Legally, no.


If you are a hacker-cum-cracker:
Yeah. There is a security hole in older versions of flash player (less than 9 I believe) that allows you to do this. If you are smart enough, you can exploit that and run any code on users' machine (at least on windows/mac). See this link for more details.

Amarghosh
That's a rather transient solution with a lot of hooks and "if"s.
Piskvor
Note that I started the post with a **no**. The rest is supposed to be a tongue-in-the-cheek response. After all, ifs and hooks shouldn't stop a determined hacker ;)
Amarghosh