session的用法与cooke区别和CSRF攻击方案[偏理论]
1.Cookie
1.1 HTTP短连接是什么
短链接:不会记录之前的状态,当前通话结束就断开连接,不会记录状态,下次访问时要重新建立连接
长链接:当前通话结束后不会立马断开连接,在一定时间内再次连接会记录状态
在HTTP/1.0中,默认使用的是短连接。也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源,如JavaScript文件、图像文件、CSS文件等;当浏览器每遇到这样一个Web资源,就会建立一个HTTP会话
1.2状态保持
Cookie及
Session一直以来都是Web开发中非常关键的一环,因为
HTTP协议本身为无状态,每一次请求之间没有任何状态信息保持,往往我们的Web服务无法在客户端访问过程中得知用户的一些状态信息,比如是否登录等等;那么这里通过引入
Cookie或者
Seesion`来解决这个问题
1.3什么是COOKIE
当客户端访问时,服务端会为客户端生成一个Cookie
键值对数据,通过Response
响应给到客户端。当下一次客户端继续访问相同的服务端时,浏览器客户端就会将这个Cookie
值连带发送到服务端
Cookie
值存储在浏览器下,一般在你的浏览器安装目录的Cookie
目录下,我们也可以通过F12或者各种浏览器的开发者工具来获取到
因为cookie
是保存在浏览器中的一个纯明文字符串,所以一般来说服务端在生成cookie
值时不建议存储敏感信息比如密码
1.4设置COOKIE
from django.shortcuts import render,HttpResponse
# Create your views here.
def set_cookie(request):
# 在HTTPResponse部分设置COOKIE值
cookie_reponse = HttpResponse('这是一个关于cookie的测试')
cookie_reponse.set_cookie('test','cookie')
return cookie_reponse
2.Session
2.1Session的原理
虽然说有了Cookie
之后,我们把一些信息保存在客户端浏览器中,可以保持用户在访问站点时的状态,但是也存在一定的安全隐患,Cookie
值被曝露,Cookie
值被他人篡改,等等。我们将换一种更健全的方式,也就是接下来要说的Session
。
Session
在网络中,又称会话控制,简称会话。用以存储用户访问站点时所需的信息及配置属性。当用户在我们的Web
服务中跳转时,存储在Session
中的数据不会丢失,可以一直在整个会话过程中存活。
2.2框架是如何存储管理Session的
在
django
中,默认的Session
存储在数据库中session
表里。默认有效期为两个星期**。
session创建流程
- 客户端访问服务端,服务端为每一个客户端返回一个唯一的
sessionid
,比如xxx
。 - 客户端需要保持某些状态,比如维持登陆。那么服务端会构造一个
{sessionid: xxx }
类似这样的字典数据加到Cookie
中发送给用户。注意此时,只是一个随机字符串,返回给客户端的内容并不会像之前一样包含实际数据。 - 服务端在后台把返回给客户端的
xxx
字符串作为key
值,对应需要保存的服务端数据为一个新的字典,存储在服务器上,例如:{xxx : {id:1}}
**
注意:补充说明,默认存储在数据库的Session
数据,是通过base64
编码的,我们可以通过Python
的base64
模块下的b64decode()
解码得到原始数据
2.3框架如何操作Session
当settings.py
中SessionMiddleware
激活后
在视图函数的参数request
接收到的客户端发来的HttpResquest
请求对象中都会含有一个session
属性
这个属性和之前所讨论的Cookie
类似,是一个类字典对象,首先支持如下常用字典内置属性
2.4获取Session
session_data = request.session.get(Key)
session_data = request.session[Key]
```在Session
中获取对应值,get
方法获取时,如不存在该Key
值,不会引发异常,返回None
而第二种直接通过get方法获取,如Key
值不存在,引发KeyErro
3.Csrf
3.1什么是CSRF
CSRF(Cross-site request forgery):跨站请求伪造。
标题3.2 CSRF攻击模拟实现
用户是网站 A 的注册用户,且登录进去,于是网站 A 就给用户下发 cookie。
从上图可以看出,要完成一次 CSRF 攻击,受害者必须满足两个必要的条件:
(1)登录受信任网站 A,并在本地生成 Cookie。(如果用户没有登录网站 A,那么网站 B 在诱导的时候,请求网站 A 的 api 接口时,会提示你登录)
(2)在不登出 A 的情况下,访问危险网站 B(其实是利用了网站 A 的漏洞)。
我们在讲 CSRF 时,一定要把上面的两点说清楚。
温馨提示一下,cookie 保证了用户可以处于登录状态,但网站 B 其实拿不到 cookie。
3.3 如何防止CSRF攻击
讨论 GET 和 POST 两种请求,对于 GET,其实也没什么需要防范的。为什么?
因为 GET 在 “约定” 当中,被认为是查询操作,查询的意思就是,你查一次,查两次,无数次,结果都不会改变(用户得到的数据可能会变),这不会对数据库造成任何影响,所以不需要加其他额外的参数。
所以这里要提醒各位的是,尽量遵从这些约定,不要在 GET 请求中出现 /delete, /update, /edit 这种单词。把 “写” 操作放到 POST 中。
对于 POST,服务端在创建表单的时候可以加一个隐藏字段,也是通过某种加密算法得到的。在处理请求时,验证这个字段是否合法,如果合法就继续处理,否则就认为是恶意操作。