Https身份鉴权（小迪网络安全笔记~

附：完整笔记目录~
ps：本人小白，笔记均在个人理解基础上整理，若有错误欢迎指正！

5.2 Https&身份鉴权

引子：上一篇主要对Http数据包结构、内容做了介绍，本篇则聊聊Https、身份鉴权等技术。
Https
1. 概述
  由于Http报文在通信链路中明文传输，因此一旦报文被截获，任何人都可查看更改Http报文内容。而这一行为往往会造成许多安全隐患，如窃取受害者的登录凭证、使受害者访问恶意网页等。
  这也是我们所常说的中间人攻击，而Https则为解决该问题而出现，通过TLS加密协议，确保数据在传输时不会被第三方窃取且能对用户访问服务器身份进行验证。
2. Https数据包
  接下来展示通过WireShark嗅探到的Http/Https数据包。
3. Q&A
  Q1：既然Https数据包被加密，那为什么在浏览器&各抓包软件中都可以获取到Https数据包的实际内容呢？
  A1：这其实是基于TLS加密原理。简单来说通过TLS加密的报文内容，无论是客户端还是服务端在获取到报文时均需先使用证书进行解密才能得到原报文内容。我们的浏览器实际上已经提前将所需证书安装好了，而各抓包软件也同样内置了证书。
  Q2：那既然抓包软件内置了证书，已经可以拦截、解密Https数据包了，为什么我们本地也需要额外安装抓包软件的证书？
  A2：是因为Https数据包由抓包软件转发给用户本地，而证书不仅有解密TLS的功能，也能验证用户访问的服务器是否合法。若本地不安装抓包软件证书，则当Https报文由抓包软件转发给本地浏览器时，由于证书校验不上，浏览器会弹出安全告警且阻止解密。（当然，你要使用抓包软件自带浏览器则无该问题，因为其浏览器已经装好了对应证书。)
身份鉴权
引子：Https解决了Http报文在客户端和服务端之间安全传输的问题，而客户端自身仍会产生安全问题，如越权访问、敏感用户账号密码被爆破、身份被伪造等。因此产生了身份鉴权技术，其目的就是为了确认用户/系统在访问某一资源时，身份是否合法。下面则对常见的身份鉴权方式做一介绍。
Http基本鉴权
1. 概述：组合用户所输入的账户&密码，并进行base64编码。
2. 鉴权流程
  1. 请求一个受限内容。
  2. 客户端输入账户&密码，账户密码于前端被组合且进行base64编码。
  3. 服务端收到后，解码并验证账户密码是否正确。
3. 影响
  1. 对于用户：每一次访问新的受限内容时，无论是否跨域，都需重新输入账户&密码，很麻烦。
  2. 对于安全测试者：账户&密码就相当于明文传输，常规测试手法仍有效，如爆破、注入等。
    现如今也几乎不存在这种鉴权方式，放到这了解一下就行。
Session - Cookie
1. 概述：Session - Cookie为解决用户每次访问新受限页面时需重新登录问题。
2. 鉴权流程
  1. 请求一个受限内容，客户端输入账户&密码。
  2. 服务端收到后，基于用户输入生成Session并保存。
  3. 此时在服务端响应包中，响应头会存在一个Set-Cookie字段，其内容则为刚刚生成Session的唯一标识Session ID。
  4. 客户端收到后，会将Set-Cookie的值（Session ID）存储于本地浏览器Cookie中。
  5. 当客户端对同站不同页面内容进行访问时，其请求包请求头会携带Cookie。
  6. 服务端收到后，只需比对保存的Session和来自客户端Cookie中的Session ID，就能通过ID判断会话是否存在。若会话存在则证明客户端身份正确，无需客户端反复输入账户密码。
    补：我们常常会发现，发送给服务端的Cookie内容往往有很多，因为Cookie除了含有登录凭证外，还有一些个性化设置或其它要记录的数据等内容。
3. 影响
  1. 对于服务端：服务端需保存每个用户Session，且Session会过期（默认关闭浏览器后Session过期，当然服务端也可自定义过期时间），服务端需定期清理过期的Session，影响服务器性能。
  2. 对于安全测试者：一旦用户Cookie被窃取，且服务端Session并未过期。那攻击者就可以利用用户Cookie，实现用户登录、伪造用户操作等行为，这也是XSS、CSRF攻击的原理。
    补：基于Session - Cookie实现的攻击思路往往是窃取被保存至客户端本地的Cookie，但我们知道能实现身份认证的仅为Cookie中的Session ID，那Session ID可不可以被破解伪造呢？（emmm。。。来自小白的提问）
Token
1. 概述：工作机制&实现功能，与Session - Cookie类似，不过Token往往会携带完整的用户身份认证信息。
2. 鉴权流程
  1. 请求受限内容，客户端输入账户&密码。
  2. 服务端收到账户密码后，依据后端逻辑，生成加密后的Token，并返回给客户端。
  3. 客户端收到Token并将其保存至本地浏览器。（Token除了被保存到浏览器Cookie外，也可以被存储至localStorage、sessionStorage等。）
  4. 当客户端再次对受限内容请求时，请求包会默认携带Token。
  5. 服务端接收并验证Token是否有效，实现身份鉴权。
