客户端脚本安全

参考文献：白帽子讲Web安全 （亚马逊购买地址：链接）

前言

浏览器作为客户端，也是我们用户上网的直接入口，所以浏览器的安全就是用户安全的第一道屏障。

同源策略

同源策略是浏览器最核心最基本的安全功能。它限制了来自不同源的“document”或脚本，对当前“document”读取或者设置某些属性。所谓同源是指host（域名或者ip地址）、子域名、端口和协议相同。不同源的客户端脚本(javascript、ActionScript)在没明确授权的情况下，不能读写对方的资源。
但需要注意的是，对于当前页面来说，页面存放js文件的域并不重要，重要的是加载js的页面所在域是什么。例如：在a.com的页面下通过获取了b.com域中的资源，但是由于b.js是运行在a.com的页面中，因此对于当前页面来讲，b.js的域就是a.com。
在浏览器中，，再次提交搜索之后就会发现我们提交的内容被浏览器执行了。即用户输入的script脚本被写入到页面中。这个栗子里面用户写入的内容因为只有当前用户看到，所以不会有特别大的危害，那么如果是这个用户写入的内容可以被其他用户看到的场景，当写入一些恶意代码的话危害就很大了。
栗子2:黑客写了一篇包含有恶意js代码的博客文章，文章发表之后，所有访问该博客的用户都会在他们的浏览器中执行这段恶意代码。黑客这里把恶意脚本保存到服务器端，所以这种xss攻击就叫做存储型xss。
－－－－－栗子结束－－－－－

跨站请求伪造（CSRF）

csrf（cross site request forgery），是指黑客伪造成合法用户发起请求而造成的一种攻击。

－－－－－举一个栗子－－－－－
某博客网站，用户小白在登陆自己的账号后可以管理自己的文章，其中有个操作是删除某篇文章。删除的操作是请求url：http://blog.balabala.com/manager/entry.do?m=delete&id=12345 其中12345是这篇文章的id号。接下来我们就用这个url存在的csrf漏洞来删除这篇文章。
攻击者首先在自己的域内构造一个页面，http://www.a.com/csrf.html，内容为：
,然后攻击者诱使目标用户也就是小白同学访问这个页面，他看到一张无法显示的图片，但是在这这图片的背后是csrf攻击的巨大阴谋。
－－－－－栗子吃完了－－－－－

CSRF防御

面对csrf攻击，用户真的是防不胜防，那么作为网站建设者有什么方法可以防御这种攻击呢呢。下面列几种比较常用的方法。

1. 验证码
   验证码被认为是对抗csrf攻击最简洁有效的防御方法。csrf攻击往往是在用户不知情的情况下构造了网络请求，而验证码则是强制用户与应用进行交互来完成最终的请求。但是出于对用户体验的考虑，网站不会在所有的操作上都加上验证码，所以这只能作为一种辅助手段，而不是最终的解决方案。

2. referer check
   referer是http请求header中的一个参数，允许客户端指定请求url的源资源地址。所以referer check可以用于检查请求是否来自合法的“源”。常见的互联网应用，页面与页面之间都具有一定的逻辑关系，这使得每个正常清请求的referer都具有一定的规律。举个栗子，比如进行发表博客的操作，在提交发表博客的表单时，referer的值必然是编辑博客所载的页面，如果不是这个页面甚至不是这个网站的域那么极有可能是csrf攻击。这种防御手段的缺陷在于，服务器不是任何时候都能取得referer，所以这只能作为一种监控手段而无法作为主要的防御手段。

3. Anti CSRF Token
   现在业界针对csrf防御的一致做法是使用token。csrf能够成功的本质原因是攻击者可以猜出请求中的所有参数和参数值，所以才能成功地构造一个伪造的请求。所以直观的解决方案是：把参数加密，或者使用一些随机数从而让攻击者无法猜测到参数值，目前业界通用的方案就是使用AntiCSRFToken。那么针对我们开头所说的那个栗子?，保持原有参数不变，新增一个参数token，这个token的值是随机的，不可预测：http://blog.balabala.com/manager/entry.do?m=delete&id=12345&token=[random(seed)] 。在实际应用中，token同时放在表单和session（或者cookie）中，在提交请求的时候服务器只需要验证表单中的token和用户session（或者cookie）中的token是否一致从而判断这个请求是否合法。