关于CSRF 和 csrftoken

CSRF 虽然利用了session验证机制的漏洞，一般使用加密token的方式防御，但是其本身和session以及JWT token没有直接联系。

描述

CSRF利用用户正常登录产生的cookie，利用钓鱼网站传给用户发送一张有内容的表单，并携带用户的正常cookies访问网站，达到将伪造的表单通过用户之手传到网站上的目的。为了避免用户提交其他网站生成的表单，网站在用户登录时签发给用户一个csrftoken，该token不存放在cookie中（存放在浏览器的local storage中），由网站前端js调用（识别{{form.field_name}} ），在提交表单时需要携带该token从而验证该表单来自于本网站（服务器端的token验证数据存放在session中）。

CSRF攻击攻击原理及过程

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2. 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

怎样防御CSRF

1. 提交验证码
   在表单中添加一个随机的数字或字母验证码。通过强制用户和应用进行交互。来有效地遏制CSRF攻击。

2. Referer Check
   检查假设是非正常页面过来的请求，则极有可能是CSRF攻击。

3. token验证

   • 在 HTTP 请求中以參数的形式添加一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，假设请求中没有token 或者 token 内容不对，则觉得可能是 CSRF 攻击而拒绝该请求。
   • token须要足够随机
   • 敏感的操作应该使用POST。而不是GET，以form表单的形式提交。能够避免token泄露。

4. 在 HTTP 头中自己定义属性并验证

   这样的方法也是使用 token 并进行验证。这里并非把 token 以參数的形式置于 HTTP 请求之中，而是把它放到HTTP 头中自己定义的属性里。通过 XMLHttpRequest 这个类，能够一次性给全部该类请求加上 csrftoken 这 HTTP 头属性。并把 token 值放入当中。这样攻克了上种方法在请求中添加 token 的不便。同一时候，通过XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用操心 token 会透过 Referer 泄露到其它站点中去。

关于token

1. Token 应该被保存起来（放到 local / session stograge）
2. Token 除了像 cookie 一样有有效期，还需要能够有很多其它的操作方法。一旦 token 过期，仅仅需要又一次获取一个。你能够使用一个接口去刷新 token。你甚至能够把 token 原来的公布时间也保存起来。而且强制在两星期后又一次登录什么的。假设你须要撤回 tokens（当 token 的生存期比較长的时候这非常有必要）那么你须要一个 token 的生成管理器去作检查。
3. Local / session storage 不会跨域工作，请使用一个标记 cookie：基于浏览器的同源策略
4. 有须要的话，要加密而且签名 token
5. 将 JSON Web Tokens 应用到 OAuth 2

关于跨域请求白名单

django-cors扩展 django flask 或者其他扩展

1. 编写中间件，在中间件中拦截处理options
2. 判断请求方式是否是options，如果不是opitons，不做处理，进入视图执行，否则，按照下面的流程处理
3. 从options请求中取出访问域名，与白名单中的允许域名对比，
4. 如果在白名单中，则返回允许跨域访问，否则返回不允许

浏览器的同源策略

同源策略（Same origin policy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。说简单点，同源策略就是浏览器本身的一种特殊属性，浏览器在访问资源时会在同源策略约束下，避免不同的站点相互之间轻易的获取信息。

所谓同源是指，域名，协议，端口相同。当一个浏览器的两个tab页中分别打开百度和谷歌的页面。浏览器的百度tab页执行脚本的时候会检查这个脚本是属于哪个页面的，即检查是否同源，只有和百度同源的脚本才会被执行。 如果非同源，那么在请求数据时，浏览器会在控制台中报一个异常，提示拒绝访问。

我们知道，浏览器是以HTTP请求模式获取请求资源，如：Http://www.baidu.com:8080/xxxx。 其中HTTP是请求协议，www.baidu.com 是域名，8080是端口号，请求的意思是 使用HTTP协议模式，从域名为 www.baidu.com 的服务器上8080端口部署的服务下请求资源XXXX。

那么当协议，域名，端口不相同时，即为不同源。

现在有一个网站：http://www.a.com/a。

https://www.a.com/a          ：不同源，协议不同，此处协议是https！

http://www.b.com/a           ：不同源，域名不同

http://www.a.com:8080/a      ：不同源，端口不同

http://www.a.com/b           ：同源

综上，跨域就是请求路径的url不同源。

可参考文档：https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy

session，localStorage，sessionStorage, cookies存储机制的区别

localStorage、sessionStorage、cookies都可以用来在浏览器进行数据的缓存存储。

sessionStorage、cookies这两个存储随着关闭浏览器或者停止对服务器的访问而会消失，并不会永久的存在。

localStorage不会通过这种方式清除，只有当用户手动清除浏览器缓存才能真正的清除掉数据。

session不是用来存储在客户端，而是存储在服务器端。cookies中会保存一个sessionID，以便用户的身份验证。

在以前，这些缓存存储都是由 cookies 完成的。但是cookies不适合大数据量的存储，它们由每个对服务器的请求来传递，这使得 cookie 速度很慢而且效率也不高。

在 HTML5 中，数据不是由每个服务器请求传递的，而是只有在请求时使用数据。它使在不影响网站性能的情况下存储大量数据成为可能。对于不同的网站，数据存储于不同的区域，并且一个网站只能访问其自身的数据。

即当浏览器打开的tab满足同源策略后，可以在各页面之间进行数据的相互存取操作，这样就可以不用反复进行重复的数据请求操作，如登录权限，获取用户信息等等。

相关阅读：

关于 Token，你应该知道的十件事

session，localStorage，sessionStorage,cookies和跨域问题