1、什么是CSRF
CSRF跨站点请求伪造(Cross—Site Request Forgery)， 是一种恶意的，利用网站信任的用户发送一些未经用户授权的请求。
例如:攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。
CSRF漏洞是在用户浏览器中利用站点对用户的信任，然后对特定网站发起的攻击。
比如Web应用程序，它将经过身份信息验证的用户信息保存在cookie中，基于cookie来验证用户身份，继而执行操作，无需用户每次操作都输入身份信息。然而用户可能会在不知情的情况下将HTTP请求(携带cookie)发送到站点，从而导致用户不知情的操作。
2、 CSRF 特点
CSRF一般具有以下特点：
- 它存在于依赖用户身份认证的站点。
- 它利用了站点对用户身份的信任。
- 它欺骗用户的浏览器，将HTTP请求发送到目标站点。
- 它所发出的HTTP请求是用户意料之外的
3、举例CSRF攻击过程
CSRF过程.png
其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。
实际举例：
受害者C 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=C&amount=1000000&for=C2可以使 C 把 1000000 的存款转到 C2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 C 已经成功登陆。
黑客 W 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。W 可以自己发送一个请求给银行：http://bank.example/withdraw?account=C&amount=1000000&for=W。但是这个请求来自而非 C，他不能通过安全认证，因此该请求不会起作用。
这时，W 想到使用 CSRF 的攻击方式，他先自己做一个网站B，在网站中放入如下代码： src='http://bank.example/withdraw?account=C&amount=1000000&for=W'，并且通过广告等诱使 C 来访问他的网站。当 C 访问该网站时，上述 url 就会从 C 的浏览器发向银行，而这个请求会附带 W 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 C 的认证信息。但是，如果 C 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有C的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 C 的账号转移到 W 的账号，而 C 当时毫不知情。等以后 C 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 W 则可以拿到钱后逍遥法外。
4、CSRF 防御
- 验证 HTTP Referer 字段
对于需要防范 CSRF 的请求，可以通过验证 Referer 来判断该请求是否为第三方网站发起的。在后台接收到请求的时候,可以通过请求头中的Referer请求头来判断请求来源。
根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问 http://bank.example/withdraw?account=C&amount=1000000&for=W，用户必须先登陆bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank.example 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。
这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。
然而，这种方法并非万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，目前已经有一些方法可以篡改 Referer 值。
即便是使用最新的浏览器，黑客无法篡改 Referer 值，这种方法仍然有问题。因为 Referer 值会记录下用户的访问来源，有些用户认为这样会侵犯到他们自己的隐私权，特别是有些组织担心 Referer 值会把组织内网中的某些信息泄露到外网中。因此，用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时，网站会因为请求没有 Referer 值而认为是 CSRF 攻击，拒绝合法用户的访问。
-
Token
服务器下发一个随机 Token（算法不能复杂），每次发起请求时将 Token 携带上，服务器验证 Token 是否有效。 -
HttpOnly
这个属性用来防止例如跨站脚本等攻击，设置它的cookie不允许通过JavaScript来访问。
5、Axios CSRF 防御
Axios 是目前使用最广的前端发请求的库。Axios 提供了 xsrfCookieName 和 xsrfHeaderName 两个属性来分别设置 CSRF 的 Cookie 名称和 HTTP 请求头的名称。
// `xsrfCookieName` is the name of the cookie to use as a value for xsrf token
xsrfCookieName: 'XSRF-TOKEN', // default
// `xsrfHeaderName` is the name of the http header that carries the xsrf token value
xsrfHeaderName: 'X-XSRF-TOKEN', // default
其实现：
// Add xsrf header
// This is only done if running in a standard browser environment.
// Specifically not if we're in a web worker, or react-native.
if (utils.isStandardBrowserEnv()) {
// Add xsrf header
var xsrfValue = (config.withCredentials || isURLSameOrigin(fullPath)) && config.xsrfCookieName ?
cookies.read(config.xsrfCookieName) :
undefined;
if (xsrfValue) {
requestHeaders[config.xsrfHeaderName] = xsrfValue;
}
}
我理解 其实现方式是 通过 在 header中添加 token信息 进行校验，提高了伪造的门槛。
hi~ 上面写的有啥问题没~ 点赞了没~
网友评论