标签：能力 tps 不用 nta 指南 http协议 需求 很多 区分
CSRF 英文全称是 Cross-site request forgery，所以又称为“跨站请求伪造”，也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。**跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。 **
对于大多数站点，浏览器请求将自动包括与该站点相关联的任何凭据，例如用户的会话cookie，IP地址，Windows域凭据等。因此，如果用户当前已通过站点认证，则该站点将无法区分受害者发送的伪造请求和受害者发送的合法请求。
简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
下面先看一个CSRF经典攻击例子，用户A通过银行提供的URL地址进行转账户操作：
用户A通过GET向银行站点发起请求，此时的用户A已经是被认证的状态了，它的浏览器中的Cookie缓存着已经认证的会话ID(这是1步骤)
黑客在另一个网站（第三方站点），放置上图中隐藏在图片资源中的恶意转账需求的链接。如果用户A访问了这个第三方的站点（这是步骤2），由于他之前刚访问银行站点不久，登录的信息尚未过期，此时银行站点对用户浏览器是充分信任的，无论啥请求照单全收，页面加载时，浏览器就自动发起了img中资源请求，银行站点无法分辨出是否是用户A的真实操作，因此用A损失了1000刀，心好疼啊！
从上述的例子可以知道，黑客实施的攻击方式是自动发起GET请求，这同时也是黑客最简易和常用的方式，这种恶意的网址可以有很多种形式，藏身于网页中的许多地方，例如可以插入url的一些地方
<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">
除了自动发起get请求之外，有些站点服务器接口使用的POST方法，此时黑客可以在该站点上潜伏伪造POST请求，一般在论坛，博客等任何用户生成内容的网站中都可能是攻击发源地。当用户访问黑客的站点的，就会自动触发POST请求，如自动触发表表单提交：
<html>
<body>
<form class="hacker" action="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman" method=POST>
<input type="hidden" name="account" value="用户A" />
<input type="hidden" name="for" value="hacker" />
<input type="hidden" name="amount" value="1000" />
</form>
<script> document.getElmentsByClassName("hacker").submit(); </script>
</body>
</html>
如下图，所示，真的陌生网站链接不要随便点，尤其是关乎钱，要仔细看，有些网站伪装太像了。
同以上两个请求类似，一旦你点击图中领奖的链接，那么你很可能就访问到了黑客站点，那里预设了一个圈套，等你去触发，从而造成你的财务上的损失。
以上了解到了三种黑客经常采用的攻击方式，根据去其攻击流程，可以发现以CSRF攻击的特征，想要成功实施一次CSRF必须具备以下几点特征：
CSRF的特征：
具备了以上条件后，CSRF攻击就开始进行了，前面提到过跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任，对服务器发起攻击，被攻击的服务器是是可以从阻断攻击，或者正面刚，提高自身的攻击能力来提高安全性，主要有以下几个主流的方法：
该SameSite属性使服务器要求cookie不应与跨站点请求一起发送（该站点由可注册域定义），这为跨站点请求伪造攻击（CSRF）提供了一些保护。
从上述的例子CSRF攻击中一个特征就是，黑客会利用用户未过期的登录状态，即用户浏览器中Cookie缓存的已经认证的会话ID.来发起CSRF攻击
要找阻止黑客通过冒用用户登录信息进行CRSF攻击，就要在Cookie这个关键字上面施加一些手段
SameSite属性主要做两件事，第一个就是控制跨站点访问，第二就是保证同一站点的稳定安全访问。CSRF攻击都是从第三方站点发起了，在浏览器分辨不出好坏请求时，通过一些属性值可以有效限制Cookie的发送。如在http相应头中：
Set-Cookie: mykey=myvalue; SameSite=Strict
它有三个可能的值：Strict，Lax，和None。
值得注意的是浏览器正在迁移，以将Cookie设置为SameSite=Lax。但是并非所有的默认浏览器都是这样，如果需要跨域发送cookie，需要显式的设置None属性值选择退出SameSite限制。还必须将Secure属性添加到SameSite=None cookies中。如：
Set-Cookie: mykey=myvalue; SameSite=none;Secure
对于防范 CSRF 攻击，根据具体的应用场景将一些些关键的 Cookie 设置为 Strict ，Lax 或者None模式，这样在跨站点请求时，这些关键的 Cookie 就不会被发送到服务器，从而使得黑客的 CSRF 攻击失效。
HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。
以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问
这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的Referer字段。
虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。所以浏览器提供给开发者一个选项，可以不用上传 Referer 值，可参考具体使用参考Referrer-Policy |MDN
因此标准委员会又制定了Origin 属 性，请求首部字段 Origin 指示了请求来自于哪个站点。该字段仅指示服务器名称，并不包含任何路径信息（处于安全考虑）。该首部用于 CORS 请求（XMLHttpRequest、Fecth ）或者 POST 请求。除了不包含路径信息，该字段与 Referer 首部字段相似。例如
Origin: https://developer.mozilla.org
服务器的策略是优先判断 Origin，如果请求头中没有包含 Origin 属性，再根据实际 情况判断是否使用 Referer 值。
由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再运行CSRF攻击.主要分为以下两步：
**第一步: **这种数据通常是窗体中的一个数据项。服务器将其生成并附加在窗体中，其内容是一个伪随机数。当客户端通过窗体提交请求时，这个伪随机数也一并提交上去以供校验。例如通过以下函数去生成：
function getCookie(name) {
var cookieValue = null;
if (document.cookie && document.cookie !== ‘‘) {
var cookies = document.cookie.split(‘;‘);
for (var i = 0; i < cookies.length; i++) {
var cookie = cookies[i].trim();
//这个cookie字符串是否以我们想要的名称开头？
if (cookie.substring(0, name.length + 1) === (name + ‘=‘)) {
cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
break;
}
}
}
return cookieValue;
}
var csrftoken = getCookie(‘csrftoken‘);
**第二步：**正常的访问时，客户端浏览器能够正确得到并传回这个伪随机数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪随机数的值，服务端就会因为校验token的值为空或者错误，拒绝这个可疑请求。
更多具体实践操作请参考：Cross Site Request Forgery protection | Django documentation | Django. docs.djangoproject.com. [2020-01-21].
应该遵循以下原则来防御CSRF 具体方式见跨站点请求防伪备忘单
Cross-site request forgery on Wikipedia
Cross-site request forgery | MDN
标签：能力 tps 不用 nta 指南 http协议 需求 很多 区分
原文地址：https://www.cnblogs.com/eric021/p/12994806.html
