保护谷歌浏览器扩展中的代码 [英] secure the code in google chrome extension

问题描述

我想写一个 google chrome 扩展，它应该向我的网站发出请求以发送和获取一些数据，所以，实际上我应该像这里写的那样做一个 ajax 请求 https://developer.chrome.com/extensions/xhr.html

I want to write a google chrome extension, that should make a request to my website to send and get some data, so, actually I should do an ajax request like it is written here https://developer.chrome.com/extensions/xhr.html

var xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.example.com/data.json", true);

我想问一下是否有办法以某种方式保护代码或阻止其他人使用我的 api，因为实际上其他用户在安装扩展时可以看到它的源代码，因此在我不知道的情况下使用我的 api

I wanted ask if there is a way to somehow secure the code or prevent others from using my api, because actually the other users can see the source code of the extension when they install it and so use my api without me being aware of it.

如果我需要进行某种身份验证，那么如何在进行 ajax 调用之前对用户进行身份验证?对于身份验证，我需要向我的服务器发送请求，但为此我应该发送，例如用户名和密码，应该保存在扩展文件的某个地方，实际上，用户在安装扩展时可以看到.

If I need to make some sort of authentication, than how can I authenticate the user before making the ajax call ? for authentication I will need to send a request to my server , but for that I should send , e.g. username and password, that should be saved somewhere in the extension's files, which, in fact, can be seen by the users, when they install the extension.

谢谢

推荐答案

不要相信浏览器，而是采取措施验证用户.因此，在这种情况下，您可能需要输入用于与服务器通信的密码.

Don't trust the browser, take steps to authenticate the user instead. So, in this case, you could require that YOU enter in a password that is used to communicate with your server.

您的 Google 扩展程序会简单地要求您在尝试使用 AJAX 与您的服务器通信之前输入密码.

Your Google extension would simple require you to enter in a password before it attempts to use AJAX to communicate with your server.

请注意，您应该建立保护自己免受暴力攻击的方法.因此，如果密码错误的数量超过少数，请执行诸如锁定所有内容之类的操作.

Be aware that you should build in means of protecting yourself from brute-force attacks. So, do things like lock everything down if there are more than some small number of wrong passwords, etc.

您也可以考虑使用密码来简单地解密 XHR 的目的地，但是如果您走这条路，您应该非常小心地存储它，因为这将在离线时被暴力破解.

You could also consider using the password to simply decrypt the destination of the XHR, but if you go this route, you should store this very carefully, because this will be brute-forceable offline.

编辑试图锁定一个 API 以便只有一个应用程序可以使用它是不切实际的，在技术上也不可能，所以你唯一的希望是使用 API 对用户进行身份验证，而不管他正在使用什么访问软件.您可以让用户签署一项协议，在法律上将他们限制在您的扩展范围内，但我怀疑这在很大程度上无法执行，并且会消耗您的时间来追踪滥用者.

EDIT Trying to lock down an API so that only a single application can use it is just not practical nor technically possible, so you're only hope of doing this is to authenticate the user using the API, regardless of the accessing software he is using. You could have the user sign an agreement that legally limits them to only your extension, but I suspect this will go largely unenforceable and will consume your time tracking abusers down.

如果您不希望未经授权的人甚至知道 API 在哪里，您可以使用带外机制执行身份验证:通过电话、电子邮件、短信，或者简单地，另一个可以授予用户权限的 API向您的 API 请求的密码或令牌必须随附.

If you don't want unauthorized people even knowing where the API is, you could perform authentication using an out-of-band mechanism: over the telephone, email, SMS, or simply, another API that will grant the user a password or token that requests to your API must be accompanied with.

在此带外过程中，您还可以授予用户一个唯一的 URI(API 访问点)，该 URI 仅对每个经过身份验证的会话有效(https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/，例如).在其他 URI 上向您的服务器发出的任何请求都将不起作用.然而，这在理论上与使用相同的 API 访问点并拥有一个好的密码并没有太大的不同.它只是改变了架构中将执行身份验证和/或授权检查的位置数量.

During this out-of-band process, you could also grant the user, a unique URI (the API access point) that is only valid per authenticated session (https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/, for example). Any requests to your server on OTHER URIs simply won't work. However, this isn't theoretically much different than using the same API access point, and having a good password. It just changes the number of places in your architecture that will be performing authentication and/or authorization checks.

<aside>我的投票是将授权/身份验证点的数量减少到尽可能少，这样您就可以花更多的时间在正确的地方而不是有多个地方以及可能存在多个逻辑缺陷或其他可能导致漏洞的因素.</aside>

<aside>My vote would be to reduce the number of authorization/authentication points to as few as possible so that you can spend more time on getting that one place correct rather than having multiple places and possibly multiple logic flaws or other things that could lead to vulnerabilities.</aside>

您还可以探索使用公钥基础设施和/或一次性密码方案或基于设备的令牌生成器等，但最终，您将允许经过身份验证和授权的用户使用您的 API.而且，多亏了互联网，这不会长期保持一个未公开的 URI.

You could also explore using Public Key Infrastructure and/or one-time passwords schemes or device-based token generators, etc., but in the end, you'll be allowing authenticated and authorized users to use your API. And, thanks to the Internet, this will not remain an undisclosed URI for long.

而且，更重要的是，它不会阻止某人自行使用数据.即使采取了所有这些措施，授权用户在将这些数据流式传输到您的扩展程序时收集这些数据也是微不足道的.或者，如果您使用点对点加密，他们可以截屏或对您的代码使用某种形式的 JS 内省，甚至从他们的计算机内存中提取数据.

And, more importantly, it will not prevent someone from using the data on their own. Even with all these measures in place, it would be trivial for an authorized user to collect this data as it is being streamed to your extension. Or, if you employ point-to-point encryption, they could screen-scrap or use some form of JS introspection on your very code or even extract the data from their computer's memory.

我知道您在这里寻找灵丹妙药，但它不存在.

I know you were looking for a silver bullet here, but it doesn't exist.

这篇关于保护谷歌浏览器扩展中的代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！