csrf和xss攻击-以及各类项目的安全防护措施

csrf和xss攻击-以及各类项目的安全防护措施

起因

我最近在搞一个项目验收，然后验收标准是通过渗透测试，里面几个重要的指标就是防范csrf攻击和xss攻击。

了解

想防范先得了解什么是csrf攻击和xss攻击。

https://www.jianshu.com/p/344947705c3d

https://segmentfault.com/q/1010000014364239

https://www.jianshu.com/p/c69f08ca056d

https://blog.csdn.net/xiaomin1991222/article/details/84811272

https://blog.csdn.net/sdb5858874/article/details/81666194

https://www.cnblogs.com/zzwlong/p/13222943.html

以我的理解来说，就是在登录网站A后，如果用户没有退出网站A，这个时候用户访问了危险网站B，这个网站B获取能获取登录网站A的时候的cookie，这个时候网站B有个链接，诱使用户点击，这个链接是网站A的api，这个时候因为有cookie，导致这个操作是允许的，导致用户权益受损。

为什么一个cookie能导致用户信息泄漏呢。

这个时候需要我们先了解一下，我们服务是通过什么来确定用户是用户呢。

因为http是无状态的，也就是没特殊手段的话，服务器根本不知道这个连接是哪个用户，所谓的一视同仁，但这个就导致了权限有问题、

这个时候需要一个手段来区分客户。

这个时候，第一个方案出现了，

• 用户浏览器访问web网站，输入用户名密码
• 服务器校验用户名密码通过之后，生成sessonid并把sessionid和用户信息映射起来保存在服务器
• 服务器将生成的sessionid返回给用户浏览器，浏览器将sessionid存入cookie
• 此后用户对该网站发起的其他请求都将带上cookie中保存的sessionid
• 服务端把用户传过来的sessionid和保存在服务器的sessionid做对比，如果服务器中有该sessionid则代表身份验证成功

简单来说，就是用户发送请求给服务器登录后，后台生成对应的特殊标识，返回给前端，前端后续请求发送请求的时候，都带上这个特殊标识，然后后台通过维护的特殊标识对应用户的关系，得知这个用户是哪位。简单理解来说，一个cookie对应一个用户。

这个问题在哪里呢，因为这个cookie是存在浏览器端的，而这个时候，如果用户在没有退出我们的网站的时候，访问危险网站，然后危险网站也能获取cookie，而这个时候，用户被诱使点击我们的网站，那对我们网站来说，我们也只能认为是这个用户进行了操作，后续查看记录，也只能看到用户进行这个操作的记录。

还有一个登录方案是jwt

验证过程如下：

• 用户访问网站，输入账号密码登入
• 服务器校验通过，生成JWT，不保存JWT，直接返回给客户端
• 客户端将JWT存入cookie或者localStorage
• 此后用户发起的请求，都将使用js从cookie或者localStorage读取JWT放在http请求的header中，发给服务端
• 服务端获取header中的JWT，用base64URL算法解码各部分内容，并在服务端用同样的秘钥和算法生成signature，与传过来的signature对比，验证JWT是否合法

是不是差不太多，不过一个是服务端维护用户关系，一个是jwt自带用户信息。

你会不会觉得，这样是不是还是会csrf攻击呢？

https://segmentfault.com/q/1010000014364239

我比较倾向于第二个说法，csrf攻击的前提是因为浏览器默认带上cookie，而验证信息放在head的话，不通过js获取的话，是拿不到的。

第一种说法也对，利用referer或者csrf_token跟jwt是并不冲突的。

还有一种验证方案是，oauth2。

验证过程跟jwt差不多，不过是也模仿cookie。

验证过程如下：

• 用户访问网站，输入账号密码登入

• 服务器校验通过，生成Token，返回给客户端，服务端维护一个tokne和user的关系

• 客户端将token存入cookie或者localStorage

