一切的前端安全都是纸老虎

Z时代
2024-01-10
分类：技术分享

引子

最近逼乎有一个很火热的问题，叫前端能否限制用户截图？

20200911180320

当我看到这个问题，我就觉得这个提问者应该是个萌新，或者已经被产品经理或SB leader 折磨的失去理智。因为下方有一个非常直中要害的回答：

这个问题，真的说明一切的前端安全，其实都是纸老虎。

接下来，我结合自己遇到的几个场景，来谈一些做前端以来，自己遇到的那些伪前端安全需求。

曾经那些被怼回去的安全需求

最近几年互联网数据泄露非常频繁，我上一家公司是做金融贷款的，非常强调数据安全，这两年也做了不少关于安全的需求。

前端数据脱敏

前端数据脱敏是一个很常见的需求，特别是当今隐私被卖的这么猖狂的时代，所以很多公司都开始注重这些细节，最基础的就是数据脱敏。

数据脱敏，就是将用户的隐私信息，用一些手段，让这些信息有一定辨识度，但又无法准确获取，比如：

金*胖

186**2892

510*1262

川A 7*1

上面一般是我们常见到的数据脱敏格式，我又叫他数据马赛克。前端能不能做，肯定能做，一个正则配上一个String.replace方法就搞定。但如果产品让我们实现这种需求，我们肯定要拒绝，因为前端做数据脱敏就是被单里眨眼睛 - 自欺欺人。

归根揭底，一个稍微有点IT常识的人，如果想要这些数据，直接从请求拿就是了，何必从页面复制。

所以数据脱敏这种事，一定要交给后端做，从源头开始脱敏。

可能后面一些场景，有些被脱敏的数据，在前端又要被用到。比如列表数据脱敏，到详情/表单编辑操作时又需要脱敏前的，那就根据ID再发一次请求获取脱敏前的数据，然后对这个接口调用做权限限制和日志记录，让敏感数据的使用相对安全。

表单校验是为了安全么

我们在做表单时，很多时候都会针对数据格式做校验，比如邮箱、电话号码、银行卡号这些，甚至还有一些非常复杂的联动校验。
20200913211120

前端做校验是为了安全么？

可能有那么一丁点意思吧，比如以前我们总是在提校验输入防XSS攻击。但现在前端这种格式校验，更多是为了：提升用户体验,提升用户体验,提升用户体验。

首先提醒并引导用户，应该怎么输入；

其次，如果用户输入半天，前端不校验，直接到后台，后台发现格式不正确，再提示用户，这是一个非常耗时且不专业的交互体验；

如果前端没校验，后端也没校验，那这就是一条脏数据插入到数据库，有可能造成XSS攻击 或 SQL攻击, 这就非常危险了。

数据报表加水印

页面加水印，其实在前端很普遍，比如钉钉, 企业微信 的群聊都是加了水印的，很多在线图片编辑工具也是加了的，比如我常用的图怪兽，你想白嫖，他就给你加个水印：
20200912214649

而当时我们有些列表，因为运营需要，有些数据没法做数据脱敏，所以领导说，前端能不能做个水印，让数据安全一点：防止运营人员不按规范处理问题，私自截图。所以当我看到知乎那个提问是，我特别庆幸，没有让我做：限制用户截图。

从我个人经验来讲，前端加水印有三个层次：

通过 CSS 背景加水印，简单粗暴，能骗一点文科运营。但稍微懂行的人，就知道通过 Elements 编辑面板屏蔽这个水印。正所谓你加的简单，别人去掉更简单。

通过 JS 定向植入水印dom节点，这个比上一个稍微复杂点，但还是通过Elements 编辑面板屏蔽，只不过多思考一下，操作步骤多点。

终解: 服务端加水印生成列表图片，实现思路和图怪兽网站一致。但这个操作描述起来简单，具体实现就非常复杂，需要考虑投入产出比。

有可能你会疑问，为什么是服务端加水印生成图片，而不是前端自己通过 canvas 生成？

第一，同上面提到过的，通过请求拿到敏感数据，本身就是不安全的；

第二，JS 本身是不安全的，可篡改；

JS 可篡改

我上面反复在说前端安全是个伪需求，你可能不信。但如果你知道 JS 是可篡改的，那你就明白为什么了。我们总是在提JS丑化，但丑化更多是减少包的体积，在某种程度上，可以让发布的js资源可读性更差，但做到不可读很难。

接下来体验一下什么叫 JS 可篡改吧

实战演练

第一步：Chrome 下载安装 Header Editor 插件

20200914181822

第二步：找一个目标网站，并找到一个你想篡改的 JS 资源。我这里以我常用的作图网站的jquery 资源（https://js.tuguaishou.com/js/...）引用为例；

第三步：拷贝代码带编辑器，输入你想篡改的内容，我这里就只加了个console输出, 然后本地起一个静态资源服务

  // ...
console.log('do some change, ho ho ho');
var c = []
, d = c.slice
, e = c.concat// ...

第四步，使用插件重定向网站静态资源，我这里就是使用本地的jquery 代替网站原有的，保存配置并启动那个规则；

20200914182637

第五步: 强刷浏览器，使代理资源生效，当你看到请求被标成了307的响应，说明篡改生效，然后看console，就有了对应的输出；

20200914183058

至此，一次完整的篡改完成。但这个教程并不是让你用这个方法去做一些XX的事情，而只是让你明白由于JS的可篡改，我们在做网站设计时，你需要时刻思考代码安全的事，能做不代表可以做。

分享个趣事

年初，前公司要做一次大的系统融合：就是两个子公司各有各的权限系统，然后资本青睐的一方占优(以系统设计来讲，我们的权限系统设计更专业)，被遗弃的我们不得不改我们现有系统，去对接对方的系统。

这中间因为异地沟通问题，对方开始没把规则说好，然后对接人将我们清洗重组后的数据导入了数据库。后面由于需要修改一些数据，网站页面提示我们导入数据key的格式不对，而这个key，又被设置成了只读，这就走入了死路。然后沟通能不能把数据库数据删除了重新导入，对方一万个不情愿，让我们自己在网站上自己删除再添加数据，那可是200多条数据啊，侮辱谁呢？？？？
20200915093613
这真的把我同事们惹毛了，然后就试了上面的招数，看了对方的JS，代理然后再一提交，成功！！！