此问题试图在Chrome扩展程序的API中引发真正的安全问题:如何在与您的服务进行互动时检查Chrome扩展程序的真实性。 如果有任何遗漏的可能性或任何误解,请随时在评论中询问我。
答案 0 :(得分:7)
我很遗憾地说,但由于一个简单的问题,你提出的这个问题实质上是不可解决的:你不能信任客户。而且因为客户端可以看到代码然后你无法解决问题。
来自客户端的任何信息都可以通过其他方式复制。这与基本相同的问题是,当试图证明当用户登录他们的帐户时,实际上是用户而不是其他人发现或获得了他们的用户名和密码。
互联网安全模型是围绕2个试图进行通信的各方建立的,而第三方无法模仿,修改或收听对话。在不隐藏扩展源代码的情况下,客户端与第三方无法区分(副本中的文件 - 无法确定哪个是哪个)。
如果源代码被隐藏,它就变成了另一个故事。现在,用户或恶意方无法访问真实客户端所知道的秘密,并且所有常规安全模型都适用。但是,Chrome会在扩展中允许隐藏源代码是值得怀疑的,因为它会产生其他安全问题。
如您所述,某些源代码可以使用NPAPI插件隐藏,但它的价格已经为您所知。
回到现状:
现在它变成了交互意味着什么的问题。
如果互动意味着当用户在页面上您想知道它是您的扩展程序还是其他人时,那么您最接近的就是在 app 下的扩展程序清单中列出您的页面记录here
的部分这将允许您在页面上询问是否使用
安装了应用程序 chrome.app.isInstalled
这将返回显示您的应用程序安装与否的布尔值。该命令记录在here
然而,这并没有真正解决问题,因为扩展程序可能已安装但未启用,并且还有另一个扩展程序模仿与您站点的通信。
此外,验证是在客户端进行的,因此可以覆盖使用该验证的任何函数来忽略此变量的结果。
但是,如果交互意味着制作XMLHttpRequests,那么你运气不好。由于源代码的可见性,无法使用当前方法完成,如上所述。
但是,如果将您的网站的可用性限制为授权实体,我建议您使用常规的身份验证方法:让用户登录将允许您创建会话。此会话将传播到扩展程序发出的所有请求,因此您可以在常规客户端登录信任问题,例如帐户共享等。这些当然可以通过让用户通过他们的Google帐户登录来管理,而这些帐户大多数都不愿意通过阻止似乎被误用的帐户来分享和进一步减轻。
答案 1 :(得分:1)
我建议做一些类似于Git使用的东西(看看http://git-scm.com/book/en/Git-Internals-Git-Objects来了解git如何实现它),即
创建您的每个文件内容的SHA1值 chrome-extension 然后重新创建另一个SHA1值 先前获得的连接SHA1值。
通过这种方式,您可以与服务器共享SHA1值并验证您的扩展,因为SHA1值将在任何人更改时更改您的任何文件。
使用一些伪代码更详细地解释它:
function get_authentication_key(){
var files = get_all_files_in_extension,
concatenated_sha_values = '',
authentication_key;
for(file in files){
concatenated_sha_values += Digest::SHA1.hexdigest(get_file_content(file));
}
$.ajax({
url: 'http://example.com/getauthkey',
type: 'post'
async: false,
success:function(data){
authentication_key = data;
}
})
//You may return either SHA value of concatenated values or return the concatenated SHA values
return authentication_key;
}
// Server side code
get('/getauthkey') do
// One can apply several type of encryption algos on the string passed, to make it unbreakable
authentication_key = Digest::<encryption>.hexdigest($_GET['string']);
return authentication_key;
end
此方法允许您检查是否已更改任何类型的文件,可能是图像文件,视频文件或任何其他文件。很高兴知道这件事是否也可以被打破。