We have a client that wants their content on Google TV (via the Chrome Browser), but is legally restricted from allowing it on the "regular web". So we want to detect Google TV Browser via Javascript, and if it is not, disallow playing the content.
The first thought was to check the user agent string, but apparently they don't like that because it would be too easy for a user to change their user agent string on their web browser so it pretends to be the Google TV browser.
Is there something else we could check for that is a little harder (or at least less obvious) to fake? I know any solution can be hacked around if someone tries hard enough, and that is ok.
There may be some things you can do since you only want to ensure that you are detecting who is NOT using a GoogleTV browser. Certainly these can be spoofed but they are quite a bit harder than just using a different user-agent string.
Basically, the idea would be to test for certain JavaScript object support (see this page: http://www.javascriptkit.com/javatutors/objdetect3.shtml for some ideas). An example of this would be testing for the presence of window.opera which would indicate that the browser was indeed Opera and definitely NOT a GoogleTV.
To that end, I've written a small fiddle example that cannot be faked by user-agent switching in all the modern browsers and requires a more sophisticated mechanism to bypass. I tested and it does pass on a Google TV.
http://jsfiddle.net/XBT4w/2/
I don't think there are any better ways then what Google suggests:
var userAgent = navigator.userAgent;
function isGoogleTvBrowser(useragent) {
return Boolean(useragent.match(/(Large Screen)|GoogleTV/i));
}
Although obviously, the user agent string can be faked extremely easily.
Anything you can come up with, especially in JavaScript, is going to be very easy to fake, because one can trivially (with console) paste code that will inject any value into any location.
Related
I've tried on getting browser info from javascript - navigator.userAgent, but cannot find any related string with "Vivaldi".
Please help to suggest if there are any other programming method or javascript can be used to detect Vivaldi browser?
The correct syntax in JavaScript is navigator.userAgent.
You can check window size, but it may be incorrect.
Vivaldi has its own sidebar and bottom bar that the others not.
But remember, user can change the window size to prevent detection.
According to Vivaldi, the userAgent will not have Vivaldi in it for a better user experience and mimic Chrome in all sites except a few known ones.
For the next release of Vivaldi, we have decided to try something different. The problem with our current approach is that with the web being almost infinite, we can’t possibly discover all the websites who have blocks set against us. Thus maintaining a list of sites where we present a non-Vivaldi User Agent is difficult. Instead, we will try doing the reverse. For a handful of sites where we know the label Vivaldi (and our version number) is responsibly used, we will present our full User Agent. Those sites being our own and a handful of interesting alternative search engines: duckduckgo.com, ecosia.org, qwant.com, and startpage.com. Every other site will get a User Agent that appears to be identical to Chrome.
src: https://vivaldi.com/blog/user-agent-changes/
Since you haven't mentioned your use case, assuming you are building sites, the best solution would be to do what everyone does. I recommend building websites agnostic to browsers and devices, but responsive to resolutions and feature support. Almost all of the browsers are running on Chromium these days, except Safari and Firefox (to my knowledge). So they are all going to work consistently across the board. For any given feature, one could always refer to w3c or mdn docs for compatibility and build around that.
Browser detection is also not quite reliable, as there are extensions to spoof the information. Like this extension that mimics a TV agent so one can run youtube console version on it.
On the other hand, once again I don't know your use case, one might benefit from platform detection over browser detection, like catering to mobile and TV users. Even then, if you have a site responsive enough the platform becomes non-essential information.
Is there any way to consistently detect PhantomJS/CasperJS? I've been dealing with a spat of malicious spambots built with it and have been able to mostly block them based on certain behaviours, but I'm curious if there's a rock-solid way to know if CasperJS is in use, as dealing with constant adaptations gets slightly annoying.
I don't believe in using Captchas. They are a negative user experience and ReCaptcha has never worked to block spam on my MediaWiki installations. As our site has no user registrations (anonymous discussion board), we'd need to have a Captcha entry for every post. We get several thousand legitimate posts a day and a Captcha would see that number divebomb.
I very much share your take on CAPTCHA. I'll list what I have been able to detect so far, for my own detection script, with similar goals. It's only partial, as they are many more headless browsers.
Fairly safe to use exposed window properties to detect/assume those particular headless browser:
window._phantom (or window.callPhantom) //phantomjs
window.__phantomas //PhantomJS-based web perf metrics + monitoring tool
window.Buffer //nodejs
window.emit //couchjs
window.spawn //rhino
The above is gathered from jslint doc and testing with phantom js.
Browser automation drivers (used by BrowserStack or other web capture services for snapshot):
window.webdriver //selenium
window.domAutomation (or window.domAutomationController) //chromium based automation driver
The properties are not always exposed and I am looking into other more robust ways to detect such bots, which I'll probably release as full blown script when done. But that mainly answers your question.
Here is another fairly sound method to detect JS capable headless browsers more broadly:
if (window.outerWidth === 0 && window.outerHeight === 0){ //headless browser }
This should work well because the properties are 0 by default even if a virtual viewport size is set by headless browsers, and by default it can't report a size of a browser window that doesn't exist. In particular, Phantom JS doesn't support outerWith or outerHeight.
ADDENDUM: There is however a Chrome/Blink bug with outer/innerDimensions. Chromium does not report those dimensions when a page loads in a hidden tab, such as when restored from previous session. Safari doesn't seem to have that issue..
Update: Turns out iOS Safari 8+ has a bug with outerWidth & outerHeight at 0, and a Sailfish webview can too. So while it's a signal, it can't be used alone without being mindful of these bugs. Hence, warning: Please don't use this raw snippet unless you really know what you are doing.
PS: If you know of other headless browser properties not listed here, please share in comments.
There is no rock-solid way: PhantomJS, and Selenium, are just software being used to control browser software, instead of a user controlling it.
With PhantomJS 1.x, in particular, I believe there is some JavaScript you can use to crash the browser that exploits a bug in the version of WebKit being used (it is equivalent to Chrome 13, so very few genuine users should be affected). (I remember this being mentioned on the Phantom mailing list a few months back, but I don't know if the exact JS to use was described.) More generally you could use a combination of user-agent matching up with feature detection. E.g. if a browser claims to be "Chrome 23" but does not have a feature that Chrome 23 has (and that Chrome 13 did not have), then get suspicious.
As a user, I hate CAPTCHAs too. But they are quite effective in that they increase the cost for the spammer: he has to write more software or hire humans to read them. (That is why I think easy CAPTCHAs are good enough: the ones that annoy users are those where you have no idea what it says and have to keep pressing reload to get something you recognize.)
One approach (which I believe Google uses) is to show the CAPTCHA conditionally. E.g. users who are logged-in never get shown it. Users who have already done one post this session are not shown it again. Users from IP addresses in a whitelist (which could be built from previous legitimate posts) are not shown them. Or conversely just show them to users from a blacklist of IP ranges.
I know none of those approaches are perfect, sorry.
You could detect phantom on the client-side by checking window.callPhantom property. The minimal script is on the client side is:
var isPhantom = !!window.callPhantom;
Here is a gist with proof of concept that this works.
A spammer could try to delete this property with page.evaluate and then it depends on who is faster. After you tried the detection you do a reload with the post form and a CAPTCHA or not depending on your detection result.
The problem is that you incur a redirect that might annoy your users. This will be necessary with every detection technique on the client. Which can be subverted and changed with onResourceRequested.
Generally, I don't think that this is possible, because you can only detect on the client and send the result to the server. Adding the CAPTCHA combined with the detection step with only one page load does not really add anything as it could be removed just as easily with phantomjs/casperjs. Defense based on user agent also doesn't make sense since it can be easily changed in phantomjs/casperjs.
I can't figure out how to detect a "dumb" phone browser using jQuery/JavaScript. I have a desktop/tablet, a smartphone, and a dumbphone version of my website. The smartphone version of the site is too heavy and slow for dumb phones so I want to redirect them to the "lite" version instead.
A good example of this would be Facebook. When I open Facebook on a dumb phone browser, the users get redirected to hte lite version. How do I do that same behavior?
NOTE: I am using JavaScript and not PHP beacuse of platform constraints. (It is on Tumblr.)
In your javascript you will need to detect the user agent variable (this is what each browser uses to identify itself).
if( /Android|webOS|iPhone|iPad|iPod|BlackBerry/i.test(navigator.userAgent) ) {
// Redirect code goes here
window.location = "someplace.com";
}
Essentially you will have to manually enter the types to test for in this and have an if/else statement for each case. (See http://www.w3schools.com/jsref/prop_nav_useragent.asp and http://useragentstring.com/pages/useragentstring.php)
Another good way would be check if certain features are present in the browser, like the http://modernizr.com/ library does. This might be better performance wise and you won't have to update the user-agent string every-time you find a "dumbphone".
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 want to redirect to Internet Explorer from other browsers by JavaScript. How can I do that?
You can't.
In a standard security context, browsers provide no way of launching other programs (and a goodly number of systems don't have Internet Explorer anyway). In non-standard security contexts, most browsers still don't provide a way of launching other programs.
JavaScript does not allow you to execute programs (like Internet Explorer) from another web browser. This isn't possible.
I would recommend to either:
Show an error/warning that the site doesn't work or might not work correctly when not using IE
Fix the site to work cross-browser (recommended)
Short answer is that you can't.
The real reason is security, which will (hopefully) always prevent you from running applications on the user's computer, but even if there weren't for that reason... I'm sorry, I just have to nitpick a bit here. What you're trying to do should be absolutely unacceptable in no uncertain terms to every single user and developer. I think I can safely speak for the overwhelming majority of experienced web developers, that techniques designed to dictate to the user which browser to use are always, always, always wrong, not just technically but morally. Yes, I used the M-word. It's immoral to make those sorts of decisions for your users, no matter how dumb they are. Warn them if your site is designed specifically for a particular browser, that's fine, but don't make the actual decision for them.
Sorry, I know this ain't the place for arguing, but I do believe this needs to be clear because it's a real problem in web development that really does waste time and really does cost money and really does harm the web as a whole.
So as far as I'm concerned, I'm glad these security measures are there, because this is an extraordinarily bad idea in the first place, even without the security risks.
No disrespect intended. It just had to be said.
You can't and you shouldn't!
However, this simple javascript, which only works in IE6, can runs firefox.exe from C:\Program Files\Mozilla Firefox ( YES I KNOW IT CAN BE SOMEWHERE IN E: OR D: .... but as I know the default path of Firefox is C:\Program Files\Mozilla Firefox ... you can complete this script and find the correct path of firefox.exe)
This HELL script shows that IE6 is really insecure. ( of course it shows a warning message )
You should never 'FORCE' visitors using your favorite browser. Never ever use such script, this is just for demonstration purpose.
<html>
<head>
<SCRIPT Language="JScript">
function runFirefox() {
File="c:\\PROGRA~1\\MOZILL~1\\FIREFOX.EXE http://stackoverflow.com";
WSH=new ActiveXObject("WScript.Shell");
WSH.run(File);
}
</SCRIPT>
</head>
<body onLoad="javascript:runFirefox();">
<b>For the best experience we FORCE you using Firefox.</b>
</body>
</html>
You should just develop websites that are viewable in all common browsers ;).
No work-arounds for people using different browser types / version.
When developing websites just make sure you meet the standards and all websites have sheets for the common browsers.
You can't.
As far as I'm concerned, I'd love the other way around: redirect any user with IE6 to Firefox/Chrome/safari :-)
You can. We do it because IE has a problem with how many cookies (and how large cookie storage can be) per domain. Because we have so much in our domain we hit a wall with IE. Also, PeopleSoft does not support browsers besides IE so PS users are forced to use IE while everyone else can get locked out of other apps when they hit the IE cookie limit. Is it ugly? Yes. Horribly. It shows what happens when enough planning isn't put into a process and what happens when one group is allowed to make decisions in a vacuum without talking to other groups about potential issues. But this is a fact of life in any organization and especially smaller (size and thinking) ones where there are big egos and weak leadership. Nonetheless...
It is possible to push out to the desktop something that handles a custom mime type. Therefore, when a response goes back to the desktop of type blah/blahblah this triggers an EXE that gets the response (a target location) and fires up IE. Or milks a cow. Whatever you want. You could even use this to tell a PC to take a picture...lots of possibilities.
you can do the following:
function openInChrome(url) {
var ws = new ActiveXObject("WScript.Shell");
ws.Exec("c:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe " + url);
}