关于JavaScript的代码安全性，你可以把代码文知件存在服务器端，在页面道中引用代码的时候应用服务器端的代码文件
xss是前端经常会遇到的问题，由于页面中的js都执行在同一个上下文中，意味着一旦出现xss漏洞，攻击者就能享有和页面其它部分js同样的权利，能做任何事情所以一般情况下我们都会对用户输入进行过滤，禁止任何js的执行。但有时由不得不嵌入第三方js，如Google Adsense，这时就只能完全信任它，而没有机制来避免它的恶意行为，另外还有一种方法是通过iframe嵌入，但这样又会遇到不少问题，如高度调整等，而且同样不能避免第三方的恶意行为，如使用ActiveX
是否还有其它方法呢? 文整理了facebook、google、microsoft、yahoo对于这个问题的解决方案，希望能给大家带来一些启发
FBML
FBML是facebook让第三方的html、js、css嵌入到facebook页面的技术，目前在sns中很流行，如空间、人人、51等都在使用它
基本原理
下图是facebook页面展现的一个流程，图片来自http://www.ccheever.com/blog/?p=10
首先由facebook向第三方发起请求，第三方服务返回一个FBML的页面给facebook，然后facebook将其转成html放到facebook的页面中，其中FBML是个类似xhtml的标记语言，它允许使用很多html中的标签，并提供了很多facebook特有的标签，方便第三方开发人员
在FBML转成html的过程中会进行很多安全检查，如给script标签中的变量及函数名都加上前缀，如下面这段代码
function $(str) {
return document.getElementById(str)
}
$("hello")
会被转成如下形式，这里假设第三方应用的id为1，所有变量名都会被加上a1_前缀
function a1_$(a1_str) {
return a1_document.getElementById(a1_str)
}
a12_$("hello")
这样做的好处是第三方的js不会影响到页面中其它js，它只能调用自己内部创建的变量及函数，为了让它具备一定的功能， 可以在运行前给它提供一些全局对象，如前面用到了document全局对象，经过转换后变成了a1_document，只要在运行第三方js前先对这个对象进行赋值，第三方的js就能使用了
var a1_document = new fbjs.main('1')
这样，在fbjs.main对象就代替了第三方js中的document对象，在这里就能进行各种检查，保证第三方js不会影响到页面的其它部分，而且做到了白名单机制，第三方只能调用几个特定的api，而不能进行读写cookie等操作，如fbjs_main实现的一个简单示例
function fbjs_main(appid) {}
fbjs_main.prototype.getElementById = function(id) {
return fbjs_dom.get_instance(document.getElementById(id))
}
可以看到，实际上第三方调用document.getElementById返回的是一个内部的对象，而不是实际的dom节点，这样的好处是可以限制第三方程序的运行，缺点是不能直接访问很多dom节点的属性（如tagName），只能通过调用相应的方法来进行读写，有点类似于jQuery
实现方法
FBML的转换库是开源的，感兴趣的同学可以去libfbml看看，它使用了firefox 2.0.0.4源码中的函数来解析html、css、js
除了解析和代码转换，由于js的动态性，使得很多问题不能通过静态分析发现，因此还需要在运行时进行安全检查，运行库是fbjs，它的实现在fbjs.js中
接下来我们就具体研究一下FBML是如何保证安全的
html/css的转换
首先，FBML中标签的id都加上了前缀，如id=”a”的div转成了
<div id="app_1_a"></div>
同时还对html的属性都进行了严格的检查，避免出现如下类型的代码
<a href="javascript:alert()">click</a>
<img src="xxx" onerror="alert()" />
css的转换相对简单些，主要是给selector都加上前缀，将样式都限定到第三方js所属的容器内，如
#app_content_1 .my_class
而对于一些危险的css属性，如expression、behavior、moz-binding都直接滤掉了
为了避免通过position将div移出所属容器，facebook页面中给第三方应用最顶端容器的div加上了overflow:hidden
js的转换
保证js安全主要分为两方面，一是静态分析，如禁止某些函数和变量名加前缀，另一个是进行运行时的检查，如this引用
this引用
this很容易就指到windows上，如在新建对象时少写了个new
function Car() {
this.xx = 'yyy'
}
var car = Car()
alert(xx)
所以需要对this进行重新封装，在运行时对其进行检查，将上面的代码转成
function a1_Car() {
ref(this).xx = 'yyy'
}
var a1_car = a1_Car()
这样就能在运行时对其进行检查，避免它指到window上，ref函数的实现是
function ref(that) {
if (that == window) {
return null
} else if (that.ownerDocument == document) {
fbjs_console.error('ref called with a DOM object!')
return fbjs_dom.get_instance(that)
} else {
return that
}
}
with
with无法进行静态分析，因为它临时插入了一个上下文，需要在运行时才能知道取得的变量是哪个，所以FBML中将其禁止了，后面的很多方案也都禁止with语句
危险的属性
js中的某些属性很危险，如可以通过constructor拿到生成对象的构造函数，如下面的代码可以修改Object函数
var o = {}
o.constructor.prototype.xx = 'xx'
在FBML中将如下几个属性都替换成__unknown__
__proto__
__parent__
caller
watch
constructor
__defineGetter__
__defineSetter__
然而由于js的动态性，还可以使用方括号语法来获得这些属性，如之前的代码可以等价于
var o = {}
o['constr' + 'uctor'].prototype.xx = 'xx'
静态分析是无法发现这类问题的，所以需要类似this那样，对方括号内的属性加上一层运行时的检查
function idx(b) {
return (b instanceof Object || fbjs_blacklist_props[b]) ? '__unknown__' : b
}
不过上述列表其实还是有风险的，后面的caja、ADsafe等都直接禁止后缀带_的属性，避免后续浏览器升级导致的漏洞
arguments
在老版本的Firefox和IE中，arguments对象可以通过caller取到调用当前函数的函数，会带来很多安全隐患，如ajax回调第三方函数时就把ajax库给暴露了，所以FBML给它加了一层封装，转成arg(arguments)，arg函数会将其转成普通数组
function arg(args) {
var new_args = []
for (var i = 0i <args.lengthi++) {
new_args.push(args[i])
}
return new_args
}
eval
因为eval没法进行分析，只能将其禁止，对于需要获取json数据的第三方js，由fbjs提供了Ajax库来转成json对象，不过从代码看这里并没用做相应的安全检查，会造成安全隐患
为了保证eval第三方json时的安全，可以采用json2.js的做法，在eval前检查是否是合法的json
if (!/^[/],:{}/s]*$/.test(data.replace(///(?:["////bfnrt]|u[0-9a-fA-F]{4})/g, "@")
.replace(/"[^"///n/r]*"|true|false|null|-?/d+(?:/./d*)?(?:[eE][+/-]?/d+)?/g, "]")
.replace(/(?:^|:|,)(?:/s*/[)+/g, "")) ) {
return null
}
去掉注释
去掉注释似乎是为了减少大小，然而由于IE的条件编译机制，导致注释里还能执行任意JS，所以注释必须去掉，如
/*@cc_on @*/ /*@if (1) alert(document.cookie) @end @*/
另一种就是Firefox对--的错误解析也会导致安全问题
array中的很多方法
在某些浏览器下，array中的很多方法通过call和apply调用时会返回window对象，如下写法在Firefox、Chrome等浏览器中会取到window对象
alert(window === ([]).sort.call())
所以在fbjs中对这些方法都进行了重写，避免它在运行时的this指向window
Array.prototype.sort = (function(sort) { return function(callback) {
return (this == window) ? null : (callback ? sort.call(this，function(a,b) {
return callback(a,b)}) : sort.call(this))
}})(Array.prototype.sort)
甚至还将reduce、reduceRight直接删掉了
Array.prototype.reduce = null
Array.prototype.reduceRight = null
dom
为了让第三方js能对页面元素进行控制，fbjs封装了dom的很多方法，并对其进行运行时的检查
getElementById
因为id都加上前缀了，所以fbjs提供给第三方js的api需要加上前缀才能取到
fbjs_main.prototype.getElementById = function(id) {
var appid = fbjs_private.get(this).appid
return fbjs_dom.get_instance(document.getElementById('app'+appid+'_'+id)，appid)
}
getParentNode
为了不让第三方js影响到页面的其它部分，需要在dom节点移动时进行检查，如获取parentNode，要将其限定到第三方应用所属的容器里，不能取高于这个节点的其它元素
createElement、innerHTML
fbjs提供了createElement接口来让第三方js创建元素，并进行检查，只允许创建一些安全的元素
而对于很多开发人员喜欢使用的innerHTML则不容易进行安全检查，因为需要在运行时对html进行解析，fbjs目前只提供两种方式，一种是setInnerFBML，通过FBML中的一个自定义标签<fb:js-string>，让FBML来解析，它的缺点是无法在运行时拼装，另一种是setInnerXHTML，它要求传递的字符串是一个合法的xml形式，直接使用浏览器的XML解析器来解析
location、src、href
有一种风险是可以动态创建一个a标签，设置它的href来生成<a href=”javascript:alert()”>x</a>，所以这些url的属性都需要加上一层判断
fbjs_dom.href_regex = /^(?:https?|mailto|ftp|aim|irc|itms|gopher|//|#)/
fbjs_dom.prototype.setHref = function(href) {
href = fbjs_sandbox.safe_string(href)
if (fbjs_dom.href_regex.test(href)) {
fbjs_dom.get_obj(this).href = href
return this
} else {
fbjs_console.error(href+' is not a valid hyperlink')
}
}
除此之外还有img的src和location.href
setTimeout、setInterval
setTimeout、setInterval是可以传递字符串来执行的，和eval一样没法进行静态分析，如
var a = 'ale'
var b = 'rt()'
setTimeout(a+b, 10)
于是fbjs对这两个函数都进行了封装，限制其只允许传递函数类型
fbjs_sandbox.set_timeout = function(js, timeout) {
if (typeof js != 'function') {
fbjs_console.error('setTimeout may not be used with a string. Please enclose your event in an anonymous function.')
} else {
return setTimeout(js, timeout)
}
}
js代码的执行
fbml解析后的js并不直接放回<script>标签中，而是将它取出，在fbjs中通过eval_global来执行
function eval_global(js) {
var obj = document.createElement('script')
obj.type = 'text/javascript'
try {
obj.innerHTML = js
} catch(e) {
obj.text = js
}
document.body.appendChild(obj)
}
为何要这么做呢? 我能想到的一个原因是js字符中script标签会导致漏洞，不好进行静态分析，如下面的代码会在IE、Chrome下执行alert
<script>
var a = "</script><script>alert()</script>"
</script>
不过因为FBML使用了firefox的引擎来解析html，所以直接在字符串中第一个</script>标签就截断了
隐蔽的问题
了解fbml的解决方案后，感觉挺似乎很完美，然而实际上远没有那么简单，Facebook script injection vulnerabilities上报了很多Facebook的漏洞，如Firefox中支持的E4X语法，因为Facebook是基于firefox2的解析引擎，所以导致解析时没有发现问题
<script>
<x x="
x" {alert('any javascript')}="x"
/>
</script>
在fbjs中有大量这样case by case的漏洞修复，涉及到浏览器特性的问题是无法预测的，尤其是浏览器解析时对html的容错机制（这也是html5重点解决的一个问题，感兴趣的同学可以看看其中的第8章），不过总的来说fbml的解决方案还是很不错的，也经受了大量的线上考验
Microsoft Web Sandbox
Microsoft Web Sandbox是微软提出的一种方案，它最大的特点就是引入了虚拟机的思想，将代码全部转成了虚拟机中的调用，将很多安全检查的工作放到运行时去解决， 在这个虚拟机中将所有html标签，以及所有的js对象和dom的调用都进行了封装，将第三方代码完全和外部环境隔离开
在浏览器端，安全控件跟 JS 加密的密码我认为还是有很大区别的。但我觉得安全控件，它自身的安全性和自我保护能力都比JS强多了。
（一）对安全控件的认识： 1.由于安全控件的保护，客户的帐号及密码还是相对安全的。安全控件实质是一种小程序。由各网站依据需要自行编写，当该网站的注册会员登录该网站时，安全控件发挥作用，然后通过对关键数据进行SSL加密，防止账号密码被木马程序或病毒窃取，可以有效防止木马截取键盘记录。安全控件工作时，从客户的登录一直到注销，实时做到对网站及客户终端数据流的监控。安全控件是很多网银使用前必须安装的小程序。安全控件安装可以减少账户的不必要丢失和操作方面的失误。所以网站，大多都会使用安全控件对客户的帐号密码等信息加以保护，对优化网络环境起着至关重要的作用。
2.在选择控件方面需注意事项：一、确定所用的网站或是平台是否必须使用此控件；
二、检查控件的发行商；
三、安装控件时最好让一些杀毒或是一些保护电脑安全的软件处于开启状态，发现异常马上处理；
四、安全控件最好是从官方网站下载。
（二）对常用的 JS 加密（RSA）的认识：1. JS 加密（RSA）步骤：
服务端生成公钥私钥，下发公钥给客户端 客户端使用公钥（还有盐）对密码加密 把加密后的密码发送到服务端，服务端使用私钥解密拿到密码 对于攻击者来说，只要能够拿到 HTTP 明文，就可以在公钥下发时进行公钥或者加密方式的替换，拿到密码后解密，再使用服务器公钥加密密码明文，返回给服务端。
2.加密注意事项：
通常情况下，在提交注册表单时，最好对密码之类的敏感字段进行加密，保证内容的安全。
（三）两者区别：1.如果从安全角度上来看，js加密也好，安全控件也好，都是可被逆向破解的，其两者的唯一区别，可能就是破解安全会更复杂麻烦点，但是因为每个客户端它的安全控件程序都是一样的，所以在算法上是可以通过分析破解得到的。
2.如果考虑到安装时被攻击的情况，控件是要相对安全些，因为你不用每次都要传输安装控件，而js代码在传输过程中是存在被更改的的可能性的。
总之，从安全角度，js也好，控件也好，都是可以被逆向分析的，控件要相对安全些，因为你不需要每次传输安装控件，但是js代码在传输过程中存在被篡改的可能性。因为每个客户端控件程序是一样的，所以其实算法也是可以分析得到的如果考虑到中间人攻击的情况，安全控件比较安全。
