前端源码安全

标签：

今天思考下前端源码安全的东西（不是前端安全，只是针对于源码部分）。在我看来，源码安全有两点，一是防止抄袭，二是防止被攻破。实际上讲，前端的代码大多是没有什么可抄袭性，安全更是形同虚设的（任何前端输入都是不能相信的）。但如果还是想防止源码被查看，HTML、CSS并不能做什么，最终都会用露出来（最简单用Chrome开发者工具就可以看到），所以只能针对JS做文件的压缩合并和混淆。

关于抄袭

其实就前端来讲，代码没有什么好抄袭的，大多人都是抄UI设计（这个是躲不了），还有一些富前端的控件和算法，重要之处还是在于后端，而后端是抄不了的。所以前端文件压缩合并，目的并不是防止抄袭，而是为了减少文件体积、加快载入速度，提高程序的执行性能，当然压缩也有混淆的功能。文件混淆是防止其他人查看代码逻辑，但是生成的代码比原代码体积大得多，所以文件如果做了混淆，加载速度和执行速度都会有所下降。

关于安全

所有的用户输入都是不能相信的，如果后端的检查校验还做得不好，那就可能被攻破。前端代码的逻辑如果还被了解清楚，那就是雪上加霜。后端的问题我们前端管不着，前端的代码安全，简单的可以用压缩解决、再进一步就去混淆，让别人看不懂。

HTML压缩

很少有人去做HTML的压缩（特指去除空白字符和注释），根据其他资料有几个原因：

1. HTML文档中，多个空白字符等价为一个空白字符。也就是说换行等空白字符的删除是不安全的，可能导致元素的样式产生差异。

2. HTML元素中，有一个pre, 表示 preformatted text. 里面的任何空白，都不能被删除。

3. HTML中有可能有 IE 条件注释。这些条件注释是文档逻辑的一部分，不能被删除。

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

CSS压缩合并

CSS压缩合并很常见，或者说是必做的，可以由后端动态生成或工具提前生成。目的也只是为了提高加载速度，CSS即便的压缩之后，代码也是清晰可见，没有混淆说法。CSS压缩合并的工具很多，一般是用sass、less直接生成压缩后的CSS，如果是直接压缩，用grunt还不错。

JS压缩合并混淆

在生产环境上，压缩合并是必做的。就如上面说的，目的不是为了防止暴露业务逻辑，是为了提高载入速度。在上一篇文章《AngularJS结合RequireJS做文件合并压缩的那些坑》，说了一点JS压缩合并要注意的东西。除了用RequireJS，直接使用grunt来做发布是不错的方式，开发后一键调用grunt。

grunt需要配置两个文件：

package.json：声明应用信息和使用依赖库的版本

{
    "name":"BingoTouch",
    "version":"3.0.0",
    "engines":{
        "node":">= 0.8.0"
    },
    "devDependencies":{
        "grunt":"~0.4.0",
        "grunt-contrib-concat":"~0.3.0",
        "grunt-contrib-copy" : "~0.4.1",
        "grunt-contrib-cssmin" : "~0.6.0",
        "grunt-contrib-uglify":"~0.2.0",
        "express":""
    }
}

Gruntfile.js：声明压缩合并的文件

module.exports = function(grunt){
     grunt.initConfig({
        pkg : grunt.file.readJSON(‘package.json‘),
        concat : {
            ‘dist/bingotouch.js‘ :
               [ ‘demo/js/ui.js‘,
                 ‘demo/js/module/ui.GarbageCollection.js‘,
                 ‘demo/js/module/ui.plugins.js‘]
        },
        uglify : {
            target : {
                files : {
                    ‘dist/bingotouch.min.js‘: ‘dist/bingotouch.js‘
                }
            }
        }
     });
    grunt.loadNpmTasks(‘grunt-contrib-concat‘);
    grunt.loadNpmTasks(‘grunt-contrib-uglify‘);
    grunt.registerTask(‘default‘, [‘concat‘,‘uglify‘]);
}

JS的混淆我到现在为止还没用过，原理都是类似的，混淆是把JS代码变成乱七八糟的字符串，然后用eval执行。

PS：uglify本身有一定的混淆作用，但也只是对变量名的混淆，混淆度并不够。

混淆前：

function hello(){
    alert(‘hello‘);
}

混淆后：

eval(function(p,a,c,k,e,r){e=String;if(!‘‘.replace(/^/,String)){while(c--)r[c]=k[c]||c;k=[function(e){return r[e]}];e=function(){return‘\\w+‘};c=1};while(c--)if(k[c])p=p.replace(new RegExp(‘\\b‘+e(c)+‘\\b‘,‘g‘),k[c]);return p}(‘1 0(){2(\‘0\‘)}‘,3,3,‘hello|function|alert‘.split(‘|‘),0,{})) 

不同混淆算法混淆的结果不一样，而且混淆后也不是一劳永逸，还是可以被反混淆的。另外混淆会降低程序执行性能，所以是否需要做混淆得做评估。

总结

我觉得做好文件压缩合并，简单的变量名混淆就可以了，并不需要那么彻底的混淆。即便是前端被人挖得清清楚楚，只要后端强劲也就没问题了。所以当你想进行代码混淆时候，想想是为了什么，值不值得。

本文为原创文章，转载请保留原出处，方便溯源，如有错误地方，谢谢指正。

本文地址 ：http://www.cnblogs.com/lovesong/p/5185543.html

前端源码安全

标签：

原文地址：http://www.cnblogs.com/lovesong/p/5185543.html