csrf从小白到入门(简单易懂,有逻辑)

<1>简介

csrf(cross-site-request-forgery)俗称跨站请求伪造,这种漏洞是服务端对用户审核不严格导致的。简单来说就是伪造一个用户的身份做一些违法乱纪的事情。举例说明,假如有一个人叫A,A打开了一个网站,这个网站在A打开并且登录之后返回了一个cookie,如果我这时发了一个钓鱼邮件给A,邮件中有我提前写好的html文件,A打开邮件附录的
html文件之后会直接访问他刚刚打开的网站,这时计算机会直接将刚刚的cookie发给服务器,这样就实现了冒用他的身份。有的人可能会问,这样做了之后有什么危害?有危害是肯定的,要是我冒用A的身份打开的是一个银行的网页,且这个网页有转账的功能我要是直接用脚本完成转账的动作,那么这就算是完成了一次攻击,且对A也好还是银行也好都是不好的,足以看出csrf的危害。

<2>csrf分类及实例

众所周知,在HTTP协议中规定了8种传递数据的方式,所以理论上csrf应该有八种类型,不过对于现实来说服务器上的网站一般用post和get两种方式来传递参数,所以我接下来将要用pikachu上面的几种方法来举例csrf和csrf的防御方法还有csrf跨域请求的方法。

(1)get传参的csrf

所谓get传参的csrf就是服务器接收数据是用get的方式,打开pikachu,登录一个用户的账号,比如用用户名为vince密码是123456的账户
csrf从小白到入门(简单易懂,有逻辑)_第1张图片csrf从小白到入门(简单易懂,有逻辑)_第2张图片
登录上去之后理论上前端就已经收到了后端传过来的cookie那么我们只差伪造一个url就能开始骗用户点击之后修改他的信息了
打开开发者工具查看网络种的记录可以发现传来了cookie
csrf从小白到入门(简单易懂,有逻辑)_第3张图片
我们伪造一个“诱人”的url骗他们点击之后就可以实现发送cookie冒用身份了。首先我们要确定修改用户页面传的get参数。
转到用户修改数据页面之后就可以根据源码看get传的参数了
csrf从小白到入门(简单易懂,有逻辑)_第4张图片如上图我们可以发现传的参数是如上几个,我们构造一下url,把vince用户的个人信息改成好玩的参数
原本从修改页面传回的url如下

127.0.0.1/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=lal&phonenum=123456&add=lilian&email=dumb&submit=submit

经过修改成了这样子

<a href="http://127.0.0.1/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=你必狂吃不胖&phonenum=你必越长越好看&add=你必天天捡钱&email=你必好运连连&submit=submit"<美女荷官,在线发牌,百万影片你想要的这里都有

那么在一个能解析html标签的环境下你就会发现它变成了如下的标签
csrf从小白到入门(简单易懂,有逻辑)_第5张图片要是被你骗的人真的点击之后会是这样子

csrf从小白到入门(简单易懂,有逻辑)_第6张图片现在你成果完成了一次csrf

(2)post传参的csrf

有些网站并不是get传参而是post传参那么此时我们怎么实现csrf呢?我会用钓鱼邮件中附加一个html的方式,有可能也会用恶意服务器的方式,也可以用xss+csrf组合拳的方式传递参数。我在这里就介绍一下伪恶意服务器的方法。之所以说他是伪恶意服务器是因为我不可能真的做一个服务器,我是将sql-labs的靶场源文件改了改成了一个在集成环境中的伪恶意网站。基于上文的原理,我们可以想到csrf的基本套路,但是我们也发现刚刚的传参方式在post类型中并不适用所以我们要用以上三种方法用post方式传递数据。
首先要写一个搭建在集成环境上的网站,我就直接用了sql-labs靶场第十一关,原本第十一关的代码如下

csrf从小白到入门(简单易懂,有逻辑)_第7张图片

更改之后第十一关的代码改成了如下样子
csrf从小白到入门(简单易懂,有逻辑)_第8张图片此时在一个新的窗口中访问sql-labs靶场第十一关,会是如下

csrf从小白到入门(简单易懂,有逻辑)_第9张图片
原本vince的信息是如下图

csrf从小白到入门(简单易懂,有逻辑)_第10张图片
再点击sql-labs的submit按钮之后就能实现csrf,实现之后vince信息被改成了如下样子

csrf从小白到入门(简单易懂,有逻辑)_第11张图片

(3)加入token的csrf

在服务器传回的数据中加入名为token的变量,那么就能有效防范csrf。但是可以肯定的是世上没有绝对的东西,token虽然能有效防御csrf,但是做不到完全。csrf的重点是冒用正常用户的身份,用他的身份做一些事情。用之前讲的老套路套路加入token的csrf明显是行不通的,因为你自己写的网页也好、url也好是不能用javascript等语言写的脚本调取另一个窗口的数据的。他们循序了同源策略。下面首先介绍一下同源策略之后再说绕过实例。

  • token简单来说就是服务器随机生成的一个字符串,在一个请求到达服务器的时候,服务器会首先查看请求中是否有合法的token,有的话才会正常处理。

<3>同源策略

同源策略是指同源的脚本才能互相调用dom树、cookie、token的情况。下面是判断两个脚本同源的条件。

1.协议:比如用http协议的网站文件不能调用用https协议的网站文件。
2.域名:比如一个域名是forming.com那么与handsome.com就不遵守同源协议。值得一提的是一级域名与二级域名之间也是不遵守同源策略的,比如forming.com和handsome.forming.com之间也不遵守同源策略。
3.端口:就是字面意思的端口也没有什么好解释的。

同源策略是一种安全策略,为的就是保护用户的隐私,但是本着“既然存在就一定有漏洞”的原则,同源策略也是有办法绕过的。

<4>加入token后实现csrf

直接用之前提的两种方法因为同源策略的原因是不行的。基于此一般要用xss+csrf组合拳的方式再结合上跨域的方法将数据传递出去实现绕过,首先需要本页面具有xss漏洞(对xss了解不多的童鞋可以看看这篇文章xss(cross site script)注入点、注入语句及危害知识总结)实现javascript脚本的注入,之后调取必要信息和token实现csrf。

  • 举例:假如www.first.com的a.html存在xss漏洞,注入一个iframe框架,框架的网页指向是之前的恶意网站www.second.com的b.html,其中iframe的src属性中要包含hash记录(就是#后面要有东西),其中的hash值是a.html的cookie和token,这样实现了数据的跨域传递。然后b.html中有根据hash记录接受cookie和token实现csrf。这种方法根据下文跨域方法中的location.hash的跨域思路,不过不完全相同。

<5>跨域的方法(克服同源策略的方法)

(1)可以跨域的HTML标签

1.标签
通过src属性

2.

3.

4.标签
通过src属性

5.

你可能感兴趣的:(csrf,web,安全漏洞)