来源：自学PHP网 时间：2015-04-17 11:59 作者： 阅读:次
[导读] 今年来根据乌云站点的资料，XSS漏洞在WEB前端的比额已经非常明显，而CSRF的危害又有多少人关心呢？最近也在看XSS的相关资料，但是看到CSRF的时候还是忍不住好好的看了一下有关资料，...
|
今年来根据乌云站点的资料，XSS漏洞在WEB前端的比额已经非常明显，而CSRF的危害又有多少人关心呢？
最近也在看XSS的相关资料，但是看到CSRF的时候还是忍不住好好的看了一下有关资料，发现CSRF其实一样很有影响力。我要写的就是一点读后感 别的没什么哈 轻喷吧.. CSRF全称为：Cross Site Request Forgery 英语没过四级的也应该能看懂点吧 就是跨站请求伪造。对了，这里说一下，CSRF也有XSRF这样的格式，所以认清他们哦。 其实他和XSS有本质上的区别，我以前总把他们两个搞混淆，所以有的时候学习XSS和CSRF经常会把知识点搞乱，其实这是没有从根本上理解他们的原因。 XSS和CSRF的区别： XSS是跨站脚本，而他最主要的还是脚本两个字，“跨”是浏览器的特性，而脚本才是XSS能够造成危害的核心。 CSRF：是跨站请求伪造，很明显根据刚刚的解释，他的核心也就是请求伪造，通过伪造身份提交POST和GET请求来进行跨域的攻击。 这样说应该能够很好的区分了吧。 还是继续我们的CSRF吧。 当时看书的时候就在想，他是怎么跨站伪造身份进行请求的并且浏览器居然还会认为是正常的请求呢？ 这里必须补充一个姿势： 同源策略的限制：是指浏览器会阻止从一个域上加载的脚本获取或操作另一个域上的文档属性。也就是说，受到请求的 URL 的域必须与当前 Web 页面的域相同。这意味着浏览器会主动隔离来自不同源的内容，以防止它们之间的操作。这个浏览器策略很旧，从 Netscape Navigator 2.0 版本开始就存在。 XSS发起的攻击是在存在漏洞网站的同域内进行的，所以不受同源策略的限制，但是CSRF是跨站点请求，怎么实现呢？ 还记的同源策略限制的是什么么？ 嗯 加载脚本。而我们的CSRF最大的特点恰恰就是不用加载脚本，所以他不受同源策略的限制。但是，必须保证，在跨站点发出请求时，我们的身份是被认证后的，也就是我们的COOKIES是合法的。 而且客户端HTML标签发出的跨域GET请求会被认为是合法的，类似一些网页游戏都会用到。 给大家看下我自己根据攻击原理做的图 比较粗糙 凑活看哈
然后我们看下我伪造的一个发出请求的数据： 这个是跨站请求的数据（CSRF的请求）: GET http://www.2cto.com /addJB.php?id=FK_lccl&JB=1000 HTTP/1.0 Referer: http://www.FK_lccl.com/CSRF.htm Accept-Language: zh-cn Proxy-Connection: Keep-Alive User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Host: www.f4ck.net Cookie: ASPSESSIONIDCCAQTQQC=EAIFAJCBOGOJDICNLKDNONAM; Hm_lvt_ab4fa68eb3486ebca7af6089cef2b711=1360203586; Hm_lpvt_ab4fa68eb3486ebca7af6089cef2b711=1360203598
这个是目标网站自己发出的请求：目的是给我加1000JB 哈哈 GET http://www.2cto.com /addJB.php?id=FK_lccl&JB=1000 HTTP/1.0 Referer: http://www.2cto.com /addJB.php?id=FK_lccl&JB=1000 Accept-Language: zh-cn Proxy-Connection: Keep-Alive User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Host: www.f4ck.net Cookie:ASPSESSIONIDCCAQTQQC=EAIFAJCBOGOJDICNLKDNONAM; Hm_lvt_ab4fa68eb3486ebca7af6089cef2b711=1360203586; Hm_lpvt_ab4fa68eb3486ebca7af6089cef2b711=1360203598 这个是正常情况下发出的请求，可以看到除了Referer的请求来源不同外，其他的都一样。 重点是COOKIES必须一样。因为这个是目标网站认证身份的标识。上面说到只有身份认证后，CSRF攻击才能得以施展。 书上这里补充了一个关键的姿势： COOKIES分本地COOKIES和内存COOKIES两种，这两类在CSRF中存在一些差异。IE浏览器默认不允许目标网站A的本地COOKIE在这样的跨域请求中带上，除非在HTTP响应头中设置了P3P，这个响应头允许我们的网站带着本地COOKIES发出请求，所以这才是关键。同样的POST表单我们也可以伪造请求，从而达到我们的目的。 简单的说，完成CSRF需要两个步骤： 1.登陆受信任的网站A，在本地生成COOKIE 2.在不登出A的情况下，或者本地COOKIE没有过期的情况下，访问危险网站B。
下面看下能够利用CSRF的几个要点： 1.网站违反了HTTP规范，使用GET请求更新资源。 2.如果网站的过滤方式用这个$_REQUEST 变量，$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题 3.$_POST用这个变量只获取POST请求的数据。我们可以隐藏一个POST进行突破 <body onload=”steal()”> <iframe name=”steal” display=”none”> <form method=”POST” name=”transfer” action=”http://www.f4ck.net/addJB.php”> <input type=”hidden” name=”id” value=”FK_lccl”> <input type=”hidden” name=”JB” value=”1000″> 理解上面的3种攻击模式，其实可以看出，CSRF攻击时源于WEB的隐式身份验证机制，web的身份验证机制虽然可以保证一个请求来自于某个用户的浏览器，但却不无法保证该用户的请求是用户批准发送的。 从而产生CSRF的利用。 在网上看资料的时候看到了一篇利用CSRF破解WPA密码，给大家看下吧： 他利用的是一般路由器在内网中缺少身份验证通过认证绕过漏洞或者默认登录，攻击者可以修改路由器的任何设置。 |
自学PHP网专注网站建设学习,PHP程序学习,平面设计学习，以及操作系统学习
京ICP备14009008号-1@版权所有www.zixuephp.com
网站声明：本站所有视频，教程都由网友上传，站长收集和分享给大家学习使用，如由牵扯版权问题请联系站长邮箱904561283@qq.com
