I'm developing a web application and since it has access to a database underneath, I require the ability to disable the developer tools from Safari, Chrome, Firefox and Internet Explorer and Firebug in Firefox and all similar applications. Is there a way to do this?
Note: The AJAX framework provided by the database requires that anything given to the database to be in web parameters that can be modified and that anything it returns be handled in JavaScript. Therefore when it returns a value like whether or not a user has access to a certain part of the website, it has to be handled in JavaScript, which developer tools can then access anyway. So this is required.
UPDATE: For those of you still thinking I'm making bad assumptions, I did ask the vendor. Below is their response:
Here are some suggestions for ways of mitigating the risk:
1) Use a javascript Obfuscator to obfuscate the code and only provide
the obfuscated version with the sold application; keep the non
obfuscated version for yourself to do edits. Here is an online
obfuscator:
How can I obfuscate (protect) JavaScript?
http://en.wikipedia.org/wiki/Obfuscated_code
http://javascriptobfuscator.com/default.aspx
2) Use a less descriptive name; maybe 'repeatedtasks.js' instead of
'security.js' as 'security.js' will probably stand out more to anyone
looking through this type of information as something important.
No you cannot do this.
The developer menu is on the client side and is provided by the user's browser.
Also the browser developer should have nothing to do with your server side database code, and if it does, you need some maaaaaajor restructuring.
If your framework requires that you do authorization in the client, then...
You need to change your framework
When you put an application in the wild, where users that you don't trust can access it; you must draw a line in the sand.
Physical hardware that you own; and can lock behind a strong door. You can do anything you like here; this is a great place to keep your database, and to perform the authorization functions to decide who can do what with your database.
Everything else; Including browsers on client computers; mobile phones; Convenience Kiosks located in the lobby of your office. You cannot trust these! Ever! There's nothing you can do that means you can be totally sure that these machines aren't lying to cheat you and your customers out of money. You don't control it, so you can't ever hope to know what's going on.
In fact this is somehow possible (how-does-facebook-disable-developer-tools), but this is terribly bad idea for protecting your data. Attacker may always use some other (open, self written) engines that you don't have any control on. Even javascript obfuscation may only slow down a bit cracking of your app, but it also gives practically no security.
The only reasonable way to protect your data is to write secure code on server side.
And remember, that if you allow someone to download some data, he can do with it whatever he wants.
There's no way your development environment is this brain-dead. It just can't be.
I strongly recommend emailing your boss with:
A demand for a week or two in the schedule for training / learning.
A demand for enough support tickets with your vendor to figure out how to perform server-side validation.
A clear warning that if the tool cannot do server-side validation, that you will be made fun of on the front page of the Wall Street Journal when your entire database is leaked / destroyed / etc.
No. It is not possible to disable the Developer Tools for your end users.
If your application is insecure if the user has access to developer tools, then it is just plain insecure.
Don't forget about tools like Fiddler. Where even if you lock down all the browsers' consoles, http requests can be modified on client, even if you go HTTPS. Fiddler can capture requests from browser, user can modify it and re-play with malicious input. Unless you secure your AJAX requests, but I'm not aware of a method how to do this.
Just don't trust any input you receive from any browser.
you cannot disable the developer tool. but you can annoys any one who try to use the developer tool on your site, try the javascript codes blow, the codes will break all the time.
(function () {
(function a() {
try {
(function b(i) {
if (('' + (i / i)).length !== 1 || i % 20 === 0) {
(function () { }).constructor('debugger')()
} else {
debugger
}
b(++i)
}
)(0)
} catch (e) {
setTimeout(a, 5000)
}
}
)()
}
)();
Update at the time (2015) when this answer was posted, this trick was possible. Now (2017) browsers are mature. Following trick no longer works!
Yes it is possible. Chrome wraps all console code in
with ((console && console._commandLineAPI) || {}) {
<code goes here>
}
... so the site redefines console._commandLineAPI to throw:
Object.defineProperty(console, '_commandLineAPI',
{ get : function() { throw 'Nooo!' } })
This is the main trick!
$('body').keydown(function(e) {
if(e.which==123){
e.preventDefault();
}
if(e.ctrlKey && e.shiftKey && e.which == 73){
e.preventDefault();
}
if(e.ctrlKey && e.shiftKey && e.which == 75){
e.preventDefault();
}
if(e.ctrlKey && e.shiftKey && e.which == 67){
e.preventDefault();
}
if(e.ctrlKey && e.shiftKey && e.which == 74){
e.preventDefault();
}
});
!function() {
function detectDevTool(allow) {
if(isNaN(+allow)) allow = 100;
var start = +new Date();
debugger;
var end = +new Date();
if(isNaN(start) || isNaN(end) || end - start > allow) {
console.log('DEVTOOLS detected '+allow);
}
}
if(window.attachEvent) {
if (document.readyState === "complete" || document.readyState === "interactive") {
detectDevTool();
window.attachEvent('onresize', detectDevTool);
window.attachEvent('onmousemove', detectDevTool);
window.attachEvent('onfocus', detectDevTool);
window.attachEvent('onblur', detectDevTool);
} else {
setTimeout(argument.callee, 0);
}
} else {
window.addEventListener('load', detectDevTool);
window.addEventListener('resize', detectDevTool);
window.addEventListener('mousemove', detectDevTool);
window.addEventListener('focus', detectDevTool);
window.addEventListener('blur', detectDevTool);
}
}();
https://github.com/theajack/disable-devtool
This tool just disabled devtools by detecting if its open and then just closing window ! Very nice alternative. Cudos to creator.
I found a way, you can use debugger keyword to stop page works when users open dev tools
(function(){
debugger
}())
Yeah, this is a horrible design and you can't disable developer tools. Your client side UI should be sitting on top of a rest api that's designed in such a way that a user can't modify anything that was already valid input anyways.
You need server side validation on inputs. Server side validation doesn't have to be verbose and rich, just complete.
So for example, client side you might have a ui to show required fields etc. But server side you can just have one boolean set to true, and set it to false if a field fails validation and then reject the whole request.
Additionally your client side app should be authenticated. You can do that 100 thousand ways. But one I like to do is use ADFS passthrough authentication. They log into the site via adfs which generates them a session cookie. That session cookie get's passed to the rest api (all on the same domain) and we authenticate requests to the rest api via that session cookie. That way, no one that hasn't logged in via the login window can call the rest api. It can only be called form their browser context.
Developer tool wise, you need to design your app in such a way that anything that a user can do in the developer console is just a (feature) or a breaking thing. I.e. say they fill out all the fields with a js snippet, doesn't matter, that's valid input. Say they override the script and try to send bad data to the api calls. Doesn't matter, your server side validation will reject any bad input.
So basically, design your app in such a way that developer tool muckery either brakes their experience (as it won't work), or lets them make their lives a little easier, like auto selecting their country every time.
Additionally, you're not even considering extensions... Extensions can do anything and everything the developer console can do....
I am just throwing a random Idea maybe this will help.
If someone tries to open the developer tool just redirect to some other site.
I don't know how much this is gonna effective for you but at least they can't perform something on your site.
You can not block developer tools, but you can try to stop the user to enter them. You can try to customize a right-click menu and block the keystrokes for developer tools.
You can't disable developer tools
However...
I saw one website uses a simple trick to make devtools unusable. It worked like this - when the user opens devtools the whole page turns into blank page, and the debugger in devtools is stuck in a loop on a breakpoint. Even page refresh doesn't get you out of that state.
Yes. No one can control client browser or disable developer tool or debugger tool.
But you can build desktop application with electron.js where you can launch your website. Where you can stop debugger or developer tool.
Our team snippetbucket.com had build plenty of solution with electron.js, where similar requirement was their. as well restructure and protect website with many tools.
As well with electron.js many web solution converted and protected in well manner.
You can easily disable Developer tools by defining this:
Object.defineProperty(console, '_commandLineAPI', { get : function() { throw 'Nooo!' } })
Have found it here: How does Facebook disable the browser's integrated Developer Tools?
Related
I am currently writing a program that collects information from a sports website. (it contains the history of some basketball matches) The problem is that the website uses Angular.js for dynamical HTML binding. Consequently, the HTML source code involves lots of variables.
I need to find out the values of the variables in order to make my program work as I want. Is there any library or framework that could help me?
Edit: I am not limited by anything, but I prefer a web app (MEAN, JS frameworks with node-webkit). If it can't be done, I can also code it in C++ or Java (or extend it further to Android with NDK or SDK)
Disclaimer: This is not grey-hat stuff. I just need to do some web-scraping.
PhantomJS is a headless browser. It will allow you to use JavaScript to get the information you want.
Details:
It will browse to the page you want, execute the JavaScript like any browser and have access to the page as if it was displayed to a normal user using a normal browser. Using JavaScript DOM traversal, you will be able to get the information you need. This is almost the same as automatizing the task of opening a console in a browser and executing javascript which will get the information from the page.
While the below example is really simple, it can do much more than just getting the page results... it can click buttons, navigate to other pages, extract only relevant information, extract the page as an image... Do not hesitate referring to its Quick start documentation to learn more about it.
Example script returning the complete HTML page after waiting 10 seconds for the AngularJS to have finished calculating the page:
Command line usage: phantomjs-1.9.1 this_script.js
this_script.js (PhantomJS 2.0 may have different syntax in some cases):
var url = phantom.args[0]
function getDocumentElementAsHTML(page) {
return page.evaluate(function() {
return document.documentElement.innerHTML
})
}
var page = new WebPage()
page.settings.userAgent = "PhantomJS"
//page.onConsoleMessage = function (msg) { console.log(msg); }
page.open(url, function (status) {
if (status !== 'success') {
console.log('Unable to access network')
phantom.exit()
} else {
setTimeout(function(){
console.log(getDocumentElementAsHTML(page))
phantom.exit()
},10000)
}
});
PS: Waiting 10 seconds is not always a great solution, I used to periodically test the existence of the elements I wanted to get information from to be sure the JavaScript finished loading instead.
Source: grey-hat stuff I did in the past
I'd say you'd want to look at http://phantomjs.org/, http://www.slimerjs.org/, and/or http://casperjs.org/.
Phantom & Slimer give you API access to Webkit and Gecko respectively. Casper adds a more user friendly API over the top.
Can javascript detect when a user saves the web page to their local disks? Or is there a similar functionality in some other client side scripts?
You could watch the key commands for the combination of ctrl + s to be hit. But if the user chooses to save through the menu, there is no way to capture that.
JavaScript cannot do this, nor any other client-side language. As a matter of fact, there are no server-side languages that can do that either. As others stated, you can watch for a keyboard combination, but there is (currently) no way to detect that.
It can't - and maybe some browser extensions can do it but it's highly unpractical to even expect random users install those just for this.
But you could for example try with some other methods:
right click custom function - enabling saving custom save page (while loging to backend),
capturing CTRL+s (as mentioned by Juan Mendes),
having some sort of tracking on the page that is triggered only when page is not accessed via your domain (for example image on your server that is requested only with special conditions)...
offering PDF document for saving and measuring it's requests (via backend method)...
So - shortly - no 100% solution...
As others have illustrated already; via CTRL + S but not via the menu command
Here's some jQuery that illustrates capture of the keystrokes:
$(document).keydown(function(e) {
if (e.key === "s" && e.ctrlKey) {
alert("user saved page");
}
});
Is it possible to disable the IE developer console?
I tried this
<script type="'text/javascript'">
(function(){
var _z = console;
Object.defineProperty( window, "console", {
get : function(){
if( _z._commandLineAPI ){
throw "Sorry, Can't exceute scripts!";
}
return _z;
},
set : function(val){
_z = val;
}
});
})();
</script>
but didn't work
No, it's not.
You can't force a browser (not) to do something like that.
Even if it were possible, the user always has access to the scripts you send to the browser. Besides, it's relatively easy to write a bookmarklet that adds a input element to the page that can serve as impromptu console.
I suspect you are doing this to prevent users from executing arbitrary code on your page. Like others have mentioned, there will always be ways to circumvent this kind of artificial restrictions (ex: bookmarklets). You should instead focus on Server-side validation and treat all data that comes from the user as suspect.
That said... If you are hard-set on disabling JS execution from the console, disable the EVAL statement (which the F12 console uses to evaluate script).
Example:
eval = function() {}
The only way to disable the F12 tools is via the registry:
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\IEDevTools]
"Disabled"=dword:00000001
Which can also be set by group policy as documented "Turn Off Developer Tools".
This won't help you as a web site owner block F12 but if you're in an enterprise it's an option. But really your page is running on the clients machine and they can use any number of techniques to interact with it if they want to put the effort in.
Note: You can hack things to try to break the tools but that's not a supported mechanism to disable it :).
Since 12 june 2012 11:20 TU, I see very weirds errors in my varnish/apache logs.
Sometimes, when a user has requested one page, several seconds later I see a similar request but the all string after the last / in the url has been replaced by "undefined".
Example:
http://example.com/foo/bar triggers a http://example.com/foo/undefined request.
Of course theses "undefined" pages does not exist and my 404 page is returned instead (which is a custom page with a standard layout, not a classic apache 404)
This happens with any pages (from the homepage to the deepest)
with various browsers, (mostly Chrome 19, but also firefox 3.5 to 12, IE 8/9...) but only 1% of the trafic.
The headers sent by these request are classic headers (and there is no ajax headers).
For a given ip, this seems occur randomly: sometimes at the first page visited, sometimes on a random page during the visit, sometimes several pages during the visit...
Of course it looks like a javascript problem (I'm using jquery 1.7.2 hosted by google), but I've absolutely nothing changed in the js/html or the server configuration since several days and I never saw this kind of error before. And of course, there is no such links in the html.
I also noticed some interesting facts:
the undefined requests are never found as referer of another pages, but instead the "real" pages were used as referer for the following request of the same IP (the user has the ability to use the classic menu on the 404 page)
I did not see any trace of these pages in Google Analytics, so I assume no javascript has been executed (tracker exists on all pages including 404)
nobody has contacted us about this, even when I invoked the problem in the social networks of the website
most of the users continue the visit after that
All theses facts make me think the problem occurs silently in the browers, probably triggered by a buggy add-on, antivirus, a browser bar or a crappy manufacturer soft integrated in browsers updated yesterday (but I didn't find any add-on released yesterday for chrome, firefox and IE).
Is anyone here has noticed the same issue, or have a more complete explanation?
There is no simple straight answer.
You are going to have to debug this and it is probably JavaScript due to the 'undefined' word in the URL. However it doesn't have to be AJAX, it could be JavaScript creating any URL that is automatically resolved by the browser (e.g. JavaScript that sets the src attribute on an image tag, setting a css-image attribute, etc). I use Firefox with Firebug installed most of the time, so my directions will be with that in mind.
Firebug Initial Setup
Skip this if you already know how to use Firebug.
After the installs and restarting Firefox for Firebug, you are going to have to enable most of Firebug's 'panels'. To open Firebug there will be a little fire bug/insect looking thing in the top right corner of your browser or you can press F12. Click through the Firebug tabs 'Console', 'Script', 'Net' and enable them by opening them up and reading the panel's information. You might have to refresh the page to get them working properly.
Debugging User Interaction
Navigate to one of the pages that has the issue with Firebug open and the Net panel active. In the Net panel there will be a few options: 'Clear', 'Persist', 'All', 'Html', etc. Make sure ALL is selected. Don't do anything on the page and try not to mouse over anything on it. Look through the requests. The request for the invalid URL will be red and probably have a status of 404 Not Found (or similar).
See it on load? Skip to the next part.
Don't see it on initial load? Start using your page and continue here.
Start clicking on every feature, mouse over everything, etc. Keep your eyes on the Net panel and watch for a requests that fail. You might have to be creative, but continue using your application till you see your browser make an invalid request. If the page makes many requests, feel free to hit the 'Clear' button on the top left of the Net panel to clear it up a bit.
If you submit the page and see a failed request go out really quick but then lose it because the next page loads, enable persistence by clicking 'Persist' in the top left of the Net panel.
Once it does, and it should, consider what you did to make that happen. See if you can make it happen again. After you figure out what user interaction is making it happen, dive into that code and start looking for things that are making invalid requests.
You can use the Script tab to setup breakpoints in your JavaScript and step through them. Investigate event handlers done via $(elemment).bind/click/focus/etc or from old school event attributes like onclick=""/onfocus="" etc.
If the request is happening as soon as the page loads
This is going to be a little harder to peg down. You will need to go to the Script tab and start adding break points to every script that runs on load. You do this by clicking on the left side of the line of JavaScript.
Reload your page and your break points should stop the browser from loading the page. Press the 'Continue' button on the script panel. Go to your net panel and see if your request was made, continue till it is found. You can use this to narrow down where the request is being made from by slowly adding more and more break points and then stepping into and out of functions.
What you are looking for in your code
Something that is similar to the following:
var url = workingUrl + someObject['someProperty'];
var url = workingUrl + someObject.someProperty;
Keep in mind that someObject might be an object {}, an array [], or any of the internal browser types. The point is that a property will be accessed that doesn't exist.
I don't see any 404/red requests
Then whatever is causing it isn't being triggered by your tests. Try using more things. The point is you should be able to make the request happen somehow. You just don't know yet. It has to show up in the Net panel. The only time it won't is when you aren't doing whatever triggers it.
Conclusion
There is no super easy way to peg down what exactly is going on. However using the methods I outlined you should be at least be able to get close. It is probably something you aren't even considering.
Based on this post, I reverse-engineered the "Complitly" Chrome Plugin/malware, and found that this extension is injecting an "improved autocomplete" feature that was throwing "undefined" requests at every site that has a input text field with NAME or ID of "search", "q" and many others.
I found also that the enable.js file (one of complitly files) were checking a global variable called "suggestmeyes_loaded" to see if it's already loaded (like a Singleton). So, setting this variable to false disables the plugin.
To disable the malware and stop "undefined" requests, apply this to every page with a search field on your site:
<script type="text/javascript">
window.suggestmeyes_loaded = true;
</script>
This malware also redirects your users to a "searchcompletion.com" site, sometimes showing competitors ADS. So, it should be taken seriously.
You have correctly established that the undefined relates to a JavaScript problem and if your site users haven't complained about seeing error pages, you could check the following.
If JavaScript is used to set or change image locations, it sometimes happens that an undefined makes its way into the URI.
When that happens, the browser will happily try to load the image (no AJAX headers), but it will leave hints: it sets a particular Accept: header; instead of text/html, text/xml, ... it will use image/jpeg, image/png, ....
Once such a header is confirmed, you have narrowed down the problem to images only. Finding the root cause will possibly take some time though :)
Update
To help debugging you could override $.fn.attr() and invoke the debugger when something is being assigned to undefined. Something like this:
(function($, undefined) {
var $attr = $.fn.attr;
$.fn.attr = function(attributeName, value) {
var v = attributeName === 'src' ? value : attributeName.src;
if (v === 'undefined') {
alert("Setting src to undefined");
}
return $attr(attributeName, value);
}
}(jQuery));
Some facts that have been established, especially in this thread: http://productforums.google.com/forum/#!msg/chrome/G1snYHaHSOc/p8RLCohxz2kJ
it happens on pages that have no javascript at all.
this proves that it is not an on-page programming error
the user is unaware of the issue and continues to browse quite happily.
it happens a few seconds after the person visits the page.
it doesn't happen to everybody.
happens on multiple browsers (Chrome, IE, Firefox, Mobile Safari, Opera)
happens on multiple operating systems (Linux, Android, NT)
happens on multiple web servers (IIS, Nginx, Apache)
I have one case of googlebot following the link and claiming the same referrer. They may just be trying to be clever and the browser communicated it to the mothership who then set out a bot to investigate.
I am fairly convinced by the proposal that it is caused by plugins. Complitly is one, but that doesn't support Opera. There many be others.
Though the mobile browsers weigh against the plugin theory.
Sysadmins have reported a major drop off by adding some javascript on the page to trick Complitly into thinking it is already initialized.
Here's my solution for nginx:
location ~ undefined/?$ {
return 204;
}
This returns "yeah okay, but no content for you".
If you are on website.com/some/page and you (somehow) navigate to website.com/some/page/undefined the browser will show the URL as changed but will not even do a page reload. The previous page will stay as it was in the window.
If for some reason this is something experienced by users then they will have a clean noop experience and it will not disturb whatever they were doing.
This sounds like a race condition where a variable is not getting properly initialized before getting used. Considering this is not an AJAX issue according to your comments, there will be a couple of ways of figuring this out, listed below.
Hookup a Javascript exception Logger: this will help you catch just about all random javascript exceptions in your log. Most of the time programmatic errors will bubble up here. Put it before any scripts. You will need to catch these on the server and print them to your logs for analysis later. This is your first line of defense. Here is an example:
window.onerror = function(m,f,l) {
var e = window.encodeURIComponent;
new Image().src = "/jslog?msg=" + e(m) + "&filename=" + e(f) + "&line=" + e(l) + "&url=" + e(window.location.href);
};
Search for window.location: for each of these instances you should add logging or check for undefined concats/appenders to your window.location. For example:
function myCode(loc) {
// window.location.href = loc; // old
typeof loc === 'undefined' && window.onerror(...); //new
window.location.href = loc; //new
}
or the slightly cleaner:
window.setLocation = function(url) {
/undefined/.test(url) ?
window.onerror(...) : window.location.href = url;
}
function myCode(loc) {
//window.location.href = loc; //old
window.setLocation(loc); //new
}
If you are interested in getting stacktraces at this stage take a look at: https://github.com/eriwen/javascript-stacktrace
Grab all unhandled undefined links: Besides window.location The only thing left are the DOM links themselves. The third step is to check all unhandeled DOM links for your invalid URL pattern (you can attach this right after jQuery finishes loading, earlier better):
$("body").on("click", "a[href$='undefined']", function() {
window.onerror('Bad link: ' + $(this).html()); //alert home base
});
Hope this is helpful. Happy debugging.
I'm wondering if this might be an adblocker issue. When I search through the logs by IP address it appears that every request by a particular user to /folder/page.html is followed by a request to /folder/undefined
I don't know if this helps, but my website is replacing one particular *.webp image file with undefined after it's loaded in multiple browsers. Is your site hosting webp images?
I had a similar problem (but with /null 404 errors in the console) that #andrew-martinez's answer helped me to resolve.
Turns out that I was using img tags with an empty src field:
<img src="" alt="My image" data-src="/images/my-image.jpg">
My idea was to prevent browser from loading the image at page load to manually load later by setting the src attribute from the data-src attribute with javascript (lazy loading). But when combined with iDangerous Swiper, that method caused the error.
Is there a way to check in JavaScript if given a host its SSL certificate is valid? (non blocking)
In my case, I want to display: "you can also use https://.." if via JavaScript I can make a request to https://my_url without being asked to accept an untrusted certificate.
Can this be done asynchronously?
Take a look here: https://support.mozilla.org/pl/questions/923494
<img src="https://the_site/the_image" onerror="redirectToCertPage()">
This solution is tested and working in current versions of FF and Chrome (as of 2022):
<script> var sslCertTrusted = false; </script>
<script src="https://example.com/ssltest.js"></script>
<script>
if (!sslCertTrusted)
{
alert('Sorry, you need to install the certificate first.');
window.location.replace('http://example.com/cert_install_instructions/');
}
else
{
// alert('Redirecting to secure connection')
window.location.replace('https://example.com/');
}
<script>
You of course need to make your web server return this code under the URL https://example.com/ssltest.js:
sslCertTrusted = true;
I'm not exactly sure about the details. But I've seen similar technology used to detect adblocking etc. You may need to piggyback on the window object maybe, if the variable can't be modified by another script, but generally making the above proof of concept work is left as an exercise to the reader.
What I've found up to now - it is possible with Firefox, don't know yet about other browsers:
https://developer.mozilla.org/En/How_to_check_the_security_state_of_an_XMLHTTPRequest_over_SSL
The straight answer is no. Javascript does not provide any means of validating certificates. This is a job left to the browser.
A better approach to this problem is from the server side. If you are controlling the site, than you can render down a variable on the page with information gleaned on the server side.
In .Net something like
var canSecure = <%= MySiteHasSsl ? "true" : "false" %>;
if (canSecure) {
if (confirm("This site supports SSL encryption. Would you like to switch to a secure connection?")) {
location.href = "https://mysite.com";
}
}
I'm not quite sure what your use case is. If you are just trying to "check ahead of time" before you provide a link to someone for another website then the other answers here will be more relevant than mine.
If you are expecting mysite.com to use an SSL certificate that isn't trusted by default in the browser but you have another way of knowing it should be trusted, then you could use a JavaScript TLS implementation to make cross-domain requests to that other site. However, this requires that your website be served on https and trusted in the browser to begin with and the other site to provide a Flash cross-domain policy file.
If this sounds anything like what you want to do, check out the open source Forge project at github:
http://github.com/digitalbazaar/forge/blob/master/README.md
Useful notice: navigator.clipboard will be undefined on Chrome browsers if there's no valid SSL certificate.
The question doesn't make sense. You can't get the server's SSL certificate without opening an SSL connection to it, and once you've done that, telling the user they can do that too is a bit pointless.
You could run a server elsewhere that handles certificate checks based on whatever you want, then your javascript application sends a request to that server asking for a checkup. This does require that you have at least one server somewhere in the world that you can trust.
A query of this nature can be done in the background quite easily.