TLS中的加密套件、CSRF
文章目录
- 一、加密套件长啥样？
- 二、CSRF 跨站请求伪造攻击
一、加密套件长啥样？
大概就是这样：TLS_ECDH_RSA_WITH_AES_256_GCM_SHA256
| 选项名称 | 解释 | 推荐使用 |
|---|---|---|
| TLS | 使用TLS协议 | TLS1.2、TLS1.3及以上 |
| ECDH | 秘钥协商算法，客户端和服务端进行秘钥协商时候使用的算法 | DH、ECDH |
| RSA | 身份认证算法，表示后面传输过来的证书的公钥用的是RSA算法，通信的过程中需要签名的地方也用RSA，签名时候的摘要值由最后的sha256生成 | RSA2048及以上、DSA、ECDSA |
| AES_256_GCM | 对称加密AES256的GCM模式，用于加密握手后传输的数据，其加密秘钥由前面的ECDH协商生成 | AES256及以上，模式使用GCM |
| SHA256 | 数据摘要算法，表示后面交换的证书里签名用到的摘要算法是sha256，并且后续通信过程中需要用到数据校验的地方也是用的这个算法 | sha2及以上 |
二、CSRF 跨站请求伪造攻击
跨站请求伪造攻击，最容易和XSS相混淆。
从这个名称着手进行理解
解释之前先引入几个约定：
一、网站A：用户正在浏览的正规的官方网站A，后台服务AService
二、用户：正在浏览网站A的用户
三、网站B：带有CSRF攻击脚本的网站B
四、用户在未退出网站A的时候，打开了网站B，并点击了恶意的链接、图片或者提交了恶意表达之类的
跨站：意思是要跨越网站进行攻击。就像上面说的，在网站B，攻击网站A的服务。（受害者是用户）
请求伪造：网站B伪造用户合法的请求，发送请求到网站A的服务，进行攻击A的服务。（受害者是用户）
那他怎么伪造用户的合法请求呢？
伪造请求的前提：
- 一、网站A的接口和参数
要知道请求的接口和请求的参数，然后一般可以通过一个URL、恶意表单等实现恶意数据的构造。
- 二、当前用户的认证凭据
既然是伪装成当前用户进行合法请求，那就得拿到这个用户在网站A的身份，即，当前用户在网站A的cookie，cookie中包含了认证凭据，以及一些重要参数，这个就是用户在网站A的身份凭据。
那他怎么获取用户的认证凭据进行攻击呢？
前提：用户在未退出网站A的时候，打开了网站B，并点击了恶意的链接、图片或者提交了恶意表达之类的
用户点击网站B的链接、图片、表单提交等操作，不知不觉就访问了网站A，这个时候由于当前浏览器有网站A给用户的cookie，此时网站B就会携带用户的cookie请求网站A，而网站A只认cookie，只要cookie合法的，就认为是当前用户自己的合法操作，就接受请求，然后就被攻击到了。
那怎么防御呢？
在请求头添加CsrfToken，这样在网站B请求网站A的时候，虽然能携带cookie，但是不能携带这个token。
网站A的服务每次接受数据的增、删、改请求时候，服务器都校验这个token值是否合法。
那我们怎么能防止恶意网站B构造出这个CsrfToken呢？
这个token要在服务器生成，需要使用【安全随机数+UID+认证凭据+失效时间】，用AES256/GCM进行加密生成。
即：CsrfToken = AES256.encrypt(安全随机数+UID+AT/SessionID+expireTime)
就算攻击者获取到了cookie，能获取到UID、AT/SessionID、失效时间，但是他构造不出相同的安全随机数，以及没有加密的秘钥，他就无法构造出相同的CsrfToken，就无法进行攻击了。
CsrfToken校验逻辑 ：
1、服务器校验CsrfToken的时候，从请求头中获取是空的，就认为是非法的请求；
2、校验的时候，先经过秘钥进行解密，得到用户UID、SessionID、失效时间；
3、根据失效时间判断这个CsrfToken是否失效；
4、根据UID、AT/SeesionID判断是否是当前用户；
注意：也可以生成JWT类型的，但是核心就是，CsrfToken需要用服务器端的秘钥加密，要设置失效时间、要加用户ID或者认证凭据，把这一坨混一起才安全。