CSRF跨站请求是伪造的，攻击者伪装成用户身份发送请求，从而窃取信息或破坏系统。以下文章主要介绍什么是CSRF攻击？而如何防范CSRF袭击，你可以参考给有需要的朋友。
目录
一、什么是CSRF攻击二、CSRF攻击的过程三、常见的CSRF攻击一、GET-type CSRF二、POST-type CSRF四、CSRF测试五、预防CSRF攻击5.1、验证HTTPReferer字段5.2、增加token验证5.3、HTTP头和验证摘要中的自定义属性。
一、什么是CSRF攻击
CSRF攻击的全称是跨站脚本伪造，也称为一键攻击或会话Eiding，通常缩写为CSRF或XSRF。CSRF通过伪装可信用户的请求来攻击可信网站。与XSS相比，CSRF的袭击通常不太受欢迎(因此防范这些袭击的资源很少)，也很难防范，因此被认为比XSS更危险。我们可以这样理解CSRF攻击：首先，攻击者会窃取你的身份，然后以你的名义做一些非法操作，甚至窃取从你的账户购买的商品。CSRF攻击的价值在于利用了web中用户认证的一个漏洞：简答认证只能保证请求来源于用户的浏览器，而不能保证请求本身来源于用户资源。
二、CSRF攻击的流程
CSRF攻击的原理过程如下：
1.用户C打开浏览器，访问安全网站A，输入用户名和密码请求登录网站A .
2.验证用户信息后，网站A生成Cookie信息并返回给浏览器。此时，用户成功登录网站A，可以正常向网站A发送请求。
3.在用户退出A之前，在同一个浏览器中，打开一个标签页访问网站b .
4.网站B收到用户请求后，返回一些攻击代码，并发送访问第三方网站a的请求.
5.浏览器收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带cookie信息，向网站A发送请求，网站A并不知道该请求实际上是B发出的，所以会根据用户C的Cookie信息，在C的许可下处理该请求，导致来自网站B的恶意代码被执行。
从以上过程可以看出，要实现CSRF攻击，必须满足两个基本条件。
1.登录到可信网站A并在本地生成Cookie。
2.在不注销网站a的情况下访问危险网站B .
三、常见的CSRF攻击
1、GET类型的CSRF
银行站点A:通过GET请求完成银行转账；如http://www.mybank.com.Transfer.php？toBankId=11money=1000
危险网站B:有一个html代码img src=http://www.mybank.com/transfer.php? to bankid=111000
首先，你登录银行网站A，然后访问危险网站B，然后你会发现你的银行账号少了1000元。为什么会这样？原因是银行站点A违反了HTTP规范，使用GET请求更新资源。在访问关键站点B之前，您已经登录了银行站点A，在B中有一个合法的请求，但是被不法分子利用了)。所以你的浏览器会用你的银行站点A的Cookie发出GET请求，获取资源，以Get的方式请求第三方资源(这里的第三方指的是银行站点，原来这是http://www.mybank.com/Transfer.php? ToBankId=11 money=1000。结果银行站点服务器收到请求后，觉得是资源更新操作(转账操作)，于是马上转账。
2、POST类型的CSRF
这种类型的CSRF不像GET类型那样有害，它通常使用自动提交表单，比如
form action=http://woo yun . org/csrf . PHP method=POST
输入类型='text' name='xx' value='11' /
/表单
编写document.forms[0]的脚本。submit()；/脚本
访问这个页面后，表单会自动提交，相当于模拟用户完成一个POSt操作。
四、CSRF测试
检测CSRF漏洞是一项单调乏味的任务。最简单的方法是抓取正常请求的数据包，删除Referer字段并重新提交。如果该提交仍然有效，则基本上可以确定CSRF漏洞存在。随着对CSRF漏洞研究的深入，一些检测CSRF漏洞的工具不断涌现，如CSRFTester、CSRF请求生成器等。以CSRF Tester为例，CSRF漏洞检测工具的测试原理是：用CSRF测试器测试时，首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过修改CSRFTester中相应的表单等信息(比如更改Referer字段的信息)重新提交，相当于一个假的客户端请求。如果修改后的测试请求被网站服务器成功接受，则意味着存在CSRF漏洞。当然，这个工具也可以用于CSRF攻击。
五、预防CSRF攻击
5.1、验证HTTP Referer字段
以上面的银行转账为例。首先，当我们向一个银行站点发送请求时，HTTP协议的头部将携带Referer字段，该字段包含所请求站点的域名。这时，如果我们访问银行站点并向银行发出请求，我们携带的Referer是mybank.com。如果此时我们从一个危险网站B向银行网站发出请求，此时的Referer就是危险网站B的域名，那么我们可以通过判断Referer来判断是否可以进行操作。这将简单地防止CSRF，但仍然存在一些问题。比如我们通过查看推荐人来判断域名，这个决定权在浏览器。此时，如果某些浏览器可以重写referrer的值，那么CSRF攻击仍然有效。也有一些用户会禁用Referer字段，这将导致无法请求网站数据。
验证推荐人的方法总数：
优点：易于使用，开发简单，可以在一定程度上防止CSRF攻击。
缺点：这种机制完全依赖浏览器，Referer字段容易被有意篡改或禁用。
5.2、添加token验证
当用户请求时，我们可以在安全站点A中生成一个SessionId，并将其保存在服务器端。该值可以作为令牌传递给客户端。客户端可以设置一个隐藏的输入框，其中的值就是令牌。当我们发出请求时，值会被传送到站点a中的服务器，此时服务器可以比较生成的令牌是否与保存的令牌相同。如果相同，说明是安全站点的请求，会做出具体的相应措施。在危险网站B上无法获得令牌，因此无法提出正确的请求。如果使用post请求，我们可以将它放在隐藏的输入框中。如果是get请求，我们可以这样写。像https://www.myBank.com一样？token=XXXXX .然后一个网站有很多要求。这时，如果我们为每一个都设置token，将会非常笨拙。此时，我们可以遍历所有dom，获取所有A标签和form标签，并添加它们。但是，如果页面的DOM是动态生成的，程序员需要编写自己的代码来将令牌放入其中。还有一个问题：如何确保令牌不被攻击者截获？
添加令牌方法摘要：
安全度高于Referer，实现略复杂。有必要确保令牌存储的安全性。
5.3、在HTTP头中自定义属性并验证
这个方法也保存了令牌，但实际上，它将令牌保存在HTTP头中。我们可以一次性将这个自定义字段添加到所有访问网站的请求中，但是如何在HTTP中存储数据呢？此时，我们需要另一个模块XHRHTTPRequest。当我们使用这个模块的时候，还有一个缺点，就是它只能是一个异步请求。其他请求不可访问。另外，对于没有CSRF保护的遗留系统，采用这种方式保护无疑是不可接受的，把所有请求都改成XMLHttpRequest请求，几乎会重写整个网站。
验证头方法概述：
1、使用方式简单，不易泄露。
2、使用的局部局限性。
架设补充：防火墙是网络安全的重要保障。企业级防火墙的架设应该有两级防火墙。Web服务器和一些应用服务器可以架设在两级防火墙之间的DMZ中，而数据和资源服务器应该架设在第二级防火墙之后。
总结
以上就是这篇关于如何防范CSRF袭击的文章。有关防止CSRF攻击的更多信息，请搜索我们以前的文章或继续浏览下面的相关文章。希望你以后能支持我们！
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。