Which way to disable firebug in my website?

Question

I want to disable firebug using on each my webpages. Sometimes , we embedded important keys or id in my ui widgets. Some of our methods from server side will takes these keys for processing. So , someone can edit by firebug. That may cause wrong data updating of our database or wrong data showing in webpages. For security options , I want to disable using firebug or other developer tools of browsers. As GoogleChrome 's home page , when I open firebug in it , I want to show error message as follow..

How can I do as like it ? Eg: I want to validate my form datas with JavaScript or such as using with JQuery Form Validation That's fine. But when I use with firebug and delete elements of error messages will become validate this form.How to prevent it !Any suggestions would be appreciated. Really I means not only firebug but also others developer tools, addons , plugins. My question main point is how to disabling them. FireBug in Chrome Browser home page process and validation form instances are examples for I want to do.

Answer 1

TL;DR There is no way to achieve any kind of security that way. You can never trust the client.

In the end, a browser is just downloading a bunch of HTML and JavaScript files (and images, and CSS, etc.) and executing/presenting them in a window for you, following specifications on how to display HTML and CSS and how to execute JavaScript. An Internet browser isn't saving the files to your disk like you would download a document, but it's really not any different. (well, it is downloading the files, just not in your "Documents" folder) It's just doing everything in the context of browsing the web to make it convenient for the user to view nicely formatted pages, as opposed to HTML markup. But these files are just files and can live (i.e. be read and edited) outside of the browser context.

So if you have any sort of secret key in one of your JavaScript files, disallowing Firebug Lite won't prevent anyone from accessing the secret key because I could just download that file with tools like curl or wget and read it in a text editor. Keep in mind that anything done in a browser can be done "manually" with curl.

Let's imagine you had a way to disallow Firebug Lite in your page through some JavaScript. I could always use some kind of custom browser that behaves the exact same way as a browser except that it wouldn't execute that particular code. It's a convention that the browser will execute all code served for a page, but nothing technically stops it from being selective. (and many browser extensions actually make them become selective. AdBlock comes to mind)

Don't get me wrong: client-side validation in forms is useful and convenient, but it should never replace server-side validation. You need to write server-side code that will validate the identity of the user (typically through a cookie) for all queries and only execute the query if that user has the proper permissions. (you would also want to check the validity of the input values of course)

Answer 2

There is no way to remotely disable or affect plugins in the user's browser. Being able to do so would represent a massive security hole. There are ways of detecting whether they're using adblock, but beyond that you need to work around such plugins, rather than try to defeat them.

As far as I'm concerned, the number 1 rule of web programming is never trust user input. No matter what you do on the client end, a clever and determined user will always be able to find a way to break your site, send invalid data, etc. To that end:

1. Validate in the browser, but ALSO validate on the server. All someone has to do is disable javascript, and your client-side validation will not execute. Or, if they're very determined, they could save a copy of the html file locally, edit out the bits that are stopping them from doing what they want, and then load up their own version in their browser and submit from it instead. You cannot prevent this, so you have to account for it instead by validating all input at the server before you do anything with it.

2. Do not put sensitive data unencrypted in the browser. Even if it's in a hidden field, they can again go into the code, read/change it, and then submit their own version afterwards again. If possible, cache such data on the server. If that's not possible, give it to the user encrypted, so that even if they can see the value it will be meaningless to them.

Look at it this way: browser validation is for the user's benefit, so they don't waste bandwidth; server validation is for the system's benefit, to make sure you don't accept invalid data.

The only instance where you can get away with not doing these things is if you're developing a private application for a professional client who has no reason to do any of these things, and even then you should be in the habit of validating input on the server as a matter of course anyway. So it really doesn't matter what you're building or what your expectations are, you should always validate in both places, client and server.

Answer 3

Let's have an actual answer to this question, as in, how is it that some pages cannot run Chrome extensions. Hardcoded reasons:

1. There is a specific exception that Chrome Extensions cannot touch Chrome Web Store pages. In the Chromium source code, that would ChromeExtensionsClient::IsScriptableURL. Quoting:

   // The gallery is special-cased as a restricted URL for scripting to prevent
   // access to special JS bindings we expose to the gallery (and avoid things
   // like extensions removing the "report abuse" link).
   

   One can override this restriction by a command line flag: --allow-scripting-gallery

2. The exception in the question itself: New Tab page is not allowed for content scripts, since it's on a chrome:// URI scheme. In the source code, you can see ChromeExtensionsClient::GetPermittedChromeSchemeHosts:

   // Regular extensions are only allowed access to chrome://favicon
   

   Extensions can override a new tab page, but not inject their scripts into one.

   It can be overridden with a Chrome flag.

I'm leaving this as a community wiki, so people can freely add to this answer.

As noted in other answers, disallowing extensions on regular pages is an arms race one cannot win.

Answer 4

Rule number two. You can't prevent your scripts to potentially be hacked, but you should make it as hard as possible.

Nowadays FB 2 offers a pretty print button, while you are hard working on/with a uglifier. All the tricks and gimmicks you can't hide anymore. Why it shouldn't be helpful to switch off or disallow debuggers if you are online to take away a hacker's or layperson's toy.

By the way all answers are off topic. The asker is the king.

Maybe I come back with an answer.

Back again: I found out that the number of console ins ff is different with (21) or without (18) firebug. But console has no property length. Do a for in.

  if(console.hasOwnProperty('exception')){
    alert('please switch off FB');
    }

After that little cotton swab war, I found that pretty solution of Keith Chadwick. Devtools have problems with anonymous functions. So his idea is to wrap your script in:

 (function(){***your script***}());

and call the following function on load and resize:

var test=function(){
         if(document.getElementsByTagName('script').length>1 
         || (screen.availHeight-window.innerHeight)>150){
            window.location.href='securityabort.html';
         }
};      

That do not make debugging impossible (I know) but harder.