受害者 Bob 在银行有一笔存款，经由过程对银行的网站发送请求 http://bank.example/withdraw?… 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。一般情况下，该请求发送到网站后，服务器会先考证该请求是不是来自一个正当的 session，而且该 session 的用户 Bob 已胜利上岸。
黑客 Mallory 自身在该银行也有账户，他晓得上文中的 URL 可以把钱举行转帐操纵。Mallory 可以自身发送一个请求给银行：http://bank.example/withdraw?…。然则这个请求来自 Mallory 而非 Bob，他不能经由过程平安认证，因而该请求不会起作用。
这时刻，Mallory 想到运用 CSRF 的进击方式，他先自身做一个网站，在网站中放入以下代码： src=”http://bank.example/withdraw?… ”，而且经由过程广告等诱使 Bob 来接见他的网站。当 Bob 接见该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一同发向银行服务器。大多数情况下，该请求会失利，因为他请求 Bob 的认证信息。然则，假如 Bob 当时碰巧刚接见他的银行后不久，他的浏览器与银行网站之间的 session 还没有逾期，浏览器的 cookie 当中含有 Bob 的认证信息。这时刻，悲剧发生了，这个 url 请求就会获得相应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时绝不知情。等今后 Bob 发明账户钱少了，纵然他去银行查询日记，他也只能发明白切有一个来自于他本人的正当请求转移了资金，没有任何被进击的陈迹。而 Mallory 则可以拿到钱后逃出法网。
防备CSRF进击：
现在防备 CSRF 进击主要有三种战略：
考证 HTTP Referer 字段；
在请求地点中增添 token 并考证；
在 HTTP 头中自定义属性并考证。
（1）考证 HTTP Referer 字段
依据 HTTP 协定，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的泉源地点。在一般情况下，接见一个平安受限页面的请求来自于同一个网站，比方须要接见 http://bank.example/withdraw?…，用户必须先上岸 bank.example，然后经由过程点击页面上的按钮来触发转账事宜。这时刻，该转帐请求的 Referer 值就会是转账按钮地点的页面的 URL，一般是以 bank.example 域名开首的地点。而假如黑客要对银行网站实行 CSRF 进击，他只能在他自身的网站构造请求，当用户经由过程黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自身的网站。因而，要防备 CSRF 进击，银行网站只须要关于每一个转账请求考证其 Referer 值，假如是以 bank.example 开首的域名，则申明该请求是来自银行网站自身的请求，是正当的。假如 Referer 是其他网站的话，则有多是黑客的 CSRF 进击，谢绝该请求。
这类要领的不言而喻的优点就是简单易行，网站的一般开发人员不须要费心 CSRF 的破绽，只须要在末了给一切平安敏感的请求一致增添一个拦截器来搜检 Referer 的值就可以。特别是关于当前现有的体系，不须要转变当前体系的任何已有代码和逻辑，没有风险，异常便利。
但是，这类要领并不是十拿九稳。Referer 的值是由浏览器供应的，虽然 HTTP 协定上有明白的请求，然则每一个浏览器关于 Referer 的详细完成可能有差异，并不能保证浏览器自身没有平安破绽。运用考证 Referer 值的要领，就是把平安性都依赖于第三方（即浏览器）来保证，从理论上来讲，如许并不平安。事实上，关于某些浏览器，比方 IE6 或 FF2，现在已有一些要领可以改动 Referer 值。假如 bank.example 网站支撑 IE6 浏览器，黑客完整可以把用户浏览器的 Referer 值设为以 bank.example 域名开首的地点，如许就可以经由过程考证，从而举行 CSRF 进击。
即便是运用最新的浏览器，黑客没法改动 Referer 值，这类要领依然有题目。因为 Referer 值会记录下用户的接见泉源，有些用户以为如许会侵犯到他们自身的隐私权，特别是有些构造忧郁 Referer 值会把构造内网中的某些信息泄漏到外网中。因而，用户自身可以设置浏览器使其在发送请求时不再供应 Referer。当他们一般接见银行网站时，网站会因为请求没有 Referer 值而以为是 CSRF 进击，谢绝正当用户的接见。
（2）在请求地点中增添 token 并考证
CSRF 进击之所以可以胜利，是因为黑客可以完整捏造用户的请求，该请求中一切的用户考证信息都是存在于 cookie 中，因而黑客可以在不晓得这些考证信息的情况下直接应用用户自身的 cookie 来经由过程平安考证。要抵抗 CSRF，关键在于在请求中放入黑客所不能捏造的信息，而且该信息不存在于 cookie 当中。可以在 HTTP 请求中以参数的情势到场一个随机发生的 token，并在服务器端竖立一个拦截器来考证这个 token，假如请求中没有 token 或许 token 内容不正确，则以为多是 CSRF 进击而谢绝该请求。
这类要领要比搜检 Referer 要平安一些，token 可以在用户上岸后发生并放于 session 当中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 举行比对，但这类要领的难点在于怎样把 token 以参数的情势到场请求。关于 GET 请求，token 将附在请求地点以后，如许 URL 就变成 http://url?csrftoken=tokenvalue。 而关于 POST 请求来讲，要在 form 的末了加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>，如许就把 token 以参数的情势到场请求了。然则，在一个网站中，可以接收请求的处所异常多，要关于每一个请求都加上 token 是很贫苦的，而且很轻易遗漏，一般运用的要领就是在每次页面加载时，运用 JavaScript 遍历全部 dom 树，关于 dom 中一切的 a 和 form 标签后到场 token。如许可以处理大部分的请求，然则关于在页面加载以后动态天生的 html 代码，这类要领就没有作用，还须要程序员在编码时手动增添 token。
该要领另有一个瑕玷是难以保证 token 自身的平安。特别是在一些论坛之类支撑用户自身宣布内容的网站，黑客可以在上面宣布自身个人网站的地点。因为体系也会在这个地点背面加上 token，黑客可以在自身的网站上获得这个 token，并立时就可以提议 CSRF 进击。为了防止这一点，体系可以在增添 token 的时刻增添一个推断，假如这个链接是链到自身本站的，就在背面增添 token，假如是通向外网则不加。不过，纵然这个 csrftoken 不以参数的情势附加在请求当中，黑客的网站也一样可以经由过程 Referer 来获得这个 token 值以提议 CSRF 进击。这也是一些用户喜好手动封闭浏览器 Referer 功用的缘由。
（3）在 HTTP 头中自定义属性并考证
这类要领也是运用 token 并举行考证，和上一种要领差别的是，这里并不是把 token 以参数的情势置于 HTTP 请求当中，而是把它放到 HTTP 头中自定义的属性里。经由过程 XMLHttpRequest 这个类，可以一次性给一切该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入个中。如许处理了上种要领在请求中到场 token 的不方便，同时，经由过程 XMLHttpRequest 请求的地点不会被记录到浏览器的地点栏，也不必忧郁 token 会透过 Referer 泄漏到其他网站中去。
但是这类要领的局限性异常大。XMLHttpRequest 请求一般用于 Ajax 要领中关于页面部分的异步革新，并不是一切的请求都适合用这个类来提议，而且经由过程该类请求获得的页面不能被浏览器所记录下，从而举行行进，退却，革新，珍藏等操纵，给用户带来不方便。别的，关于没有举行 CSRF 防护的遗留体系来讲，要采纳这类要领来举行防护，要把一切请求都改成 XMLHttpRequest 请求，如许几乎是要重写全部网站，这价值无疑是不能接收的。
