从零开始学web安全（4）

本文作者：IMWeb 刘志龙 原文出处：IMWeb社区 未经同意，禁止转载

忙忙忙，最近事情实在有点多，赶在月底写一下系列4。

前面3个文章简单介绍了xss，后面还会继续对xss进行研究。无奈最近啥都没研究，只好先一个csrf的入门文章过渡一下。

这篇是csrf入门篇，内容比较简单，知道csrf的同学可以直接关掉页面了。

CSRF 是什么

CSRF（Cross Site Request Forgery, 跨站域请求伪造）是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一。

CSRF 能干啥

攻击者盗用了你的身份，在你不知情的情况下以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，购买商品，虚拟货币转账，删你文章，微博等等。

CSRF 原理

看完上面介绍，我自己是没有任何收获。。还是先看个图吧。借用cnblogs某大大一个图

看看上面这个流程，经常是我们平时浏览网站经常会走的流程。简单说来，首先我们在A网站登陆了，假设A网站有csrf漏洞，然后我们不小心浏览到某个恶意网站B，然后我们就被入侵了55555。。。

上面这个流程，估计大家有可能有疑惑的应该只是步骤5或者步骤6。就是说在恶意网站B里面写一段代码，发送一个到A网站域下的请求，一样是会带上A域下的cookie。这个是浏览器的策略。这时候可能有同学冒出跨域之类的一些疑问，后面继续这个。

上DEMO － 危险的get

看完原理，估计本来不了解的同学还是没有搞懂，直接看demo。

假设我们imweb博客有个删除文章的请求有csrf的漏洞。请求http://imweb.io/cgi-bin/del?id=1是删除id为1的文章，还是个get请求。

这时候我刚好有篇文章id=123的，有个小伙伴觉得我这个文章写的很烂，决定偷偷删掉它，问题是这个小伙伴没有我的密码，也没有管理员权限，怎么办？

这个小伙伴敏锐的发现这个删除文章的cgi是get请求，而且居然还有csrf漏洞。。于是这个小伙伴想到办法了。写到这里我特地去试了试在imweb评论里评论一个富文本，<img src="http://test.com">, 居然完整的出来了。。。这里实在有点危险。。这个小伙伴也机智的发现了这一点，于是他在我的文章下面评论了一条<img src="http://imweb.io/cgi-bin/del?id=123"的评论，然后就等着我上钩了。

然后我收到邮件（imweb博客评论的通知机制）看到有人评论，我就点进去看啦。看了下发现是张挂了的图片，就没在意了。下次我再登博客，尼玛发现我之前辛辛苦苦写的id是123的那篇文章呢，莫名其妙就不见啦。。

看到这里大部分同学应该都知道我文章为什么不见了，原因就在于我登陆了，访问了我这篇文章，然后页面开始加载，顺便加载了那个小伙伴的评论，顺便把http://imweb.io/cgi-bin/del?id=123请求也发了，服务器收到请求，发现还带了我的cookie，于是傻傻的认为是我要删这篇文章，就把它删了。。

整个流程非常的简单，这个小伙伴基本没费事，不过就评论了一下而已，就把我这篇坑爹的文章删了。可见get是多么的危险，轻松杀人于无形之中。

imweb的管理员听到还有这回事，决定赶紧修补下，删除这么危险的操作还是别随便用get了，还是改成post好了。

post 是王道？

某天我又发了一篇文章，id是233，这个小伙伴又看得很不爽，觉得尼玛这种文章也能发表。于是又像上面一样评论了一个图片，然后他发现，get接口好像已经不行了啊，文章删不掉。怎么办？

这当然难不倒这个机智的小伙伴，他立马就想到了一个很简单的方法。类似这样的代码，不是一样可以在不知情的情况下轻松post吗？

<form action="http://imweb.io/cgi-bin/del" method="post">
<input type="text" name="id" value="233" />
</form>
<script> document.forms[0].submit(); </script>

好的，代码写好了，这个小伙伴决定开始入侵了，他把上面这段代码跟之前一样写到我的这个文章的评论里。发现糟糕了，不行，富文本评论哪有那么傻，让你随便插入form表单还搞了个script。这招不行，小伙伴决定换个方法，他自己写了个页面叫http://csrf.test/,然后里面就是上面的代码，然后他诱导我说这个网址有好多美女图片。。我赶紧点进去看看，刚好这时imweb的登陆态还没失效。然后进去这个网址我发现我去什么都没有啊，被骗了，没有美女啊。却不知道我的文章又被这个小伙伴偷偷删掉了。

这个原理和上面那个get没有太多区别，就是搞了个自动提交的表单。这时候有同学可能有疑问，在http://csrf.test下发imweb.io域下的请求，这不是跨域了吗，怎么还成功了？

有这个疑问的同学注意这里是表单的post，并不是ajax发的请求。表单是可以随便post的，并不受域的限制。写到这里的时候我有点疑惑了，ajax有同源策略，表单为啥不约束？

感兴趣的同学可以深入去探讨一下上面这个问题，也欢迎评论帮我解惑。因为表单post不受同源的限制，倒是给我们提供了不少跨域方案。

好吧回到正题，整个流程下来，这个小伙伴又成功删了我的文章。但是大家应该发现了，整个入侵的门槛高了很多。所以说，post不是王道，但在这里比get毫无疑问要更安全。

防范

说了那么多，我写一篇文章被删一篇，难道我以后就不能写文章啦？

管理员这时候怒了，决定亮出自己三张王牌。

－ referrer校验 － 验证码 － token

王牌一，referrer校验，非常简单，基本就验证一下请求referrer，合法的才给予操作。

比如下面那个post的demo，发现请求来自http://csrf.test，认为是非法操作，于是我的文章就没有被删了。

但是那个get的demo，似乎防范不了？理论上referrer校验也是可以防范get的，只是这个demo有点特殊，不仅这个删除接口有csrf漏洞，还可以轻松评论任何src的图片。

造成了referrer居然是来自imweb.io。这也是我上面说这个图片评论很危险的原因之一。甚至帮助绕过了referrer校验。

在项目中这个王牌还是很少被用的，原因是因为referrer的不稳定，服务端不能保证每次都可以取到referrer（比如https跳http，还有很多办法可以模拟空referrer)。

王牌二，验证码，这个就牛逼了，防御的滴水不漏。可惜万事有利必有其弊，你总不能发每个请求都让用户敲一次验证码吧，所以这种一般只在某些特定场景用。

王牌三，token。这个应该是现在比较通用的方案。当然token具体的生成方案就一堆了，这里举个简单的例子。

比如拿用户登录态的cookie做个编码，作为token。每次发请求时带上这个token。这个方案之所以可以原因在于，比如刚刚那个小伙伴post入侵我的，在http://csrf.test域是不能读imweb.io域下的cookie的，所以就算我告诉他编码方案，他因为读不了cookie的数据也不能入侵成功。写到这里我突然想到了一种有可能入侵imweb的csrf方案。。估计不少同学也想到而且在尝试了。可行性待验证，下篇文章说说测试结果。。

有点晚了，睡觉zzzz