什么是 CSRF CSRF 是对网站的恶意使用。 CSRF 比 XSS 更危险。攻击者窃取您的身份并以您的名义发送恶意请求。对服务器来说，这个请求是完全合法的，但是完成了攻击者预期的操作，比如以你的名义发送邮件和消息，盗取你的账户，添加系统管理员，甚至是购买商品，虚拟货币转账等。 CSRF 攻击的主要目的是让用户在不知不觉中攻击他们登录的系统，类似于网络钓鱼。如果用户当前登录的是邮箱或bbs，并且用户正在使用其他已被您控制的站点，我们将其称为钓鱼站点。本网站可能会因为某张图片而吸引您。如果你点击它，可能会触发一个js点击事件，构造一个bbs发帖请求，去你的bbs发帖，因为你的浏览器当前状态已经是登录状态，所以session登录cookie信息会是和普通请求一样，当前登录状态纯粹是为了让用户在不知情的情况下为你发帖或做其他事情。 CSRF攻击原理 从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤： 1、登录可信网站A，在本地生成cookies。 2. 访问危险网站B，无需退出A。 此时，你可能会说：“如果我不满足以上两个条件之一，我就不会被 CSRF 攻击”。是的，确实如此，但您不能保证不会发生以下情况： 1. 您不能保证在您登录一个网站后，您将不再打开一个标签页并访问另一个网站。 2. 您不能保证在您关闭浏览器后，您的本地 cookie 会立即过期，您的最后一个会话结束了。 （实际上，关闭浏览器并不会结束会话，但大多数人错误地认为关闭浏览器等同于注销/结束会话......） 3、上图中所谓的攻击网站，可能是受信任且经常访问的网站，存在其他漏洞。 防御 CSRF 攻击： 目前防御CSRF攻击主要有3种策略：验证HTTP Referer字段；向请求地址添加令牌并进行验证；自定义 HTTP 标头中的属性并进行验证。 (1) 验证 HTTP Referer 字段 根据HTTP协议，HTTP头中有一个字段叫做Referer，记录了HTTP请求的源地址。在正常情况下，访问安全受限页面的请求来自同一个网站。例如访问http://bank.example/withdraw account=bob&amount=1000000&for=Mallory，用户必须先登录bank.example，然后点击页面上的按钮触发转账事件。此时，转账请求的Referer值将是转账按钮所在页面的URL，通常是以bank.example域名开头的地址。如果黑客想要对银行的网站进行CSRF攻击，他只能在自己的网站上构造一个请求。当用户通过黑客网站向银行发送请求时，请求的Referer指向黑客自己的网站。因此，为了防御CSRF攻击，银行网站只需要对每个转账请求验证其Referer值即可。如果域名以bank.example开头，则表示请求来自银行网站本身，是合法的。如果Referer是其他如果是网站，可能是黑客的 CSRF 攻击，拒绝请求。 这种方法的明显优点是简单易实现。网站的普通开发者无需担心 CSRF 漏洞。他们只需要在最后对所有安全敏感的请求添加一个拦截器来检查Referer的值。尤其是对于现有系统，不需要改变现有系统的任何现有代码和逻辑，没有风险，非常方便。 但是，这种方法并非万无一失。 Referer 的值由浏览器提供。虽然对 HTTP 协议有明确的要求，但每个浏览器可能有不同的 Referer 实现，这并不能保证浏览器本身没有安全漏洞。使用验证Referer值的方法是依靠第三方（即浏览器）的安全来保证，理论上这是不安全的。事实上，对于一些浏览器，比如IE6或者FF2，已经有了篡改Referer值的方法。如果bank.example网站支持IE6浏览器，黑客可以完全将用户浏览器的Referer值设置为以bank.example域名开头的地址，从而通过验证，进行CSRF攻击。 即使使用最新的浏览器，黑客也无法篡改Referer值，这种做法仍然存在问题。因为Referer值会记录用户的访问来源，有些用户认为这会侵犯自己的隐私，尤其是一些组织担心Referer值会将组织内网的一些信息泄露给外网。因此，用户自己可以设置浏览器，使其在发送请求时不提供Referer。当他们正常访问银行网站时，网站会因为请求没有Referer值而认为是CSRF攻击，拒绝合法。用户访问。 (2) 将token添加到请求地址并验证 CSRF攻击之所以成功，是因为黑客可以完全伪造用户的请求。请求中的所有用户认证信息都存在于cookie中，因此黑客可以在不知道认证信息的情况下直接使用用户自己的cookie。通过安全验证。要防御 CSRF，关键是在请求中放入黑客无法伪造的信息，并且该信息不存在于 cookie 中。可以将随机生成的令牌以参数的形式添加到 HTTP 请求中，并在服务器端建立拦截器来验证令牌。如果请求中没有token或者token内容不正确，则认为是CSRF攻击，请求被拒绝。 这种方法比检查Referer更安全。可以在用户登录后生成token并放入session中，然后每次请求将token从session中取出并与请求中的token进行比较，但是这个方法的难点在于如何添加令牌作为请求的参数。对于 GET 请求，token 会附加到请求地址上，使 URL 变为 http://url csrftoken=tokenvalue。对于 POST 请求，应该在表单的末尾添加，以便将 token 以参数的形式添加到请求中。但是，在一个网站中，有很多地方可以接受请求。每次请求都加一个token很麻烦，很容易漏掉。通常的方法是每次页面加载时使用java进行遍历。对于整个 dom 树，在 dom 中所有的 a 和 form 标签后面加上 token。这没关系解决了大部分的请求，但是对于页面加载后动态生成的html代码，这种方法是没有效果的，程序员在编码的时候需要手动添加token。 这种方法的另一个缺点是难以保证代币本身的安全性。尤其是在一些支持用户发布自己内容的论坛等网站上，黑客可以在上面发布自己的个人网站地址。由于系统也会给这个地址添加一个token，黑客可以在自己的网站上拿到这个token，立即发起CSRF攻击。为了避免这种情况，系统可以在添加令牌时添加判断。如果链接是链接到自己的网站，后面会添加token，如果是链接到外网的，就不添加了。但是，即使csrftoken没有以参数的形式附加到请求中，黑客的网站也可以通过Referer获取token值来发起CSRF攻击。这也是部分用户喜欢手动关闭浏览器的referer功能的原因。 (3) 自定义HTTP headers中的属性并验证 此方法还使用令牌进行验证。与前一种方法不同的是，token不是以参数的形式放在HTTP请求中，而是放在HTTP头中的自定义属性中。通过XMLHttpRequest类，可以一次性为所有该类型的请求添加csrftoken HTTP头属性，并将token值放入其中。这样就解决了之前方法给请求添加token的不便。同时，通过XMLHttpRequest请求的地址不会记录在浏览器的地址栏中，也不用担心token会通过Referer泄露给其他网站。 然而，这种方法限制是巨大的。 XMLHttpRequest 请求通常用于 Ajax 方法中，用于页面的部分异步刷新。并不是所有的请求都适合这个类发起，通过这个类请求得到的页面不能被浏览器记录下来，所以可以进行前进、后退和刷新。 、收藏夹等操作会给用户带来不便。另外，对于没有CSRF保护的遗留系统，要使用这种方式进行保护，必须将所有请求都改成XMLHttpRequest请求，这几乎要重写整个网站，这无疑是不能接受的。 以上就是为大家整理的《什么是CSRF以及如何捍卫它》的全部内容。如果用户遇到的问题无法解决，可以咨询互联网数据客服了解防御方案。