0

我想在我的每个网页上禁用萤火虫。有时，我们在我的 ui 小部件中嵌入了重要的键或 id。我们来自服务器端的一些方法将使用这些密钥进行处理。因此，有人可以通过 firebug 进行编辑。这可能会导致我们数据库的错误数据更新或网页中显示的错误数据。对于安全选项，我想禁用使用 firebug 或其他浏览器开发工具。作为GoogleChrome的主页，当我在其中打开 firebug 时，我想显示如下错误消息..

Chrome 错误提示框

我该怎么做呢？例如：我想使用 JavaScript 验证我的表单数据，或者使用JQuery 表单验证 ，这很好。但是，当我使用 firebug 并删除错误消息的元素时，将成为验证此表单。如何防止它！任何建议将不胜感激。真的，我指的不仅是 firebug，还包括其他开发人员工具、插件、插件。我的问题主要是如何禁用它们。Chrome 浏览器主页进程中的 FireBug 和验证表单实例是我想做的示例。

4

4 回答 4

7

TL;DR 没有办法以这种方式实现任何类型的安全性。你永远不能相信客户。

最后，浏览器只是下载一堆 HTML 和 JavaScript 文件（以及图像和 CSS 等）并在窗口中执行/呈现它们，遵循关于如何显示 HTML 和 CSS 以及如何执行的规范JavaScript。Internet 浏览器不会像下载文档那样将文件保存到磁盘，但实际上并没有什么不同。（嗯，它正在下载文件，只是不在您的“文档”文件夹中）它只是在浏览网页的上下文中做所有事情，以方便用户查看格式良好的页面，而不是 HTML 标记。但是这些文件只是文件，可以在浏览器上下文之外存在（即被读取和编辑）。

因此，如果您的 JavaScript 文件中有任何类型的密钥，禁用 Firebug Lite 不会阻止任何人访问该密钥，因为我可以使用curl或wget等工具下载该文件并在文本编辑器中阅读它。请记住，在浏览器中完成的任何事情都可以使用 curl “手动”完成。

假设您有办法通过一些 JavaScript 在您的页面中禁用 Firebug Lite。我总是可以使用某种自定义浏览器，其行为方式与浏览器完全相同，只是它不会执行该特定代码。这是一个约定，浏览器将执行为页面提供的所有代码，但从技术上讲，没有什么能阻止它具有选择性。（许多浏览器扩展实际上使它们变得有选择性。想到 AdBlock）

不要误会我的意思：表单中的客户端验证有用且方便，但它永远不应该取代服务器端验证。您需要编写服务器端代码来验证所有查询的用户身份（通常通过 cookie），并且仅在该用户具有适当权限时才执行查询。（当然，您还想检查输入值的有效性）

于 2013-09-05T16:42:02.357 回答
5

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.

于 2013-09-07T03:03:06.167 回答
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.

于 2014-06-15T09:02:29.723 回答
0

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.

于 2014-06-14T07:37:26.960 回答