问题定位：后台两个接口重命，走了优先级更高的接口，接口没有过滤CSRF；
一、csrf是什么
CSRF（Cross-site request forgery）跨站请求伪造，是一种常见的web安全漏洞，概括地说就是指，攻击者通过浏览器保存的Cookie盗用了你的身份，以你的名义给某个网站发送恶意请求，这些恶意请求包括但不限于发邮件、修改账户信息、购买商品、转账等等，如果这个网站没有防御csrf攻击的话，那么这些恶意请求可能会请求成功，从而泄露了个人的隐私安全和财产安全。怎么样，听着够严重吧。
二、csrf的原理
下面我们通过一张图来简述下攻击的原理。
所以，当你在不登出受信网站（即cookie依然有效）的情况下，访问了恶意网站，那么就有可能发生csrf攻击。
有人也许会说，我从不访问恶意网站。这里需要特别注意：这个恶意网站，也许会是一个有其他漏洞的受信网站，恶意攻击者也可能会以这个网站作为中间网站实施攻击。
三、了解常见的csrf攻击
了解了csrf的原理，我们就来看下常见的csrf攻击的例子。
1.GET类型的CSRF
比如，银行的转账假使使用GET方式来进行（当然现实生活中绝对不是这样，这里只是举个例子）：
http://bank.com/Transfer.php?accountId=1001&money=1000
那么现在，假使你还没有登出该银行网站，又新开了一个浏览器tab访问了恶意网站B，B网站的html中可能会有这样的代码：
在恶意网站B加载的时候，也许你什么也没看到，就是一个空白页面，但这个空白页面已经发出了转账的请求，结果你的短信来了，告知银行账号少了1000块。
2.POST类型的CSRF
银行刚刚让人损失了1000块，痛定思痛，要把重要的请求都由GET变为POST，于是，前端页面变成了这样：
accountId:
Money:
后台变成了这样：
if (isset($_REQUEST['accountId'] && isset($_REQUEST['money']))
{
transfer($_REQUEST['toBankId'], $_REQUEST['money']);
}
?>
好了，银行的代码变了，恶意网站的代码还没变，这时用户又带着银行的cookie访问了恶意网站，结果又收到了转账1000的短信。
这是怎么回事呢？问题出在$_REQUEST数组，应该用$_POST数组的。这也是为什么php代码中，当使用post提交时，一定要用$_POST的缘故。
那么，我改成了POST数组，这下总能防住了吧！
结果恶意网站也改了代码：
document.forms[0].submit();
就是一个自动提交的表单，可以再次让用户丢1000块钱。
四、如何防范csrf攻击
看来如果不做一些事情，这个csrf是防不住的。那作为web开发人员，有哪些防范措施呢？
1.首先，GET方式的csrf攻击最容易实现，所以，我们的关键操作应该只接受POST请求。
2.表单加验证码
CSRF攻击的过程中，往往是在用户不知情的情况下发送网络请求的。所以如果使用验证码，那么每次操作都需要用户进行互动，而自动提交的技术通常是猜不到验证码的，从而简单有效的防御了CSRF攻击。但是验证码不能滥用，因为会造成用户体验的下降，所以也只在注册、登录或者其他重要操作上加验证码。
3.检测Referer
所谓Referer，就是在一个网络请求头中的键值对，标示着目前的请求是从哪个页面过来的。服务器通过检查Referer的值，如果判断出Referer并非本站页面，而是一个外部站点的页面，那么我们就可以判断出这个请求是非法的。与此同时，我们也就检测到了一次csrf攻击。但是，服务器有时候并不能接收Referer值，所以单纯地只通过Referer来防御是不太合理的，它因此经常用于csrf的检测。
4.在重要请求中的每一个URL和所有的表单中添加token
目前主流的做法是使用Token抵御CSRF攻击。CSRF攻击成功的条件在于攻击者能够预测所有的参数从而构造出合法的请求，所以我们可以加大这个预测的难度，加入一些黑客不能伪造的信息。我们在提交表单时，保持原有参数不变，另外添加一个参数Token，该值可以是随机并且加密的，当提交表单时，客户端也同时提交这个token，然后由服务端验证，验证通过才是有效的请求，如果不通过就直接抛出403。
考虑下django中是怎么防止csrf攻击的：
django中使用专门的中间件来防止csrf攻击，具体的做法是，在需要进行csrf验证的表单中加入
{% csrf_token %}
这句代码，当加载表单时，服务端就会利用**以及其他随机值生成一个token，当提交该表单时，django会修改当前处理的请求，向表单中添加一个隐藏的表单字段:
这个token值一起被提交到了服务端去验证，从而防止了csrf攻击，因为如果是其他表单提交的这个请求，这个token是绝对无法验证通过的。