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是否一致，不一致则是非法操作。
前后端分离情况下示例代码：

这个是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。