JS 指纹是在客户端使用诸如指纹2 之类的库计算的。
我的问题是,如果我通过 ajax 发送这个值,用户可以轻松地伪造这个值,并且只需发出一个虚假的 post 请求,该请求将由服务器代码(如 legit)解释。
我的问题是,如果发生这种情况,可以轻松绕过这个库,甚至无需更改浏览器中的任何属性(这将更改浏览器指纹)。
我的解释对吗?我如何确保该值的完整性?
JS 指纹是在客户端使用诸如指纹2 之类的库计算的。
我的问题是,如果我通过 ajax 发送这个值,用户可以轻松地伪造这个值,并且只需发出一个虚假的 post 请求,该请求将由服务器代码(如 legit)解释。
我的问题是,如果发生这种情况,可以轻松绕过这个库,甚至无需更改浏览器中的任何属性(这将更改浏览器指纹)。
我的解释对吗?我如何确保该值的完整性?
你不能,我也不会真的担心。
规则 1:来自用户计算机的所有输入都可以伪造,不能 100% 依赖。
如果您愿意,您可以使用服务器端指纹识别和库作为piwik 设备检测器来匹配数据,但您会无缘无故地让自己头疼。
90% 的访问您的用户不知道您在做什么,并为您提供可靠的数据。他们甚至没有广告拦截。他们会给你可靠的数据。
9% 的访问者可能有一个广告拦截器,它可能会也可能不会阻止这些 ajax 请求。他们希望您尊重他们的隐私,这样做是为了让他们成为客户。1% 的人可能知道那些 ajax 请求做了什么,但他们永远不会发现,因为他们懒得检查他们访问的每个网站的控制台。这 1% 中的 1% 可能会查看浏览器控制台并找出浏览器指纹。
那 1% 中的 1% 会窃取你的指纹代码。1% 的 1% 中的另外 1% 会试图为 lulz 伪造它,然后忘记它。
所以简而言之,不要打扰。人们也不会打扰。
但是,如果您真的必须打扰,并且让自己头疼:
gotcha.js?time=1283737273873
再次使用给定的“时间戳”获取参数的javascript请求使用服务器端脚本进行拦截。然后,您可以使用 ajax 来更新页面的内容。除此之外,我真的可以向您推荐:不要打扰。这不值得努力。想规避的人就会规避。他们将禁用 javascript,排除该脚本,在继续或离开站点之前清除所有 cookie,更改注册的字体插件等......不要追逐那些不想被追逐的人。专注于不关心的群体。
我如何确保该值的完整性?
为了简单地回答您,每当您想保护自己的完整性时,您也必须提供已发送消息的摘要。
在这里,我使用 Alice ( FrontEnd )、Bob ( BackEnd ) 和 Trudy(恶意用户) 来解释完整性的防御
假设:
Alice 想向 Bob 发送一个包含PLAIN_TEXT
(这里是您的指纹)的包,而 Trudy 是希望拦截该包并更改PLAIN_TEXT
.
对完整性的威胁:
特鲁迪可以捕捉到PLAIN_TEXT
并将其更改为她想要的任何内容。(实际上可能存在更多对诚信的威胁,但我希望故事简短。)
以下是 Alice 必须采取的保护包完整性的步骤:
PLAIN_TEXT
(称为text_digest
)的摘要。PLAIN_TEXT
,并获得一个新的package
( package
= PLAIN_TEXT
+ text_digest
)package
whole_package_digest
) whole_package_digest
到加密包,并将其发送给 Bob拦截后 Trudy 可以做什么:
选项 1. 尝试破解包的加密
选项 2. 尝试省略encrypted package
并附加她自己的包。
在鲍勃这边:
他解密package
,得到PLAIN_TEXT
。(他确保 Alice 已经发送了这个包裹,因为没有其他人拥有密钥)
PLAIN_TEXT
他使用相同的方法(我们称之为 this obtained_digest
)获得了的摘要,并将obtained_digest
与进行比较text_digest
,如果它们相等,则表示PLAIN_TEXT
没有被操纵。
最后,他获得了收到的包裹的摘要,并与它进行比较whole_package_digest
。如果它们相等,则意味着 Trudy 的第二个选项失败了。
请注意,在上述情况下,完整性高度依赖于机密性。但是,您可以同时使用对称和非对称方法进行加密。
在下图中,我试图更清楚地解释我想说的话:
检查客户端指纹的完整性是不可能的......对你来说最好的选择是使用 PHP 来检测内部系统......我写了一个库,但没有发布......如果你需要它,我可以发送它给你...
这个库的作用是检测设备的Mac地址......由于两个系统不能拥有相同的Mac地址......这是获得准确指纹的好方法。