Its a relatively common best practice to filter executables and scripts from a standard user at the proxy/gateway level in corporate environment. While EXE/BAT/CMD files are easy enough, and arguably .VBS (though I suppose it could in theory be used in a website that is only IE compatible), are there simple to deploy solutions for Microsoft JScript (.JS)?

It seems like a tricky one as the file extension is the same and the language is near identical.

Alternatively are content-type header inspections necessary to check if it is being downloaded, rather than executed in the relatively safe/necessary web browser context?

Or is reconfiguration of the OS prevent execution of .js files by wscript more common to mitigate this? Or content inspection to detect the use of dangerous methods (WScript object instantiation springs to mind).

For what its worth, I'm concerned with accidental downloading and execution of malicious (but non AV flagged) scripts by users here.

  • 1
    Javascript embedded in webpages would often contain the Referer header pointing to the webpage's URL. JScript files downloaded (from e-mail attachments, etc) wouldn't have such headers. You could use that to detect it, though it's not perfect. Mar 3, 2017 at 12:32

1 Answer 1


According to Wikipedia (https://en.wikipedia.org/wiki/JScript):

[Microsoft] did not want to deal with Sun Microsystems about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues

So to answer the question in your title, they are the same thing.

Edit: Per comment below from @dandavis, Jscript is actually worse.

I don't know anything about Windows/IE, but I believe you can configure IE to not execute JS (or only for certain sites) - which should mean you could potentially only allow JS to execute for trusted sites, which should limit the attack surface.

If a bit of Javascript was being download by something other than a browser, you could check what the User-Agent for the request is (although you should expect it to be spoofed).

I think (but again, not really my area) things like EMET might be of some assistance, as would something like application whitelisting (I think the functionality is part of AppLocker, but I don't know to what extent it can help).

Realistically, I don't think you would be able to globally block Javascript, because it would break a fair number of sites that people may want to be able to use.

Edited to account for extra info in comment below:

OK - for that case (thanks for specifying), I think there are two ways:

If you had a proxy that could do content introspection (and not have to deal with TLS-protected data), you might be able to block specific scripts that contain calls to wshell, but as you say, that is almost certainly going to be a long game of whack-a-mole that only ever mostly works.

Edit: Another thought occured to me, which was to try and force users to select the download dir for all downloads - I assume most would at least pause when seeing a .JS download. Unfortunately, per https://superuser.com/questions/250057/is-there-a-way-to-make-internet-explorer-9-always-prompt-for-download-location#261007, this is no longer possible for IE. It seems to be for e.g. Chromium (https://support.google.com/chrome/a/answer/2657289?hl=en), but that probably doesn't help. It is also a fairly weak protection - and may for that reason be a bit of a dead end.

  • 1
    Thanks for that quote, thats new to me, I thought they were identical syntax (I.e what would now be called ECMAScript) but otherwise different (how?!). One thought I had would possibly look for dangerous JScript calls, such as "wscript" object instantiation, but not sure its rock solid or if thats just another case of whack-a-mole. I'll upvote, because this is useful information, but not overly complete for my particular case. I dont want to prevent JS in the browser, I'd specifically like to allow that, If possible I only want to prevent WScript scripts being downloaded and run by the gateway Mar 3, 2017 at 13:12
  • ... Though I'm beginning to expect that its not really feasible! I think disassociating ".js" with wscript by extension might be the way forward, but allowing them through the gateway? Mar 3, 2017 at 13:13
  • To be honest, it may be that quote simplifies a bit too much (I find it a little hard to imagine wshell is part of ECMA, for one), but it seemed relevant in the sense that I don't think you can only target JScript vs. Javascript. I think your issue is more the calls any version of Javascript could make, and I would imagine it is possible to prevent a browser from shelling out to WShell somehow - I put a couple of suggestions above. Mar 3, 2017 at 13:20
  • 2
    Jscript classic (as opposed to .net) and JavaScript are both ECMAScript, but they are not the same; there were about 120 diffs in core alone. More germane to the understanding however is the environment (aka the "DOM"), which JScript got a unique and (too) powerful version of. It was gob-smackingly foolish to mark such a powerful local machine scripting file as executable, especially considering 99.99% of all .js files will only error when double-clicked. a Notepad association makes a ton more sense.
    – dandavis
    Mar 3, 2017 at 20:30
  • 1
    I must admit im surprised this doesnt get abused more regularly. .vbs malware is fairly common but I don't think I've come across a .js one personally. Im also glad I'm not the only one that thinks execute by default is... a strange decision... at a minimum they should have different extensions so you can know what to expect when you double click and so they can be blocked at the perimeter Mar 4, 2017 at 9:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .