可信前端之路-代码保护

摘要： 可信前端之路-代码保护       0x00 前言 在信息安全领域，可信系统（Trusted system）是一个让人心动的目标，它指的是一个通过实施特定的安全策略而达到一定可信程度的系统。 在计算机中，可信平台模块（Trusted Platform Module，TPM）已经投入使用，它符合可信赖计算组织（Trusted Computing Group，TCG）制定的TPM规范，是为了实现可信系统目标的而打造的一款安全芯片。

可信前端之路-代码保护

 

 

 

0x00 前言

在信息安全领域，可信系统（Trusted system）是一个让人心动的目标，它指的是一个通过实施特定的安全策略而达到一定可信程度的系统。

在计算机中，可信平台模块（Trusted Platform Module，TPM）已经投入使用，它符合可信赖计算组织（Trusted Computing Group，TCG）制定的TPM规范，是为了实现可信系统目标的而打造的一款安全芯片。作为可信系统的信任根，TPM是可信计算的核心模块，为计算机安全提供了强有力的保障。

而在我们的web系统中，想打造一个可信系统似乎是个伪命题，"永远不要相信客户端的输入"是基本的安全准则。实际上，在可信系统中的可信也并不是说真的是绝对安全，维基上对其的解释为：“可信的”（Trusted）未必意味着对用户而言是“值得信赖的”（Trustworthy）。确切而言，它意味着可以充分相信其行为会更全面地遵循设计，而执行设计者和软件编写者所禁止的行为的概率很低。

从这个角度讲，我们把其当做一个美好的愿景，我们希望能够构造一个web系统中的TPM，可以把恶意行为控制在一定的概率之内，从而实现一个相对可信的web系统。

0x01 可信前端

在可信系统中，TPM的一个重要作用就是鉴别消息来源的真实性，保障终端的可信。在web系统中，我们的消息来源就是用户。随着撞库、恶意注册、薅羊毛等产业的蓬勃发展，在越来越多的场景我们需要鉴别请求数据是否来自真实的用户，保护真实用户的数据安全。

所以想要构造一个web系统中的TPM，首要问题就是需要保证输入数据安全，打造一个相对可信的前端环境。但是由于web的开放特性，前端作为数据采集的最前线，js代码始终暴露在外，在这种情况下，防止恶意伪造请求变得非常困难，可信前端也就成了无稽之谈。

在反复对抗中，代码保护也就是通常意义上的js代码混淆的重要性逐渐彰显出来。今天我就想和大家聊一聊js混淆的问题。

1、为什么需要js混淆

显而易见，是为了保护我们的前端代码逻辑。

在web系统发展早期，js在web系统中承担的职责并不多，只是简单的提交表单，js文件非常简单，也不需要任何的保护。

随着js文件体积的增大，为了缩小js体积，加快http传输速度，开始出现了很多对js的压缩工具，比如 uglify、compressor、clouser。。。它们的工作主要是

· 合并多个js文件

· 去除js代码里面的空格和换行

· 压缩js里面的变量名

· 剔除掉注释

压缩后的代码

虽然压缩工具出发点都是为了减少js文件的体积，但是人们发现压缩替换后的代码已经比源代码可读性差了很多，间接起到了代码保护的作用，于是压缩js文件成为了前端发布的标配之一。但是后来市面上主流浏览器chrome、Firefox等都提供了js格式化的功能，能够很快的把压缩后的js美化，再加上现代浏览器强大的debug功能，单纯压缩过的js代码对于真正怀有恶意的人，已经不能起到很好的防御工作，出现了"防君子不防小人"的尴尬局面。

chrome开发者工具格式化之后的代码

而在web应用越来越丰富的今天，伴随着浏览器性能和网速的提高，js承载了更多的工作，不少后端逻辑都在向前端转移，与此同时也让更多的不法分子有机可乘。在web模型中，js往往是不法分子的第一个突破口。知晓了前端逻辑，不法分子可以模拟成一个正常的用户来实施自己的恶意行为。所以，在很多登录、注册、支付、交易等等页面中，关键业务和风控系统依赖的js都不希望被人轻易的破解，js混淆应运而生。

原文链接