16、XSS——会话管理

文章目录

• 一、web会话管理概述
• • [1.1 会话管理](#1.1 会话管理)
  • [1.2 为什么需要会话管理？](#1.2 为什么需要会话管理？)
  • [1.3 常见的web应用会话管理的方式](#1.3 常见的web应用会话管理的方式)
• 二、会话管理方式
• • [2.1 基于server端的session的管理方式](#2.1 基于server端的session的管理方式)
  • [2.2 cookie-based的管理方式](#2.2 cookie-based的管理方式)
  • [2.3 token-based的管理方式](#2.3 token-based的管理方式)
• 三、安全问题

一、web会话管理概述

1.1 会话管理

在人机交互时，会话管理是保持用户的整个会话活动的互动与计算机系统跟踪过程。会话管理分类：桌面会话管理、浏览器会话管理、web服务器的会话管理。

1.2 为什么需要会话管理？

HTTP是一种无状态协议，一次请求结束，客户端与服务器的连接就会断开，服务器再次收到请求时，无法识别此次请求是哪个用户发过来的，需要重新建立连接。为了判断发送请求的用户，需要一种记录用户的方式，也就是web应用会话管理。

1.3 常见的web应用会话管理的方式

• 基于server端的session的管理方式
• cookie-based的管理方式
• token-based的管理方式

二、会话管理方式

2.1 基于server端的session的管理方式

在早期的web应用中，通常使用服务端session来管理用户的会话。

服务端session使用户第一次访问应用时，服务器就会创建的对象，代表用户的一次会话过程，可以用来存放数据。服务器为每一个session都分配一个唯一的session ID，以保证每个用户都有一个不用的session对象。

服务器在创建完session后，会把session ID通过cookie返回给用户所在的浏览器，这样当用户第二次及以后向服务器发送请求的时候，就会通过cookie把session ID传回给服务器，以便服务器能够根据session ID找到该用户对应的session对象。

session 通常设定有效时间，比如1小时。当时间失效后，服务器会销毁之前的session，并创建新的session返回用户。但是只要用户在失效时间内，有发送新的请求给服务器，通常服务器都会把他对应的session的有效时间根据当前的请求时间再重新刷新。

session在一开始并不具备会话管理的作用。它只有在用户登录认证成功之后，并且往session对象里面放入了用户登录成功的凭证，才能用来管理会话。管理会话的逻辑也很简单，只要拿到用户的session对象，看它里面有没有登录成功的凭证，就能判断这个用户是否已经登陆。当用户主动退出时，会把它的session对象里的登录凭证清掉。所以在用户登录前或退出后或者session对象失效时，肯定都是拿不到需要的登录凭证的。

session实现会话管理的流程图：

2.2 cookie-based的管理方式

session的管理方式会增加服务器的负担和架构的复杂性，所以后来就提出把用户的登录凭证直接存在客户端的方案，当用户登陆成功后，把登录凭证写到cookie里面，并给cookie设置有效期，后续请求直接验证存有登录凭证的cookie是否存在以及凭证是否有效，即可判断用户的登录状态。

> Cookie与Session最大的区别：

>- Cookie将数据存储在客户端

>- Session将数据存储在服务端

用户发起登录请求，服务端根据传入的用户密码之类的身份信息，验证用户是否满足登录条件，如果满足，就根据用户信息创建一个登录凭证，这个登陆凭证简单来说就是一个对象，最简单的形式可以只包含用户id、凭证创建时间和过期时间三个值。

服务端把上一步创建好的登陆凭证，先对它进行数字签名，然后再用对称加密算法做加密处理，将签名、加密后的字串，写入cookie。cookie的名字必须固定（如ticket），因为后面再获取的时候，还得根据这个名字来获取cookie值。这一步添加数字签名的目的时防止登录凭证里的信息被篡改，因为一旦信息被篡改，那么下一步做签名验证的时候肯定会失败。做加密的目的是，防止cookie一旦被别人截取的时候，无法轻易读取到其中的用户信息。

用户登录后发起后续请求，服务端会根据上一步存登录凭证的cookie名字，获取到相关的cookie值。然后先做解密处理，再做数字签名的认证，如果这两部都失败，说明这个登录凭证非法；如果这两步成功，接着就可以拿到原始存入的登录凭证了。然后用这个凭证的过期时间和当前时间做对比，判断凭证是否过期，如果过期，就需要用户再重新登录；如果未过期，则允许请求继续。

cookie实现会话管理的流程：

优点：

1. 实现了服务端的无状态化，服务端只需要负责创建和验证登录cookie即可，无需保持用户的登陆状态。

2. cookie可以跨越同域名下的多个网页，但不能跨越多个域名使用。

3. 可以设置有效期限，控制cookie的生命周期，使之不会永久有效。

缺点：

1. cookie有大小限制，存储不了太多数据。
2. 同样存在跨域问题（不同域名无法相互读取cookie）。

2.3 token-based的管理方式

Session和Cookie两种会话管理方式由于都要用到cookie，不适合用在native app里面，因为native app不是浏览器，不好管理cookie，因此都不适合做纯API服务的登录认证。是实现API服务的登录认证，就需要用到token-based的会话管理方式。

token-based的管理方式在流程上和实现上跟cookie-based的管理方式没有太多区别，只不过cookie-based的管理方式中写道cookie里面的ticket再这种方式下被称为token，这个token在返回给客户端后，后续请求都必须通过url参数或者http header的形式，主动带上token，这样服务端接收到请求后就能直接从http header或者url里面渠道token进行验证。

token实现会话管理的方式：

优点：

1. 支持跨域访问：cookie不支持跨域访问，token支持。
2. 无状态：Token无状态，session有状态（有状态和无状态的最大区别就是服务端会不会保存客户端的信息）。
3. 支持移动设备：Token更适合移动应用，cookie不支持手机端访问。

缺点：

4. 占带宽：正常情况下Token要比session id更大，需要消耗更多的流量，挤占更多的带宽。'

5. 无法在服务端注销，很难解决劫持问题。

三、安全问题

在web应用里，会话管理的安全性始终是最重要的安全问题，对用户的影响极大。

从会话管理凭证来说，session会话管理的会话凭证仅仅是一个session ID，所以只要这个session ID足够随机，那么攻击者就不会轻易地冒充别人的session ID进行操作；cookie会话管理的凭证（ticket）以及Token会话管理凭证（token）都是一个在服务端做了数字签名和加密处理的串，只要密钥不泄露，攻击者也无法轻易拿到这个串中有效信息并对它进行篡改。总之，这三种会话管理方式的凭证本身是比较安全的。

从客户端和服务端的HTTP过程来说，当攻击者截获到客户端请求中的会话凭证，就能拿到这个凭证冒充原用户，做一些非法操作，而服务器也认不出来。这种安全问题，可以简单采用HTTPS来解决。