&&：并且 ||：或者
HTTP 的请求方法
put, delete, post, get , head
TCP 的 三次握手与四次挥手
第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手
通俗的说法
1）Client：我所有东西都说完了
2）Server：我已经全部听到了，但是等等我，我还没说完
3）Server：好了，我已经说完了
4）Client：好的，那我们的通信结束l
HTTP 常见的请求头
l Accept：浏览器可接受的MIME类型；
l Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间；
l Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到；
l Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中；
l Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小；
l From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它；
l If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答；
l Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝；
l Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。
l User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用；
l UA-Pixels**，UA-Color，UA-OS，UA-CPU**：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。
HTTP 状态码
HTTP 与 HTTPS 的区别 、
https是安全协议连接，在信息传输上更为保密和安全，而http则安全性较低，会发生信息泄露和被劫持篡改。
基本概念
HTTP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。
HTTP 默认工作在 TCP 协议 80 端口，用户访问网站 http:// 打头的都是标准 HTTP 服务。
HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
HTTPS 默认工作在 TCP 协议443端口，它的工作流程一般如以下方式：
- 1、TCP 三次同步握手
- 2、客户端验证服务器数字证书
- 3、DH 算法协商对称加密算法的密钥、hash 算法的密钥
- 4、SSL 安全加密隧道协商完成
- 5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。
截至 2018 年 6 月，Alexa 排名前 100 万的网站中有 34.6% 使用 HTTPS 作为默认值，互联网 141387 个最受欢迎网站的 43.1% 具有安全实施的 HTTPS，以及 45% 的页面加载（透过Firefox纪录）使用HTTPS。2017 年3 月，中国注册域名总数的 0.11％使用 HTTPS。
根据 Mozilla 统计，自 2017 年 1 月以来，超过一半的网站流量被加密。
HTTP 与 HTTPS 区别
- HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
- 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
- HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
- http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
- HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。
TCP 三次握手
在TCP/IP协议中，TCP协议通过三次握手建立一个可靠的连接
- 第一次握手：客户端尝试连接服务器，向服务器发送 syn 包（同步序列编号Synchronize Sequence Numbers），syn=j，客户端进入 SYN_SEND 状态等待服务器确认
- 第二次握手：服务器接收客户端syn包并确认（ack=j+1），同时向客户端发送一个 SYN包（syn=k），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态
- 第三次握手：第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手
简化：
HTTPS 的工作原理
我们都知道 HTTPS 能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用 HTTPS 协议。
1、客户端发起 HTTPS 请求
这个没什么好说的，就是用户在浏览器里输入一个 https 网址，然后连接到 server 的 443 端口。
2、服务端的配置
采用 HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl 就是个不错的选择，有 1 年的免费服务)。
这套证书其实就是一对公钥和私钥，如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
3、传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
4、客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。
如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
5、传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6、服务端解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
7、传输加密后的信息
这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。
8、客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。
HTTPS中的三个随机数是如何生成会话密钥的
使用三个随机数，是因为 SSL 的协议默认不信任每个主机都能产生完全随机的数，如果只使用一个伪随机的数来生成秘钥，就很容易被破解。
通过使用三个随机数的方式，增加了自由度，一个伪随机可能被破解，但是三个伪随机就很接近于随机了，因此可以使用这种方法来保持生成秘钥的随机性和安全性。
XSS 攻击及如何防范
对于XSS 和 CSRF 如何防范
这里就不说概念性的东西了
-
XSS的防范
- 我能想到的就是转义
<>这些造成代码直接运行的的标签..轮询或者正则替换- 而面试官说这种的效率最低下,我回来仔细找了找相关资料好像没有更优方案,有的留言,
- 若是有用到
cookie,设置为http-only,避免客户端的篡改
- 我能想到的就是转义
-
CSRF的防范一般这几种
- 验证码,用户体验虽然不好,,但是很多场合下可以防范大多数攻击
- 验证
HTTP Referer字段,判断请求来源 token加密解密,这种是目前很常用的手段了,
任何防范都有代价的,比如验证码造成的体验不好,token滥用造成的性能问题,轮询替换造成的响应时间等
Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。
为了和 CSS 区分，这里把攻击的第一个字母改成了 X，于是叫做 XSS。
XSS 的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。
而由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，或者利用这些信息冒充用户向网站发起攻击者定义的请求。
在部分情况下，由于输入的限制，注入的恶意脚本比较短。但可以通过引入外部的脚本，并由浏览器执行，来完成比较复杂的攻击策略。
这里有一个问题：用户是通过哪种方法“注入”恶意脚本的呢？
不仅仅是业务上的“用户的 UGC 内容”可以进行注入，包括 URL 上的参数等都可以是攻击的来源。在处理输入时，以下内容都不可信：
来自用户的 UGC 信息
来自第三方的链接
URL 参数
POST 参数
Referer （可能来自不可信的来源）
Cookie （可能来自其他子域注入）
XSS 分类
根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种。
|类型|存储区|插入点|
|-|-|
|存储型 XSS|后端数据库|HTML|
|反射型 XSS|URL|HTML|
|DOM 型 XSS|后端数据库/前端存储/URL|前端 JavaScript|
存储区：恶意代码存放的位置。
插入点：由谁取得恶意代码，并插入到网页上。
存储型 XSS
存储型 XSS 的攻击步骤：
1.攻击者将恶意代码提交到目标网站的数据库中。
2.用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
3.用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4.恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
反射型 XSS
反射型 XSS 的攻击步骤：
1.攻击者构造出特殊的 URL，其中包含恶意代码。
2.用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
3.用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4.恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。
由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。
POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。
DOM 型 XSS
DOM 型 XSS 的攻击步骤：
1.攻击者构造出特殊的 URL，其中包含恶意代码。
2.用户打开带有恶意代码的 URL。
3.用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
4.恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
XSS 攻击的预防
通过前面的介绍可以得知，XSS 攻击有两大要素：
1.攻击者提交恶意代码。
2.浏览器执行恶意代码。
针对第一个要素：我们是否能够在用户输入的过程，过滤掉用户输入的恶意代码呢？
输入过滤
在用户提交时，由前端过滤输入，然后提交到后端。这样做是否可行呢？
答案是不可行。一旦攻击者绕过前端过滤，直接构造请求，就可以提交恶意代码了。
那么，换一个过滤时机：后端在写入数据库前，对输入进行过滤，然后把“安全的”内容，返回给前端。这样是否可行呢？
我们举一个例子，一个正常的用户输入了 5 < 7 这个内容，在写入数据库前，被转义，变成了 5 < 7。
问题是：在提交阶段，我们并不确定内容要输出到哪里。
这里的“并不确定内容要输出到哪里”有两层含义：
1.用户的输入内容可能同时提供给前端和客户端，而一旦经过了escapeHTML()，客户端显示的内容就变成了乱码( 5 < 7 )。
2.在前端中，不同的位置所需的编码也不同。
当 5 < 7 作为 HTML 拼接页面时，可以正常显示：< div title = "comment" > 5 < 7 </ div >。
当 5 < 7 通过 Ajax 返回，然后赋值给 JavaScript 的变量时，前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示，也不能直接用于内容长度计算。不能用于标题、alert 等。
所以，输入侧过滤能够在某些情况下解决特定的 XSS 问题，但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。
当然，对于明确的输入类型，例如数字、URL、电话号码、邮件地址等等内容，进行输入过滤还是必要的。
既然输入过滤并非完全可靠，我们就要通过“防止浏览器执行恶意代码”来防范 XSS。这部分分为两类：
1.防止 HTML 中出现注入。
2.防止 JavaScript 执行时，执行恶意代码。
预防存储型和反射型 XSS 攻击
存储型和反射型 XSS 都是在服务端取出恶意代码后，插入到响应 HTML 里的，攻击者刻意编写的“数据”被内嵌到“代码”中，被浏览器所执行。
预防这两种漏洞，有两种常见做法：
1.改成纯前端渲染，把代码和数据分隔开。
2.对 HTML 做充分转义。
纯前端渲染
纯前端渲染的过程：
1.浏览器先加载一个静态 HTML，此 HTML 中不包含任何跟业务相关的数据。
2.然后浏览器执行 HTML 中的 JavaScript。
3.JavaScript 通过 Ajax 加载业务数据，调用 DOM API 更新到页面上。
在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。
但纯前端渲染还需注意避免 DOM 型 XSS 漏洞（例如 onload 事件和 href 中的 javascript:xxx 等，请参考下文”预防 DOM 型 XSS 攻击“部分）。
在很多内部、管理系统中，采用纯前端渲染是非常合适的。但对于性能要求高，或有 SEO 需求的页面，我们仍然要面对拼接 HTML 的问题。
转义 HTML
如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。
常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ' / 这几个字符转义掉，确实能起到一定的 XSS 防护作用，但并不完善：
| XSS 安全漏洞 | 简单转义是否有防护作用 |
|---|---|
| HTML 标签文字内容 | 有 |
| HTML 属性值 | 有 |
| CSS 内联样式 | 无 |
| 内联 JavaScript | 无 |
| 内联 JSON | 无 |
| 跳转链接 | 无 |
所以要完善 XSS 防护措施，我们要使用更完善更细致的转义策略。
1. 在tp框架中做xss攻击可以通过create方法实现数据收集，就自动防止xss攻击了
create()------>I()------->htmlspecialchars()
2. 普通表单域通过函数防范XSS攻击
CSRF 攻击及如何防范
1、CSRF攻击是什么？如何防范？
CSRF(Cross-site request forgery), 中文名称：跨站请求伪造。攻击者盗用了你的身份，以你的名义发送恶意请求。
CSRF能做的事情包括：以你的名义发送邮件，发消息，盗取你的账号，在受害者不知情的情况下，以受害者名义伪造请求发送给受攻击站点，从而在受害者并未授权的情况下执行受害者权限下的各种操作。
2、CSRF攻击的原理
- 正常网站A,存在CSRF漏洞;恶意网站B含有攻击性代码，用来对网站A进行攻击。
- 正常网站A，有两个用户user01(受害者)和user02(攻击者)。
- user02(攻击者)清楚的了解网站A,并创建了具有攻击性的网站B(钓鱼网站)。
- user01(受害者)登录了网站A后，在自身的session未失效的情况下，访问了恶意网站B.
3、 CSRF攻击的过程
- 1.用户user01通过浏览器访问正常网站A,输入用户名和密码请求登录验证
- 2.登录验证通过后，网站A保存user01的session,并将对应的cookie返回给user01的浏览器。这样user01就可以在网站A执行自身权限下的各种请求(操作)，比如取钱，发表文章，发表评论等
- 3.user01在未退出网站A的时候，在同一浏览器，点击访问了恶意网站B(钓鱼网站)，此时user02拿到user01的认证信息或者登录状态
- 4.网站B是user02创建的，user02清楚的知道网站A的工作模式，网站B通过攻击性代码访问网站A（携带的是user01的cookie)，执行某些并非user01授意的操作。
- 5.网站A并不知道这个恶意请求是从网站B发出的，因此，就会根据user01在网站A中具备的相关权限，执行权限下的各种操作。这样，就在user01不知情的情况下，user02假冒了user01,执行了具备user01用户身份才可以执行的操作
4、CSRF攻击实例
假设，现在有一个受害者Bob，在网站http://bank.expample/有一大笔存款。
Bob通过银行的网站发送请求http://bank.example/withdraw?account=Bob&amount=100000&to=Bob2,Bob将100000的存款转账到Bob2的账户下，通常情况下，该请求发送到银行网站后，服务器会先验证该请求是否来自一个合法的session,该session的用户Bob已经成功登录
黑客Hack自己在该银行也有自己的账户，他知道银行转账操作的URL。Hack可以自己发送一个请求给银行：http://bank.example/withdraw?account=Bob&amount=100000&to=Hack,但是这个请求来自Hack，并非Bob,他不能通过安全验证，因此该请求不会起作用。这时，Hack香到使用CSRF的攻击方式，他先自己做一个网站B,在网站B中放入如下代码：src="http://bank.example/withdraw?account=Bob&amount=100000&to=Hack"，并通过广告等方式诱使Bob访问他的网站。当Bob访问网站B的时候，上述URL就会从Bob的浏览器发向银行，并且这个请求会附带Bob浏览器的cookie一起发现银行服务器。当然，大多数情况下，该请求会失败（session有有效时间），因为银行网站需要要求Bob的认证信息。
但是如果Bob当时恰巧刚访问银行网站后不久，他的浏览器与银行网站的session尚未过期（比如Bob在一个窗口还未退出银行网站），而浏览器中的cookie就含有Bob的认证信息，银行网站的对应session数据还在。
这时悲剧就发生了，这个URL会得到银行服务器的响应，钱将从Bob的账号转移到Hack的账号，而Bob并不知情。等事后Bob发现账户钱变少了，去银行查询流水，却发现是他自己转移账户的钱，没有任何被攻击的痕迹（我搞我自己？人类迷惑行为）
在这个示例中，银行网站错误的认为，这个转账时Bob本人执行的
5、CSRF攻击的对象
从以上的例子可知，CSRF攻击是黑客借助受害者的cookie伪造请求，骗取服务器的信任。黑客所能做的就是给服务器发送伪造请求，改变请求时的参数。所以我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务。则不需要进行CSRF的保护。比如银行系统中转账的请求会直接改变账户的金额，会遭到CSRF攻击，需要保护，而查询余额是对金额的读取操作，不会改变数据，无需保护
6、CSRF漏洞检测
检测CSRF漏洞是一项比较繁琐的工作，最简单的一个方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。
随着对CSRF漏洞研究的不断深入，出现了一些针对CSRF漏洞进行检测的工具，如CSRFTester,CSRE Request Builder等。
CSRFTester工具的测试原理大概是这样的，使用代理抓取我们在浏览器中访问过的所有的连接以及所有的表单等信息，通过在CSRFTester中修改相应的表单等信息，重新提交，相当于一次伪造客户端请求，如果修测试的请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击
7、防范CSRF攻击的几种策略
防范原理：防范CSRF攻击，其实本质上就是要求网站能够识别出哪些请求是非正常用户主动发起的。这就要求我们在请求中嵌入一些额外的授权数据，让网站服务器能够区分出这些未授权的请求。比如在请求参数中加一个字段，这个字段的值从登录用户的Cookie或者页面中获取（这个值需要是随机的，无规律可循）。攻击者伪造请求的时候无法获取页面中与登录用户有关的一个随机值或者cookie中的内容的。因此就可以避免这种攻击
目前防御CSRF攻击主要有以下几种策略
-
- 验证HTTP Referer字段
-
- 使用验证码（关键页面加上验证码验证，这种方法对用户不友好，不推荐）
-
- 在请求地址中加入token并验证
-
- 在HTTP头中自定义属性并验证
验证HTTP Referer字段
HTTP头中的Referer字段记录该请求的来源地址。比如访问http://bank.example/withdraw?account=Bob&amount=100000&to=Hack，用户必须先登录http://bank.example,然后通过该网站页面的转账按钮来触发转账事件。这时，该转账请求的Referer值就会是转账按钮所在页面的URL,通常以bank.example域名开头的地址。
而如果黑客要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过黑客的网站发送请求到银行网站时，该请求的Referer是指向黑客自己的网站。
因此要防御CSRF攻击，银行只需要对转账请求验证其Referer值，如果以bank.example开头的域名，则说明该请求是来自银行网站自己的请求，是合法的，如果Referer是其他网站的话，则有可能是黑客的CSRF攻击，拒绝该请求。
优点： 简单易行，只需要在最后给所有敏感的请求统一增加一个拦截器来检查Referer的值就可以。特别对于当前现有的系统，不需要改变当前系统已有代码，没有风险，简单便捷
缺点： 这种方法并非万无一失 。首先，Referer的值是由浏览器提供的，但是每个浏览器对不Referer的具体实现会有差别，并不能保证浏览器自身没有安全漏洞。验证Referer的值，把安全性都依赖于浏览器来保障，不安全。而已已有一些方法可以篡改Referer值。另外，用户会因为隐私问题，设置浏览器不允许发送Referer值,这样服务端的Referer验证就没有了意义
在请求地址中添加token并验证
CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户的 cookie来通过安全验证。
要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 中。
可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有 token或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求
这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的token 进行比对。
对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue 。
而对于 POST 请求，要在 form 表单加上：
<input type=”hidden” name=”csrftoken” value=”tokenvalue”/>
该方法也有一个缺点是难以保证 token 本身的安全。
因为即使是 POST 请求的 token，黑客的网站也同样可以通过 Referer 的值来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。
如果想保证 token 本身的安全，可以考虑使用动态 token，也就是每次请求都使用不同的动态 token。
在 HTTP 头中自定义属性并验证
这种方法也是使用 token 进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到HTTP 头中自定义的属性里。
通过 XMLHttpRequest 对象，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。
通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
然而，这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 对页面局部的异步刷新。
并非所有的请求都适合用 Ajax 来发起，而且通过该类请求得到的页面不能被浏览器所记录，影响前进、后退、刷新、收藏等操作，给用户带来了不便。
另外，对于没有进行 CSRF 防护的旧系统来说，如果采用这种方法来进行防护，需要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，工作量无疑是巨大的
