Web基础渗透与防护（第2版）课件 项目十 CSRF攻击与防御

项目十CSRF攻击与防御第10章CSRF攻击与防御10.1项目描述 10.2项目分析 10.3项目小结 10.4项目训练 10.5实训任务 项目10XSS攻击与防御

CSRF攻击是一种十分危险的Web安全攻击，利用的是网站对用户浏览器的信任，通常攻击者会通过电子邮件、聊天工具或者论坛来发送链接，甚至在不点击链接的情况下自动发出HTTP请求来实施攻击。目前，大多数的Web应用都存在应用推广或第三方调用，这就给CSRF攻击的发生提供了可能。因此掌握CSRF攻击原理、熟悉常用的CSRF攻击方法和工具，了解常见的CSRF攻击安全防护手段，对于网络安全管理运维人员来说是十分必要的。10.1项目描述在上面的项目描述中我们知道，CSRF漏洞允许攻击者利用合法用户的名义，跨站点发送恶意请求，完成攻击者所期望的操作。主要是因为在浏览器的Cookie中保存了用户的登录认证信息，使得攻击者可以利用此信息冒充合法用户，提交伪造请求，实施CSRF攻击。与XSS攻击相比，CSRF攻击往往难以防范，所以被认为比XSS更具危险性。目前主要的防御方法包括基于Referer和基于Token技术两种。针对上述情况，本项目的任务布置如表10-1所示。10.2项目分析表10-1项目任务布置1、认识CSRF攻击（1）CSRF攻击概念CSRF全称Cross-SiteRequestForgery，译为跨站点请求伪造。它是指攻击者盗用合法用户身份，以合法用户的名义发送恶意请求，完成攻击者所期望的操作，例如方邮件、购物转账、隐私获取等。其核心在于诱合法用户，使用合法身份与特权对服务器实施攻击。CSRF与XSS的区别在于，CSRF不需要提交恶意脚本到Web服务器。（2）CSRF攻击原理CSRF攻击的关键点有两个：一是跨站请求；二是请求伪造。跨站请求即该请求不是来自于本站点（当然也可以是本站点发起的请求）。比如目标Web站点上有修改用户密码的功能，但发起修改用户密码请求的是来自于其他网站的客户端（如AJAX、Flash等），这个请求就是一个跨站请求。请求伪造即该请求不是合法用户期望发出的，而是他人伪造的。项目相关知识点现有一Web站点A，网址为，A网站上有一个删除功能，当合法用户user需要删除的时候，通过点击按钮或链接，就会向A站点的服务器提交一个删除请求，URL为/something/delete?id=1来删除id为1的信息。若网站A存在CSRF漏洞，现有一攻击者attacker利用此漏洞对Web站点A发起CSRF攻击。攻击者自己建立一个恶意Web站点B，网址为。攻击者又在B站点上编写一个攻击页面，URL为/attack.html，页面中包含一个img标签，<imgsrc=”/something/delete?id=1”>。此时加入合法用户user已经登录了Web站点A，而用户user受到攻击者attacker的诱骗访问了恶意站点B的/attack.html页面，此时伪造的请求/something/delete?id=1通过恶意站点B发起。由于合法用户user之前已经登录，故服务器认为恶意站点B发起的请求是用户user发起的，从而执行了删除操作。但实际上，删除操作并不是用户期望做到。而是由攻击者attacker伪造的。这样CSRF攻击就实施成功了。从上面的攻击场景可以看出CSRF攻击的特点是：跨站发出请求，无恶意脚本（如JavaScript）的参与，攻击是在合法用户身份认证通过后发出。2、HTTP请求与响应超文本传输协议（HTTP，HyperTextTransferProtocol）是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。HTTP是一个客户端和服务器端请求和应答的标准，对于Web应用来说，客户端是浏览器，服务器端是网站。通过使用Web浏览器或者其它的工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。一旦收到请求，服务器向客户端发回一个状态行，比如"HTTP/1.1200OK"，和响应的消息，消息的消息体可能是请求的文件、错误消息、或者其它一些信息。在客户机和服务器之间进行请求-响应时，两种最常被用到的方法是：GET和POST。GET-从指定的资源请求数据。POST-向指定的资源提交要被处理的数据HTTP的请求格式如下：<method><request-URL><version><headers><entity-body>在HTTP请求中，第一行必须是一个请求行，包括请求方法，请求URL，报文所用HTTP版本信息。紧接着是一个herders小节，可以有零个或一个首部，用来说明服务器要使用的附加信息。在首部之后就是一个空行，最后就是报文实体的主体部分，包含一个由任意数据组成的数据块。但是并不是所有的报文都包含实体的主体部分。GET请求实例：GET/signup/signup.php?inviteCode=2388493434Host:Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8GET请求，请求的数据会附加在URL之后，以?分割URL和传输数据，多个参数用&连接，因此，GET请求的数据会暴露在地址栏中。GET请求的URL的编码格式采用的是ASCII编码，而不是uniclde，即是说所有的非ASCII字符都要编码之后再传输。对于GET请求，特定的浏览器和服务器对URL的长度有限制。因此，在使用GET请求时，传输数据会受到URL长度的限制。POST请求实例：POST/inventory-check.cgiHTTP/1.1Host:Content-Type:text/plainContent-length:18item=bandsaw2647POST请求会把请求的数据放置在HTTP请求包的包体中。上面的item=bandsaw就是实际的传输数据。对于POST，由于不是URL传值，理论上是不会受限制的，但是实际上各个服务器会规定对POST提交数据大小进行限制，Apache、IIS都有各自的配置。表10-1列出了GET请求和POST请求的区别：HTTP响应HTTP响应格式如下：<version><status><reason-phrase><headers><entity-body>第一行是状态行，由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔。状态代码由3位数字组成，表示请求是否被理解或被满足。状态描述给出了关于状态代码的简短的文字描述。状态代码的第一个数字定义了响应的类别，后面两位没有具体的分类。第一个数字有五种可能的取值：-1xx:指示信息—表示请求已接收，继续处理。-2xx:成功—表示请求已经被成功接收、理解、接受。-3xx:重定向—要完成请求必须进行更进一步的操作。-4xx:客户端错误—请求有语法错误或请求无法实现。-5xx:服务器端错误—服务器未能实现合法的请求。第二行是响应头，包含若干域段。例如Location响应报头域用于重定向接受者到一个新的位置；Server响应报头域包含了服务器用来处理请求的软件信息；Content-Encoding实体报头域被使用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容编码；Content-Length实体报头域用于指明正文的长度，以字节方式存储的十进制数字来表示，也就是一个数字字符占一个字节，用其对应的ASCII码存储传输。Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。第三行是一个空行第四行是响应的报文。例如下面是一个HTTP响应实例：HTTP/1.1200OKDate:Sat,31Dec200523:59:59GMTContent-Type:text/html;charset=ISO-8859-1Content-Length:122＜html＞

＜head＞

＜title＞WroxHomepage＜/title＞

＜/head＞

＜body＞

＜!--bodygoeshere--＞

＜/body＞＜/html＞3、CSRF攻击实施方式一般HTTP请求的发起分为GET和POST两种，对应的CSRF攻击实施方式也分为GET和POST两种类型，但两者的原理是一样的，只是构造请求的格式不同。下面以POST为例加以说明。如果用户user想要修改自己在的登录密码为password，那么他在浏览器登录系统后填写修改后的密码，然后提交给服务器的POST请求大致为：POST/account/updatePassword.htmlHTTP/1.iHOST:Connection:keep-aliveContent-Length:200User-Agent:Mozilla/5.0(WindowsNT5.1;rv:52.0)Gecko/20100101Firefox/52.0Accept-Language:zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3Accept-Encoding:gzip,deflateAccept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Referer:/account/updatePassword.htmlpassword_new=password&password_conf=password&Change=Change服务器响应之后，会返回HTTP/1.1200OK报文，至此用户user的密码就修改成功了。若攻击者attacker发现了A站点存在CSRF漏洞，想对用户user恶意修改其密码，那么攻击者只需要构建一个简单的URL请求/account/updatePassword.html?password_new=password2&password_conf=password2&Change=Change，然后诱骗用户user去访问。此时攻击者把含有恶意请求的代码加到自己的网站B中，只要用户user访问B站点中包含恶意请求的页面，该恶意请求就会以用户user的名义发送给Web站点A的服务器，此时用户user的密码就被恶意修改了，而用户user完全没有察觉。提交的这个恶意请求大致如下：POST/account/updatePassword.htmlHTTP/1.iHOST:Connection:keep-aliveContent-Length:200User-Agent:Mozilla/5.0(WindowsNT5.1;rv:52.0)Gecko/20100101Firefox/52.0Accept-Language:zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3Accept-Encoding:gzip,deflateAccept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Referer:/attack.htmlpassword_new=password2&password_conf=password2&Change=Change4、CSRF攻击成因（1）浏览器会自动发送标识用户身份的信息，这一过程对用户来说是透明的。当用户通过某站点的身份验证后，Web站点会发一个Cookie信息来标识用户，用户的浏览器会保存这个Cookie信息。之后只要该用户再发送请求给服务器，每次请求都会带有这个Cookie信息，Web站点看到带有此Cookie信息的请求后，便会任务该请求是此登录用户发起的。（2）请求的URL中会含有会话相关的信息。如/actionwidth=”0”height=”0”，这会弹出一个看不见的方框。如果攻击者对URL的了解非常透彻，那么其采去的攻击手段也非常多样。（3）为了提高Web应用的便利性，浏览器会自动存储Cookie、身份信息。特别是现在多标签浏览器的流行，给CSRF攻击创造了更有利的条件。因为新打开的窗口标签会继承之前已打开的窗口的认证信息，这样就延长了Cookie的失效时间。5、CSRF攻击防御（1）基于Referer的防御技术HTTP协议头中有一个Referer字段，它记录了HTTP请求的发起来源。可以通过Referer来判断请求是从同域下发起的，还是跨站发起的，进而来防御CSRF攻击。但是有些浏览器或工具可以对Referer字段进行伪造，因此该方法并不能完全防御CSRF攻击。（2）基于Token的防御技术请求中有关用户身份信息是存在于Cookie中的，要防御CSRF攻击，关键是在请求中加入攻击者无法伪造的信息，且该信息不能再Cookie中。通过在HTTP请求中以参数的形式加入随机的Token，然后在服务端来验证此Token，如果没有Token或Token不正确，则认为是CSRF攻击。通过前一节的项目分析我们介绍了CSRF攻击的概念、原理、实施和防御。CSRF攻击的本质是恶意攻击者以合法用户名义跨站点伪造GET或POST请求，服务端程序因无法对用户身份进行合法性验证，导致服务器响应请求后，完成攻击者对数据获取、更改等操作，并最终达到攻击者的目的。10.3项目小结本项目完成后，需要提交项目总结内容清单如表10-2所示：10.4项目训练

本章节中的所有实验环境都是安装在winxp虚拟机中，在虚拟机中使用的实验环境为DVWA实验环境，使用python-2.7+DVWA-1.9+xampp-win32-1.8.0-VC9-installer三个软件按搭建。使用到了中国菜刀、Burpsuit工具。Burpsuit运行环境需要安装jre，工具为：burpsuite_pro_v1.7.03、jre-8u111-windows-i586_8.0.1110.14、Firefox_152_setup。使用物理机作为攻击机。10.4.1实验环境1、打开靶机虚拟机，在虚拟机中打开桌面上的xampp程序确保Apache服务器与数据库mysql处于运行状态，如图10-3所示：10.4.2任务1利用简单实例认识CSRF攻击2、查看靶机服务器ip地址，在运行中运行cmd开启msdos窗口，在dos中运行ipconfig，查看当前服务器的ip地址，如图10-4所示：3、在攻击机中打开浏览器输入靶机的ip地址，因为我们是在DVWA平台中进行渗透测试，因此完整的路径为靶机ip地址+dvwa，具体为29/dvwa，在渗透平台中需要使用用户名与密码登录，默认账号为用户名：admin；密码：password。如图10-5所示：4、在登录平台后可以看到如图10-6所示界面，在左侧列表中选择DVWASecurity设置平台的安全级别，在本次实验中主要是利用CSRF攻击分析漏洞存在原理，因此设置安全级别为“low”然后提交。5、在图10-6所示中，选择左侧列表中的CSRF，进行CSRF攻击实验。在图10-7所示实验环境中，进行正常的数据输入。根据环境提示，需要输入Newpassword，在文本框中输入数字“12345”，再输入Confirmnewpassword，同样输入“12345”，然后提交，返回结果如图10-8所示。当我们两次输入的密码不一致时，返回结果如图10-9所示。6、通过上面数据输入与返回结果，可以分析出，服务端对提交的数据进行了两次密码是否一致的验证。如果一致就修改成功，否则就修改失败。7、进一步，我们利用Burp捕获软件对HTTP请求进行捕获，结果如图10-10所示。可以看到修改密码发起的请求是GET请求，请求URL是29/dvwa/vulnerabilities/csrf/?password_new=12345&password_conf=12345&Change=Change。8、那么此时，如果想把密码修改为attack，只需要重新打开一个浏览器的标签窗口，在浏览器窗口的地址栏里面输入如下URL，然后按下Enter键，密码就被重新进行修改了。29/dvwa/vulnerabilities/csrf/?password_new=attack&password_conf=attack&Change=Change。9、可以看到没有通过原始界面的Newpassword和Confirmnewpassword的输入，而是在另外的浏览器标签窗口地址栏直接向服务器发起GET请求，来完成密码的修改。这说明Web站点存在CSRF漏洞。漏洞的原因是服务端未对提交的请求做合法性认证。在任务1的实验中，请求的发送是直接接URL输入到地址栏中进行的。通常CSRF攻击不会实施，而是引导用户去访问攻击者的网站。利用Tomcat搭建一个网站，网站为http://localhost:8080/examples/attack.html，页面内容如下：<html><head></head><body><imgsrc=29/dvwa/vulnerabilities/csrf/?password_new=password2&password_conf=password2&Change=Change/></body></html>只要能诱导用户访问上述网页，修改密码的请求会自动发送到服务器，用户密码被修改为password2。10.4.3任务2利用CSRF攻击修改用户口令任务1中的实验PHP源码如图10-11所示10.4.4任务3防范XSS攻击可见，服务器收到修改密码的请求后，只做了检查参数password_new与password_conf是否相同，如果相同，就会修改密码，并没有任何的防CSRF机制（当然服务器对请求的发送者已经做了身份验证，即检查Cookie，只是这里的代码没有体现）。防御1：基于Referer技术将DVWASecurity平台的安全级别设置为media，做法与之前章节类似，这里不再赘述。之后无论是按照任务1在浏览器地址栏直接输入URL请求：29/dvwa/vulnerabilities/csrf/?password_new=password2&password_conf=password2&Change=Change，还是按照任务2通过一个攻击者站点访问，http://localhost:8080/examples/attack.html，密码修改均不成功，得到的结果如图10-12所示。

查看服务端源码如下，可以看到，源码中检查了保留变量HTTP_REFERER（http包头的Referer参数的值，表示来源地址）中是否包含SERVER_NA