前端源码安全

今天思考下前端源码安全的东西,不讲前端安全的大课题,只是针对于源码部分。
在我看来,源码安全有两点,一是防止抄袭,二是防止被攻破。
实际上,前端的代码大多是没有什么可抄袭性,安全更是形同虚设的(任何前端输入都是不能相信的)。但如果还是想防止源码被查看,HTML、CSS并不能做什么,最终都会用露出来(WebShield之类的WAF类产品,可以做html加密,不在本文讨论之列),所以只能针对JS做文件的混淆加密。

关于抄袭
其实就前端来讲,多数代码没有什么好抄袭的,除了一些特效、游戏、前端展示性的类app功能,那么前端源码保护主要可以说为了防分析,防止人们知道其中逻辑,这里有两个案例:一个是之前锤子手机发布时的作弊丑闻,一个是小米手机在英国发布时的作弊事件,巧了,都是手机,都是作弊,都是前端JS代码引起的问题,被分析,曝光...,其实,做一下js混淆加密,这一切就都不会发生了,可惜了,这么大的公司,不注重前端安全,得不偿失啊。
混淆加密是防止其他人查看代码逻辑,生成的代码比原代码体积大一些,但现在的网速、机器性能、浏览器性能,完全不需要考虑这点性能损失。说了这么多,前端js代码混淆加密怎么做,推荐产品吧,国外有jscrmber,国内有jshaman,就推荐用国内的吧:Jshaman(http://www.jshaman.com/

关于安全
所有的用户输入都是不能相信的,如果后端的检查校验还做得不好,那就可能被攻破。前端代码的逻辑如果还被了解清楚,那就是雪上加霜。后端的问题我们前端管不着,前端的代码安全,就是用混淆加密解决,让别人看不懂。

HTML压缩
很少有人去做HTML的压缩(特指去除空白字符和注释),根据其他资料有几个原因:

1. HTML文档中,多个空白字符等价为一个空白字符。也就是说换行等空白字符的删除是不安全的,可能导致元素的样式产生差异。
2. HTML元素中,有一个pre, 表示 preformatted text. 里面的任何空白,都不能被删除。
3. HTML中有可能有 IE 条件注释。这些条件注释是文档逻辑的一部分,不能被删除。

也是鉴于上面几个原因,不提倡压缩HTML,通过服务器的gzip压缩就已经能达到很好的效果。


JS压缩合并混淆
在生产环境上,压缩合并是不必做的。但现在很多人都在做,号称是为了提高加载速度,事实上,不得不说:把多个html、css、js压缩成一个文件,这能快的了?原来一个文件100K,并行加载,是半行同时加载啊!2秒就加载完了。
压成一个后呢,经常可见的是达到好几MB,不能同时加载了,想想吧,是快了还是慢了,认为压成一个文件加载更快的人们啊,真得去交个智商税了。。。对单个js文件混淆加密就行了,不要压成一个文件,不要压成一个文件。重要的事情说两遍。

js代码混淆效果怎么样?

混淆加密前:
function hello(){
alert('hello');
}

混淆后:
var _0x08e6=['hello'];(function(_0x560c7b,_0x17e70b){var _0x56bb8b=function(_0x4ccb21){while(--_0x4ccb21){_0x560c7b['\x70\x75\x73\x68'](_0x560c7b['\x73\x68\x69\x66\x74']());}};_0x56bb8b(++_0x17e70b);}(_0x08e6,0x77));var _0x608e=function(_0x4d0ca4,_0x58e301){_0x4d0ca4=_0x4d0ca4-0x0;var _0x50ffc7=_0x08e6[_0x4d0ca4];return _0x50ffc7;};function hello(){alert(_0x608e('0x0'));}

绝对够用!

总结
1、前端安全需要重视,将来会越来越被重视,因为它真重要。
2、不要进行多文件压缩,不要把html、css、js压到一起,很不明智的做法。
3、前端安全,就是js代码安全,对js做混淆加密是正道!