什么是CSRF
成都创新互联公司一直秉承“诚信做人，踏实做事”的原则，不欺瞒客户，是我们最起码的底线！ 以服务为基础，以质量求生存，以技术求发展，成交一个客户多一个朋友！为您提供成都网站建设、成都网站制作、成都网页设计、微信小程序定制开发、成都网站开发、成都网站制作、成都软件开发、重庆App定制开发是成都本地专业的网站建设和网站设计公司，等你一起来见证！
CSRF（Cross-siterequestforgery跨站请求伪造，也被称为“oneclickattack”或者sessionriding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且***方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS***相比，CSRF***往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
Xss与CSRF异同
CSRF与XSS在***手段上有点类似，都是在客户端执行恶意代码，有些文章中认为CSRF与XSS的区别在于CSRF不注重于获取用户Cookie，笔者认为可能还有区别在于CSRF不仅可以在源站发起***，还可以引导用户访问其他危险网站的同时发起***。
XSS全程是跨站脚本***，即***者向某个Web页面中插入恶意的JavaScript脚本。而当普通用户访问时，该恶意脚本自动执行而从盗取用户的Cookie等信息。对于XSS的防御手段主要就是输入检查与输出检查，譬如对用户输入的文本框内容进行<、>这样的特殊字符检查。而输出检查则是指对于输出到网页的内容进行过滤或者编解码，譬如使用HTML编码将<转义。
CSRF为跨站请求伪造，其与XSS有点类似，不过区别在于CSRF不一定依赖于JavaScript，并且不仅可以在源站发起***，还有可能当用户访问恶意网站时引导其访问原网站。CSRF***是源于WEB的隐式身份验证机制，WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。对于CSRF的防御也分为服务端防御与客户端防御两种，服务端防御典型的譬如给某个页面添加随机数，使得无法从第三方页面直接提交。在客户端防御的话可以利用譬如Firefox提供的一些检查工具。注意，CSRF并没有打破同源策略。
CSRF的危害
你这可以这么理解CSRF***：***者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，
虚拟货币转账等等造成的问题包括：个人隐私泄露以及财产安全。
下图简单阐述了CSRF***的思想：
从上图可以看出，要完成一次CSRF***，受害者必须依次完成两个步骤：
1.登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。
看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的***”。是的，确实如此，但你不能保证以下情况不会发生：
1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）
3.上图中所谓的***网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。同样也可以是一个恶意的url。
SCRF触发条件
1、被***者的用户cookies
2、恶意的url或表单
CSRF的防御
CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。
1.服务端进行CSRF防御
服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。
(1).Cookie Hashing(所有表单都包含同一个伪随机值)：
这可能是最简单的解决方案了，因为***者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了
//构造加密的Cookie信息
$value = “DefenseSCRF”;
setcookie(”cookie”, $value,time()+3600);
?>
在表单里增加Hash值，以认证这确实是用户发送的请求。
$hash = md5($_COOKIE['cookie']);
?>
然后在服务器端进行Hash值验证
if(isset($_POST['check'])) {这个方法目前觉得已经可以杜绝大多数***了，那还有少数由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，一般的***者看到有需要算Hash值，基本都会放弃了，当然也有些人除外，所以如果需要100%的杜绝，这并不是最好的方法。
(2).验证码
这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，厄....这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。
(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)
在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。
以下我的实现:
1).先是令牌生成函数(gen_token())：
function gen_token() {
2).然后是Session令牌生成函数(gen_stoken())：
function gen_stoken() {3).WEB表单生成隐藏输入域的函数：
function gen_input() {
4).WEB表单结构：
session_start();5).服务端核对令牌
