I got a web site using jQuery, jQuery Tools and some handcrafted JS running performing graphical enhancements. While it's running smooth on FF, Safari and Chrome, IE blocks the script execution :
There is nothing particularly more dangerous on this code than, let's say, on Netvibes.
Why is even talking about activeX ? I'm using JS.
And how can I prevent that ? I don't want my user to click on "I allow this website" to work. It would be like putting a big red absolute DIV reading "Live quick and never come back".
js can't access the filesystem, so what's so point ?
Actually JS can traditionally do some bad stuff running from the My Computer Zone, like install ActiveX objects. A lot of past IE exploits used this to leverage filesystem access into arbitrary-code access.
So faced with this problem Microsoft decided to solve the problem, not by simply removing the My Computer zone — oh no, that would be far too easy — but by adding an extra layer of complexity. So Internet Explorer gained an option, on by default, to lock down content from the filesystem, whilst allowing other applications that used embedded WebBrowser controls to continue as before, on the grounds that maybe some applications were relying on the loose settings in their internal HTML interfaces.
(They weren't, really, in the consumer space, but then we never know what shades of foulness may exist in the bespoke Enterprise app world.)
After the embarrassment of IE getting hacked all the time, MS overcompensated by making the lockdown settings for filesystem pages considerably more restrictive than even normal web pages from the Intenet. So you can't run JavaScript from files off the filesystem, for no particularly good reason.
At this point web authors whinged, so MS responded not by removing the excessive lockdown — oh no, that would be far too easy — but by adding an extra layer of complexity. So now you can get out of the My Computer Zone simply by placing at the top of your file:
<!-- saved from url=(0014)about:internet -->
This cryptic incantation is known as the Mark of the Web. The newline at the end of it has to be a Windows CRLF, which nicely shafts you if you're using plain LF line-endings. Including this string puts you in the normal Internet Zone where JScript works but you get no other special privileges.
The amusing thing is that since then, the normal security settings in the My Computer Zone have been tightened up so that it's pretty much the same as the default Internet Zone. So the net result is the same as if they'd just got rid of the bloody My Computer Zone in the first place, only with lots of extra complication for the user and annoyance to the web author.
Thank you so very much Microsoft.
As Ken Browning said in a comment to your question, this alert happens with javascript when on a High Security Zone, where local pages are.
If someone has the Internet as a High Security Zone, then the warning will pop up.
You can add localhost to the Trusted Sites Zone.
Related
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.
We are distributing a CD that displays our HTML based menu on AutoRun. The menu(a local HTML file) runs in the users browser and communicates information about whats on the CD (a Customisation Package so NOT an installer). Our menu relies heavily on JQuery so not being able to run Javascript is not good. We chose to make the menu in HTML, CSS, Javascript to achieve cross-platform compatibility.
Because we are running a local HTML file that uses Javascript we encounter IE's restriction from running scripts or ActiveX Controls.
Our solution (according to our previous question) is to use The Mark of the Web. But we have one question:
Is this the silver bullet that will overcome IE's restrition?
Will The Mark of the Web work on IE V8 and up? Can I say with certainty that this will overcome IE's restriction or are there other factors I need to consider?
This does indeed appear to be "The Silver Bullet". One of the reasons to include MOTW, in fact, the first reason is:
You are coding pages that will be viewed from a CD, DVD, or other local storage device. (Be aware that users can, but won't necessarily, exempt local content from this security feature.)
The following code causes the file to be run in the Internet zone, which will remove the restrictions placed by IE. Please note that some users settings can prevent this code working, or a user can manually bypass this feature and force the window to run in the normal way which will prevent your JS from working.
<!-- saved from url=(0014)about:internet -->
There is no specifics on where it should be placed appart from The comment must appear in the first 2,048 bytes of the HTML document, within the HTML markup.
As for your question regarding it's compatibility, the feature was introduced in Microsoft Internet Explorer 4.0 and is compatible with every version from there up.
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 ?
I am completely new to javascript programming and I have a question that I didn't manage to find an answer for anywhere.
I have recently put together a simple slideshow to view the photos remotely that I host on my home computer. This by itself works fine. The problem I run into is that when I'm viewing photos I don't interact with the hardware, which after some time causes the monitor to switch off. This is particularly annoying when watching photos on my mobile phone.
My question is: is there a way to prevent this from happening? I am thinking in the direction of faking a mouse or other event every time I refresh the photo, but I have no clue how to do that and if it is possible.
Any help is greatly appreciated!
No. JavaScript on the browser cannot interact with the underlying system. Simulating keystrokes in the browser will not stop the screen saver from turning on. This is for security reasons, so that malicious code can't harm the system when you visit a web page.
Link on JavaScript Security
The modern JavaScript security model
is based upon Java. In theory,
downloaded scripts are run by default
in a restricted “sandbox” environment
that isolates them from the rest of
the operating system. Scripts are
permitted access only to data in the
current document or closely related
documents (generally those from the
same site as the current document). No
access is granted to the local file
system, the memory space of other
running programs, or the operating
system’s networking layer. Containment
of this kind is designed to prevent
malfunctioning or malicious scripts
from wreaking havoc in the user’s
environment. The reality of the
situation, however, is that often
scripts are not contained as neatly as
one would hope. There are numerous
ways that a script can exercise power
beyond what you might expect, both by
design and by accident.
Over the decade since this questions question was originally asked JavaScript has grown to provide much of the OS functionality (usually in a secure manner). The "wake lock" functionality is slowly being implemented. Currently there is a draft for the navigator.getWakeLock interface: https://www.w3.org/TR/wake-lock/#conformance
Chrome (https://developers.google.com/web/updates/2018/12/wakelock) and Mozilla (https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API) are considering it in various manners.
No, JavaScript cannot affect hardware or operating system. Just turn off monitor power saving settings until you're done with the slideshow.
Yes, It's possible now :)
Just use NoSleep.js library: https://github.com/richtr/NoSleep.js
It's working form me with Reveal.js slides on my Android Tablet
You could do it with a console application written in c# that interacted with the os
since js is a client side browser language it can only interact with the browser/bowser
I've never actually used greasemonkey, but I was considering using it.
Considering that GreaseMonkey allows you to let random people on the Internet change the behavior of your favorite websites, how safe can it be?
Can they steal my passwords? Look at my private data? Do things I didn't want to do?
How safe is Greasemonkey?
Thanks
Considering that GreaseMonkey allows you to let random people on the Internet change the behavior of your favorite websites, how safe can it be?
It's as safe as you allow it to be - but you aren't very clear, so let's look at it from a few perspectives:
Web Developer
Greasemonkey can't do anything to your website that a person with telnet can't already do to your website. It automates things a bit, but other than that if greasemonkey is a security hole, then your website design is flawed - not greasemonkey.
Internet user with Greasemonkey loaded
Like anything else you load on your system, greasemonkey can be used against you. Don't load scripts onto your system unless you trust the source (in both meanings of the term 'source'). It's fairly limited and sandboxed, but that doesn't mean it's safe, merely that it's harder for someone to do something nefarious.
Internet user without Greasemonkey
If you do not load greasemonkey or any of its scripts, it cannot affect you in any way. Greasemonkey does not alter the websites you visit unless you've loaded it on your system.
Greasemonkey developer
There's not much you can do beyond what can already be done with XUL and javascript, but it is possible to trash your mozilla and/or firefox profile, and possibly other parts of your system. Unlikely, difficult to do on purpose or maliciously, but it's not a bulletproof utility. Develop responsibly.
-Adam
Considering that GreaseMonkey allows you to let random people on the Internet change the behavior of your favorite websites
Random people whose UserScript you have installed. No one can force you to install a UserScript.
Can they steal my passwords?
Yes, a UserScript could modify a login page so it sent your password to an attacker.
No, it cannot look at your current passwords, or for websites the UserScript isn't enabled for
Look at my private data?
Yes, if your private data is viewable on a website that you've given a UserScript access too
Do things I didn't want to do?
Yes, a UserScript could do things to a webpage (you've given it access to) that are unwanted
How safe is GreaseMonkey?
As safe as the individual UserScripts you have installed
When used with discretion, Greasemonkey should be perfectly safe to install and use. While it is definitely possible to do all manners of mischief with carte-blanche Javascript access to pages, Greasemonkey scripts are restricted to specific URLs, and will not run on sites that are not specified by the URL patterns in their headers.
That being said, a basic rule of thumb is to consider most information on pages with Greasemonkey scripts active to be accessible to those scripts. It is technically feasible to play games like replacing input boxes (in which you might enter passwords or personal info), read any data on the pages, and send data collected to a third party. Greasemonkey scripts do run in an effective sandbox within the browser, and shouldn't be able to affect your computer outside of Firefox.
That being said, in some respects, the risk is comparable to or less than that of installing any other small pieces of open source software. Since Greasemonkey scripts are simple open source Javascript files, it's relatively easy for a programmer to take a look inside and make sure it does what it says it does. As always, run strangers' code (of any form) with care, and take the time to skim the source code if the software is important to you.
In general though, Greasemonkey scripts should be pretty safe. Try to use scripts with a large number of reviews and users, since these are likely to be more thoroughly vetted and analyzed by the community.
Happy userscripting!
Yes, userscripts can steal your passwords. That's the bottom line. Don't use firefox addons or userscripts on work or government computers without referring to your bosses.
Unlike firefox addons userscripts are not formally vetted. (Firefox 'experimental' addons are also not vetted). You can register and add a malicious script to userscripts.org in a moment.
Userscripts are very unsafe. The cross-site scripting ability means that it's no difficulty at all to send off your details/passwords to an evil server quite invisibly. And the script can do it for any site. Ignore the other answers that attempt to dismiss/minimise this issue. There are two issues: evil script writers putting their evil wares on to userscripts.org and scripts that break greasemonkeys' sandbox and so are vulnerable to being used by malicious code on a hacked site that would otherwise be restricted to same-domain.
In the case of evil script authors you can examine the scripts for code that sends your details; not much fun. At the very least you could restrict the script to particular sites by editing the 'include/exclude' clause. That doesn't solve the problem but at least it won't be sending off your banking credentials (unless you've used the same login details). It's a pity there isn't an 'includexss' clause to restrict xss requests, which would effectively solve the problem since, crucially, it would be easy to check even for non-developers. (the Firefox addon "RequestPolicy" doesn't block userscripts.)
Unsafe scripts: look for any use of 'unsafewindow'. There are other risky calls. Greasemonkey doesn't warn you of their use when the script is installed. Use of these calls doesn't mean the script is unsafe, just that the script writer had better be good at secure programming; it's difficult and most aren't. I avoid writing scripts that would need these calls. There are popular, high-download scripts that use these calls.
Firefox plugins/addons at Mozilla.org have similar problems to userscripts but at least they are formally vetted. The vetting/review includes the all-important code-review. Nevertheless there are clever techniques for avoiding the detection of evil code without the need of obfuscation. Also the addon may be hosted on an (unknown to anyone) hacked site. Unfortunately mozilla also lists 'experimental' addons which are not vetted and have had malicious code. You get a warning but how many know the real significance. I didn't until I picked up security knowledge. I never install such addons.
Userscripts are not formally vetted. Unless a script has a lot of installs I examine the code. Even so a high-install script could still have had the script-writer's account hijacked and script modified. Even if I examine a script the use of anti-detection programming means I may not see the evil. Perhaps the best bet is to examine outgoing requests with "Tamper Data" firefox addon, but a clever script will delay or infrequently send data. It's a tactical war, unfortunately. Ironically only microsoft's certificate based activeX objects really approach a real solution in developer traceability (but didn't go far enough).
It's true that a firefox addon gives an evil-doer greater exposure to potential victims, since firefox addons are generally more popular and so seem more likely to be targeted, but the firefox vetting process makes userscripts more attractive to the evil-doer since they are not vetted. Arguably a low-download userscript can still get a criminal plenty of valuable logins until it is spotted, while also giving the benefit of the relative obscurity and low community churn of userscripts, as well as a low chance of anyone code-reviewing it. You can't depend on firefox addons' popularity to protect you from evil userscripts.
As a non-developer you are dependent on other users spotting evil scripts/addons. How likely is that? Who knows. The truth is it's a crap security model.
Ultimately I use firefox for general browsing and Google Chrome (without greasemonkey/plugins) for admin purposes. Chrome also has a usable 'profiles' feature (totally separate browsing spaces) which is effectively like using different browsers. I've set up three chrome profiles to make myself even more safe: email/general-admin, banking, ebay/paypal. Firefox has unusable profiles (in my experience) but I prefer firefox as a browser which is why I still use it for uncritical browsing. Profiles also protect against old fashioned browser security holes and hacked sites, at least limiting their scope. But make sure you use different passwords. Another approach is a clean bootable ubuntu install on a USB stick for critical admin (see here http://www.geekconnection.org/remastersys/).
Jetpacks' special trust model, rather like the PGP trust network, which underlines the seriousness of this issue, should hopefully mitigate it. Jetpack is firefox's new kid on the block: a kind of super greasemonkey.