关于csrf跨站请求伪造攻击原理,与csrftoken防范原理

csrf攻击的原理和过程

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

怎样防御CSRF

提交验证码
在表单中添加一个随机的数字或字母验证码。通过强制用户和应用进行交互。来有效地遏制CSRF攻击。
Referer Check
检查假设是非正常页面过来的请求，则极有可能是CSRF攻击。
token验证
- 在 HTTP 请求中以參数的形式添加一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，假设请求中没有token 或者 token 内容不对，则觉得可能是 CSRF 攻击而拒绝该请求。
- token须要足够随机
- 敏感的操作应该使用POST。而不是GET，以form表单的形式提交。能够避免token泄露。
在 HTTP 头中自己定义属性并验证

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

关于token#

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

关于跨域请求白名单

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

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

浏览器的同源策略

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

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

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

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

Copy

现在有一个网站：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满足同源策略后，可以在各页面之间进行数据的相互存取操作，这样就可以不用反复进行重复的数据请求操作，如登录权限，获取用户信息等等。