客户端脚本安全

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

前言

浏览器做为客户端，也是咱们用户上网的直接入口，因此浏览器的安全就是用户安全的第一道屏障。

同源策略

同源策略是浏览器最核心最基本的安全功能。它限制了来自不一样源的“document”或脚本，对当前“document”读取或者设置某些属性。所谓同源是指host（域名或者ip地址）、子域名、端口和协议相同。不一样源的客户端脚本(javascript、ActionScript)在没明确受权的状况下，不能读写对方的资源。
但须要注意的是，对于当前页面来讲，页面存放js文件的域并不重要，重要的是加载js的页面所在域是什么。例如：在a.com的页面下经过<script src='http://b.com/b.js'></script>获取了b.com域中的资源，可是因为b.js是运行在a.com的页面中，所以对于当前页面来说，b.js的域就是a.com。
在浏览器中，<script>、<img>、<iframe>、<link>等标签均可以跨域加载资源，而不受同源策略的限制，这些带src属性的标签每次加载时，实际上时由浏览器发起了一次get请求，经过src属性加载的资源，浏览器限制了javascript的权限，使其不能读、写返回的内容。因为这个漏洞可以跨域读取页面内容，所以绕过了同源策略，成为一个跨域漏洞。

跨站脚本攻击（XSS）

xss（cross site script），是指经过“html注入”篡改了网页，插入了恶意脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击
xss根据不一样效果分为如下几种类型：

• 反射型xss（非持久型xss）：简单地把用户输入的数据“反射”给浏览器，也就是说，黑客须要诱使用户点击一个恶意连接才能攻击成功。

• 存储型xss（持久型xss）：存储型xss会把用户输入数据“存储”在服务器端，因此这类攻击具备很强的稳定性。

• 基于DOM的xss：这类xss效果上是反射型xss，可是造成缘由是经过修改页面的DOM节点来达到攻击目的的。

－－－－－针对上面所说的三种类型举两个栗子来直观理解一下。－－－－－
栗子1:一个页面直接把用户输入的参数输出到页面上，例如咱们在网站搜索一本名字叫《白帽子讲web安全》的书，若是没有搜到这本书，那么网站会提示：没有找到白帽子讲web安全这本书，查看页面源代码，能够看到：<div>没有找到白帽子讲web安全这本书</div>，那么此时若是搜索的内容变为<script>alert(/xss)</script>，再次提交搜索以后就会发现咱们提交的内容被浏览器执行了。即用户输入的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，内容为：
<img src="http://blog.balabala.com/manager/entry.do?m=delete&id=12345" />,而后攻击者诱使目标用户也就是小白同窗访问这个页面，他看到一张没法显示的图片，可是在这这图片的背后是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是否一致从而判断这个请求是否合法。