伪造一个请求，达到某种目的。
- 浏览器的 Cookie 策略，包含 “Session Cookie”（临时 Cookie） 和 “Third-party Cookie”（本地 Cookie），Session Cookie 在浏览器关闭后失效，Third-party Cookie 在过了设置的 Expire 时间后失效。
如果浏览器要跨域请求资源，由于安全原因，某些浏览器会阻止 Thrid-party Cookie 的发送。 - P3P 头的存在，使 CSRF 能在 <iframe> 等标签里发送 Cookie。
- CSRF 攻击能够通过 GET 请求发起，但是也可以通过自动提交表单而通过 POST 请求发起。
CSRF 的防御：
- 验证码：
CSRF 的出现，是因为在用户不知情的情况下构造了网络请求，验证码的出现，强迫用户跟机器交互，从而能很好的遏制 CSRF，但出于用户体验的考虑，网站不能给所有的操作加上验证码，所以，验证码只能是一种辅助手段。 - Referer Check
Referer Check 在互联网中最常见的应用就是“防止图片盗链”，Referer Check 被用于检查请求来自合法的“源”。
Rerferer Check 的缺陷在于：服务器并非任何时候都能取到 Rerferer。出于隐私的保护，出于安全的考虑，浏览器会限制 Rerferer 的发送。比如从一个https页面上的链接访问到一个非加密的http页面的时候，在http页面上是检查不到HTTP Referer的。Referer 容易被用户改变。 - Anti CSRF Token
CSRF 出现的原因是由于重要操作的所有参数都可以被攻击者猜到 ，利用 URL 的所有参数和参数值伪造请求。一个解决办法是把所有参数加密，让其不可预测，代价是对用户不友好，有些需要明文分析的参数变的不可读，这样的做法太极端。
CSRF 主流防御方式是在后端生成表单的时候生成一串随机 token ，内置到表单里成为一个字段，同时，将此串 token 置入 session 中。每次表单提交到后端时都会检查这两个值是否一致，以此来判断此次表单提交是否是可信的。提交过一次之后，如果这个页面没有生成 CSRF token ，那么 token 将会被清空，如果有新的需求，那么 token 会被更新。
攻击者可以伪造 POST 表单提交，但是他没有后端生成的内置于表单的 token，session 中有没有 token 都无济于事。
token 应放在表单里，如果放在 URL 里，则可能通过 Referer 的方式泄露。
CSRF 的 Token 仅仅用于对抗 CSRF 攻击。当网站还存在 XSS 漏洞时，这个方案会失效，因为 XSS 可以模仿客户端浏览器执行任意操作。在 XSS 攻击下，攻击者完全可以请求页面后，读出页面内容里的 Token 值，然后再构造一个合法的请求。这个过程被称为 XSRF。
