前端安全系列之登录那些事

一、Cookie与Session

HTTP是无状态协议，它不对之前发生过的请求和响应的状态进行保存。因为无法管理用户状态，对于要登录的页面，每次跳转新页面时都需要再次登录。

于是引入了Cookie来管理用户状态：

① 首先客户端发起不带Cookie信息的登录请求

② 服务端接收到请求，验证用户数据正确后，添加响应头Set-Cookie

③ 客户端收到响应报文后，检查到响应头Set-Cookie，在本地保存Cookie

④ 之后每次向该域发起请求时，自动添加请求头Cookie，发送给服务端

⑤ 服务端获取请求头Cookie，根据Cookie的值，就可以判断出用户是否登录

但是Cookie极容易被篡改和伪造，于是产生了Session，Session将用户信息保存在服务端，那么Session是如何管理用户状态的呢？

① 首先客户端发起不带Cookie信息的登录请求

② 服务端接收到请求，检查到没有携带口令，验证用户密码正确后生成Session，将用户信息保存在Session，设置响应头Set-Cookie，通常是将Session ID作为口令值

③ 客户端检查到Set-Cookie响应头，在本地保存Cookie信息

④ 之后每次发起请求时，自动在请求头Cookie中携带口令，发送给服务端

⑤ 服务端获取Cookie携带的口令值，找到对应的Session，就可以判断用户状态

二、如何让Session口令值更安全

虽然口令值由服务端生成，用户不容易伪造，But nothing is impossible；而且口令值存在客户端，就有可能被盗用。一旦口令值被伪造或盗用，攻击者就可以伪装成用户访问服务端的数据。

那么如何让Session口令值更安全呢？

① 将客户端的某些独有信息+口令值作为原值，对其进行签名

② 将口令值拼接签名返回给客户端，将Cookie设置为HttpOnly（禁止用户通过脚本来获取和更改Cookie）

③ 服务端再次收到请求，取客户端信息与口令值签名，与客户端携带的签名对比，不相等，说明请求不合法

这样的话：

① 即使攻击者知道了口令值，由于不知道密钥，无法伪造签名

② 即使攻击者通过某种方式得到了真实的口令值和签名，但是由于攻击者的客户端信息不一样，发送到服务端后，会得到不一样的签名，签名校验不能通过

三、多系统的复杂性

web系统由早期的单系统发展成多系统组成的应用