3. 影响
  1. 对于服务端：由于Token内已经携带用户的完整信息，相较于Session - Cookie，服务端要存储每一个用户的会话，Token则无需存储，服务端只需接收并验证即可。节约服务端性能。
  2. 对于安全测试者：Token往往在生成时会设置过期时间，一般过期时间较短。相较于Session - Cookie，更加安全。

JWT

概述：全称JSON Web Token，其实从名字就可以看出JWT也是Token鉴权的一种。
鉴权流程：同Token。

特征
由于JWT具有很明显的特征，因此在这里额外聊一下。
JWT的组成：Header . Payload . Signature（头部 . 载荷 . 签名）
Header：存储JWT的基本信息，如Token类型、签名算法等，并进行base64编码。给一个JWT的官方示例：

// Header经base64编码
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
// 解码后
{"alg": "HS256",// jwt签名算法"typ": "JWT"// token类型
}

Payload：存储JWT&用户的有效信息，如JWT过期时间、用户id、用户名等，并进行base64编码。同样是官方示例：

// Payload经base64编码
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
// 解码后
{"sub": "1234567890","name": "John Doe","iat": 1516239022
}
// 我们称：sub、name、iat这些字段为声明
// 其中sub、iat为JWT注册声明，而每一个注册声明都有其特定含义。

这里对JWT注册声明进行列举

字段名	含义
iss	签发者 (Issuer)，表示 JWT 的创建者或签发服务的标识。
sub	主题 (Subject)，表示 JWT 的主题，一般是用户的唯一标识符。
aud	受众 (Audience)，表示 JWT 的接收者，通常是应用程序的标识。
exp	过期时间 (Expiration Time)，表示 Token 的到期时间，单位为秒的时间戳。
nbf	生效时间 (Not Before)，表示 Token 的有效开始时间。在该时间之前，JWT 无效。
iat	签发时间 (Issued At)，表示 JWT 的签发时间。
jti	JWT ID，表示 Token 的唯一标识符，常用于避免重复使用 Token（防止重放攻击）。

Signature：验证JWT完整性，Signature计算方式：

Header记录的加密算法(base64UrlEncode(header) + "." + base64UrlEncode(payload),secrect// 密钥
)
// 官方示例的Signature
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

将这三部分通过 “.” 组合，构成完整的JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

了解其组成后，也就可以得出JWT特征：eyJxxxxxx.eyJxxxxxx.signature。

影响
1. 对于服务端：同Token。
2. 对于安全测试者：由于JWT前两part仅进行base64编码，则一旦JWT算法密钥被获取&爆破，则可实现伪造JWT。

OAuth
1. 概述：OAuth作为一个授权框架，允许用户在不暴露其凭证的情况下，授权第三方应用访问其在另一个服务提供商上的受保护资源。简单来说，使用OAuth，用户就可以在不向第三方泄露自己账户密码的情况下，使第三方应用实现部分资源访问。
  举个栗子：使用QQ登录百度，执行授权操作后，百度在未获取到QQ账户&密码的情况下 1. 实现了登录。2. 通过获取到的QQ账户信息创建了百度账户。
2. 授权流程
  注：由于OAuth2.0标准定义了四种授权方式，分别为授权码、隐藏式、密码式和客户端凭证。其中授权码方式是如今被应用最多的，因此本文仅介绍使用授权码方式的授权流程，如果想了解其余授权方式可参考：
  https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
  1. 在OAuth授权中共有三位角色，用户所属的客户端，用户所访问的第三方应用，第三方应用需要请求资源的服务端（在该服务端中又分别存在授权服务，资源服务）。
  2. 当客户端访问的第三方应用想要获取服务端的资源时，需先向服务端授权服务器备案并获取其给予的client_id & client_secrect。
  3. 随后客户端需为第三方应用向服务端授权服务器申请授权码，申请成功后服务端授权服务器将授权码转发给第三方应用。
```
# 授权码申请
/oauth/authorize?client_id=xxxx&response_type=code&scope=read&redirect_uri=http://"第三方"
# 其中reponse_type表示授权方式
# scope表示授权范围
# redirect_uri表示重定向地址，一般为第三方应用地址# 授权码申请成功后，随redircet_uri返回给第三方应用
http://"第三方"/callback?code=authorationcode
# 其中code值为授权码
```
  4. 第三方应用拿到授权码后，再向服务端授权服务器申请Token，申请成功后服务端将Token返回给第三方应用。由于Token仅在第三方应用与服务端之间传递，无法被用户窃取，更加安全。
```
# 第三方向授权服务器申请Token
/oauth/token?client_id=xxxx&client_secrect=xxxx&grant_type=authoration_code&code=authorationcode&redirect_uri=http://"第三方"/
# 其中grant_type为授权方式
# code为第三方应用获取的授权码# 申请成功后，授权服务器将token返回给第三方应用
```
  5. 随后第三方应用凭借token向服务端资源服务器获取资源。
3. 影响
  1. 对于服务端：解决了服务端在访问受限资源时的身份鉴权问题。
  2. 对于安全测试者：针对OAuth框架的安全问题留给后面来讨论吧，现在只需对其有基本认知即可。
    （ps：其实是我没见过）