• 此后用户发起的请求，都将使用js从cookie或者localStorage读取tokne放在http请求的header中，发给服务端

• 服务端获取header中的token，获取对应的user。

  我觉得很像cookie

  如何抵御csrf攻击

  我们可以知道，csrf攻击的根源不过是浏览器自动携带上 Cookie 中的数据，那么就有两种思路了。

  一种是，对应沿用cookie的服务，是在前端请求中，添加一个随机数。主要针对非get请求。

  主要是因为默认有害操作基本是因为修改了服务器资源。

  有小伙伴可能会说放在 Cookie 中不是又被黑客网站盗用了吗？其实不会的，大家注意如下两个问题：

  黑客网站根本不知道你的 Cookie 里边存的啥，他也不需要知道，因为 CSRF 攻击是浏览器自动携带上 Cookie 中的数据的。 我们将服务端生成的随机数放在 Cookie 中，前端需要从 Cookie 中自己提取出来 csrf 参数，然后拼接成参数传递给后端，单纯的将 Cookie 中的数据传到服务端是没用的。 理解透了上面两点，你就会发现 _csrf 放在 Cookie 中是没有问题的，但是大家注意，配置的时候我们通过 withHttpOnlyFalse 方法获取了 CookieCsrfTokenRepository 的实例，该方法会设置 Cookie 中的 HttpOnly 属性为 false，也就是允许前端通过 js 操作 Cookie（否则你就没有办法获取到 _csrf）。

  总体流程是针对修改服务器资源的操作，前端页面隐藏一个参数，这个参数是前端从cookie里获取的，这样传递给后端。

  后端通过验证这个额外参数来确定是用户的正常操作还是csrf攻击。

  代码方面的话，要区分项目。

  如果老服务spring项目前后端不分离的话，页面能获取到对应的csrftoken，然后每个表单提交的页面，加上这个参数传递给后端。后端拦截也要验证，服务器进行csrf防御校验的时候，是拿用户http请求体中的cookie参数值和cookie中的csrftoken值进行比对。如果值一样了，操作才被允许执行。

  如果前后端分离的话，也就是说post请求是通过ajax来发送的话，

  需要js操作let _csrf = $.cookie(‘XSRF-TOKEN’);然后发送给后台。

  而加了springsecurity框架的话，主要配置就好。.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());其实工作就是如果是前后端不分离的项目，返回给页面的时候，也有csrf_token参数。还有个一个拦截器验证。cookie和csrf是否一致。

  你有没有发现，如果黑客能劫持cookie的话，不是一样有问题？

  其实，csrf利用是

  跨域的简单请求（GET POST，比如img标签的src，form表单的action提交）浏览器是会自动携带cookie的，所以通过黑客网站发起的跨域请求，浏览器会带着cookie请求到被攻击网站。这个csrf_token的判断方式是，需要用户的request的头部或者请求参数里带着这个csrf_token，cookie里也会有（被攻击网站服务器生成的，在用户第一次请求通过setCookie设置到cookie里），服务端收到请求，对比request头或请求参数里的csrf_token和cookie里的token。所以如果你请求头或参数里没有token，服务器是校验不通过的。因为同源策略，黑客网站无法通过js获取cookie中的token，所以请求头或者参数里无法携带token，只有cookie里有token是没有用的。

​ 而黑客有没有办法可以操作cookie？ 有xss攻击，这个我的另一个文章也说过防护了。这里简单提下

XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。

因为只有js能操作cookie，而xss能执行恶意js，那么配合着自然也能拿到cookie，然后发送给后台，一样能骗过服务器。

所以，csrf防御的前提是做好了xss。

而我们的jwt和oauth协议的话，基本配置都会关闭csrf配置，因为你想，一开，post请求都要csrf_token。而我们现在认证信息放head里的，你没退出，浏览器不会自动带上head参数的，没啥必要。不过你非要加上refer验证的话，不拦着你。