laravel 跨站请求伪造攻击防御
背景
最近公司安全部对我负责的web模板进行了安全测试，提出了很多安全问题，里面有一项是跨站攻击，优先级比较高，因此对这种攻击方式进行了研究。我们的使用的laravel框架，因此最后的解决方案是用php写的，其他语言可以自己实现下，原理一样。
一、CSRF攻击原理
英文名称：Cross-site request forgery 中文名称：跨站请求伪造 缩写：csrf/xcsrf。简单说就是是用户登录目标网站后，诱骗用户点击攻击界面，然后伪造用户请求，实现攻击。
简易转账的攻击例子：
image.png
说明：
访问A网站后，没有退出的情况下cookie会被保留。步骤4中请求A网站，通过修改转账用户和金额，会重新提交转账请求，由于cookie未过期，转账成功。
二、攻击模拟
开发防御代码，必须要在模拟攻击方式，这里有个神器burpsuit
1.proxy->intercept 设置为 is off
image.png
2.设置代理
image.png
3.设置搜狐浏览器（chrome也可以，需要安全插件）
image.png
image.png
4.找到常规-》网络设置-》手动配置代理，与burpsuit中的一致
image.png
image.png
点击test in browser，如果在浏览器中请求成功了说明存在csrf漏洞
三、伪造的网站能获取哪些信息
image.png
- 转账链接。通过charles抓包可以获取
- 请求方法和参数名：post和get
这些是攻击的前提，在生成广告链接G之前这些是提前准备好的。 -
无法获取到信息：cookie。
这里简单说下 浏览器同源策略
官方文档 https://tools.ietf.org/html/rfc6454，这里说明了必须
scheme, host和 port必须完全一致才是同源，同源才可以访问cookie等信息。为了举例，下面的表格给出了与URLhttp://www.example.com/dir/page.html"的对比。
Screen Shot 2019-03-28 at 12.10.22 AM.png
四、防御方案
1、添加验证码
这种方式可以防止csrf攻击，但是成本高。一般是用在登录、短信等不频繁的操作界面。
2、验证http的refer
http的refer显示了网站的来源，但是http refer可以被关闭，不能保证可以获取到（例如IE）
3、token验证
原理：既然网站B不能访问到网站A的cookie，那么我们可以在请求中添加cookie的token进行安全校验。
具体操作是：服务端生成token放在cookie中，user 访问A网站都要带上公共参数token，token来自cookie，服务端校验token和session中的token是否一致，不一致则是非法操作。
前后端分离情况下示例代码：
<?php
namespace App\Http\Middleware;
use Illuminate\Cookie\Middleware\EncryptCookies as Middleware;
class EncryptCookies extends Middleware
{
/**
* The names of the cookies that should not be encrypted.
*
* @var array
*/
protected $except = [
'XSRF-TOKEN',
];
}
这个是laravel的cookie加密中间件，为了使用方便移除token的加密（官网未加密token是放在html中的），显然没必要加密
前端代码：
var token = getCookie("XSRF-TOKEN")
$.ajax({
//几个参数需要注意一下
type: "POST",//方法类型
dataType: "json",//预期服务器返回的数据类型
url: "/transfer" ,//url
headers:
{
"X-CSRF-TOKEN": token
},
data: $('#Form').serialize(),
success: function (result) {
window.location = '[http://test.com:8000/success](http://test.com:8000/success)'
console.log(result);//打印服务端返回的数据(调试用)
},
error : function() {
alert("异常！");
}
});
再次用burpsuit测试，发现页面已不能访问成功。
csrf防御成功！
4、jwt 方式登录和授权
一般攻击的地方都是需要登录验证的，因此可以在登录验证方式上进行防御。
image.png
- 客户端使用账户密码请求登录接口
- 登录成功后服务器使用签名密钥生成JWT ,然后返回JWT给客户端
- 客户端再次向服务端请求其他接口时带上JWT
- 服务端接收到JWT后验证签名的有效性.对客户端做出相应的响应
token是存在客服端的，可以是cookie或者localstorage等。客户端请求服务端一般会把token放在header中，这就天然的防止了跨域攻击。jwt的具体使用可以参考这篇文章。如果项目还没开始，建议使用使用这种方式进行登录授权，而且方便后期sso。
