身份认证与鉴权

数据安全，可以说是安全的终极防护目标。广义上来讲，大部分攻击行为（0 day漏洞、勒索病毒、钓鱼邮件....），都和数据有关，从这个角度看，不论是传统的网络安全产品，还是数据安全产品，根本目的都是为了保护数据的安全。
数安全很重要，从国家近两年密集出台的法律法规中可见一斑，在对其有一定的认识与了解的前提下，我们来简单学习下 身份认证与鉴权 ——数据安全技术中的细分知识点。

一、身份认证

1、Basic认证（HTTP Basic Authentication）

认证流程：

Basic认证也叫401认证，经典特征是发出请求后会弹窗，要求用户输入账号、密码进行身份验证

请求包特征如下，由于账号和密码在http请求报文中明文传输（user:passwd的base64编码），容易造成敏感信息泄露，因而安全性不足。

经典案例：古老的tomcat 401认证弱口令漏洞，tomcat/tomcat

2、基于AK/SK的身份认证

  • AK：Access key ID，用于区分客户端应用的身份，简称AK，（有点类似web端接口的appid，也是用于区分客户端身份）
  • SK：Secret key，用于加密认证的密钥，必须保密，简称SK；

2.1 原理

客户端：　　　　

  1. 构建HTTP请求（包含 AK）；　　　　
  2. 使用 请求内容 和 SK 计算签名(signature)；　　　　
  3. 发送请求到服务端；

服务端：

  1. 根据发送的AK查找数据库得到对应的SK；

如果 AK 被篡改，那么服务端查询出的 SK 也不一样，校验不通过；

  1. 使用同样的算法将请求内容和 SK 一起计算签名（signature），与客户端步骤2相同；

签名可以保证数据的三个特性：真实性（未被伪造）、完整性（不存在缺失）、不可否认性；

  1. 对比用户发送的签名和服务端计算的签名，两者相同则认证通过，否则失败；

2.2 关于AK/SK的安全风险

使用AK/SK进行身份验证的场景，除了应用于应用程序API中，在云平台API的场景下使用更加广泛，以此作为突破口登上云控制台进而引发的漏洞也十分常见；对于AK/SK的体系化防护需要管理手段和技术手段同步进行，一般来讲单独造轮子来实现对其的管理比较难，基于云厂商的基础设施、产品能力来实现投入产出比会高些，但企业也需要做好AK/SK的存储管理、防重放攻击等措施。

1）存储风险
硬编码在代码中，代码泄露在公网后带来的安全风险；配置文件明文存储SK并在日志中任意打印等。

2）分发风险
传输过程没有保障，例如使用及时通讯工具传输、wiki明文记录等。

3）权限未做精细化隔离风险
多业务共用，导致SK权限过大，可以访问到其他业务数据；一个业务的AK/SK泄露其他业务也会被波及。

4）信息泄露导致的AK/SK泄露
例如github代码泄露，漏洞导致的AK/SK泄露（如：spring boot Actuaotr 敏感信息泄露）

3、OIDC

OIDC 是 OpenID Connect 的简称，OpenID Connect = OAuth 2.0 + ID 令牌（JWT），OAuth 2.0的功能是鉴权，OIDC 是基于OAuth 2.0 实现的一种身份认证方式。

3.1 OIDC概念

OAuth 2.0 实现的是授权，但不能实现身份认证，如果把OAuth专门用来做身份验证，就会出现很多问题，例如：没有第三方登录验证应用程序、没有一个标准的方式来获得用户信息、每个获得信息的方式也不一样、应用获得的scope也不一样，因此OIDC在前者的基础上增加以下功能，来更标准规范地实现身份认证：

  • ID token （user的信息）
  • 如果需要更多的用户信息，可以请求userinfo endpoint
  • 有一个标准的scope
  • 部署方式标准化

3.2 OIDC实现流程

OpenID Connect和OAuth从技术上来讲，哪里有什么不一样呢？

就在第一步向授权服务器进行请求时，会请求openid profile的scope。access token和ID token一起获得，access token可以向resource server要profile，ID token是 JWT格式的，由于其防篡改、防抵赖性质可以证明是哪个用户进行了登录，让client不需要再找authorization server再次进行身份验证，就能直接用ID token来进行身份验证。如果ID Token的用户信息不够，那么可以调用userinfo endpoint来获取更多的用户信息。

3.3 安全风险

  • OAuth 2.0 具备的风险，如：回调地址校验不严格导致账号被劫持、CSRF、XSS、url跳转
  • ID token是JWT格式，JWT带来的安全风险
  • SSRF：在客户端进行注册时，POST请求中可输入恶意url导致的二阶SSRF

4、JWT

4.1 为什么要使用JWT

  • 解决cookie不能跨域问题
  • 兼容多端应用： PC端、手机、webApp、App、小程序
    • App 、小程序 不支持cookie、session
  • 分布式环境下session不能共享
    • session工作在服务器端，把用户的信息记录在服务器
    • 需要想办法将用户的信息在多台服务器间共享
  • 避免CSRF攻击
    通过cookie验证的场景下，当受害者点击攻击者构造的恶意url时，由于浏览器特性会带着cookie去访问，因此以受害者的身份访问了恶意页面从而遭受CSRF攻击；

4.2、业务流程

输入账号密码进行验证，验证通过后获取JWT令牌，后续的每次访问不再需要输入账号密码，凭借JWT令牌即可访问

4.3、JWT的组成：Header、Payload、Signature

JWT在线生成：https://jwt.io/
python库生成：pyjwt
格式：base64(Header).base64(Payload).base64(Signature)

  • Header

{"typ": "JWT","alg": "HS256"}，type是指令牌的类型，alg是使用的签名算法

  • Payload：Payload 里面是 Token 的具体内容，这些内容里面有一些是标准字段，也可以添加其它需要的内容。下面是标准字段：

iss：Issuer，发行者
sub：Subject，主题
aud：Audience，观众
exp：Expiration time，过期时间
nbf：Not before
iat：Issued at，发行时间
jti：JWT ID 比如下面这个 Payload ，用到了 iss 发行人，还有 exp 过期时间。另外还有两个自定义的字段，一个是 name ，还有一个是 admin 。

{"iss": "ninghao.net",
 "exp": "1438955445",
 "name": "wanghao",
 "admin":**true**}
  • Signature：HMAC(Header.Header)
    对Header和payload base64编码后的信息进行提取摘要，得到的Signature是一段hash值

String encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload);
String token = HMACSHA256(encodedString, 'secret');

使用HAMC的目的是保证 JWT 没有被篡改过，原理如下：
HMAC 算法是不可逆算法，类似 MD5 和 hash ，但多一个密钥，密钥（即上面的 secret）由服务端持有，客户端把 token 发给服务端后，服务端可以把其中的头部和载荷再加上事先共享的 secret 再进行一次 HMAC 加密，得到的结果和 token 的第三段进行对比，如果一样则表明数据没有被篡改。

4.4、JWT的存储

  • 存储在localstorage中，但存在XSS风险
  • 存储在sessonstorage中，
  • 存储在HttpOnly Cookie中，但是存在CSRF风险，可通过设置CORS跨域白名单、Cookie secure属性设置为true

4.5、JWT常见安全问题

https://www.freebuf.com/vuls/341301.html

  • 签名未校验
  • 敏感信息泄露
  • 算法被篡改
  • 密钥被爆破
  • 伪造密钥(CVE-2018-0114)
  • 重放攻击

1）签名signature未校验
修改或者删除signature

2）敏感信息泄露
由于Header和Payload是通过base64编码的，因此如果敏感信息处理不到会导致泄露风险。

3）签名算法可被修改为none(CVE-2015-2951)

也就是header中的“alg”为none，在线工具jwt.io无法修改，使用Pyjwt库进行修改，生成的jwt token只有header和payload两部分，没有signature：

4）密钥被爆破
String encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload);
String token = HMACSHA256(encodedString, 'secret');

jwt利用算法对header和payload进行加密生成signature，如果能知道密钥secret就能随意修改jwt token了；

爆破脚本：https://github.com/Ch1ngg/JWTPyCrack

爆破工具：npm install jwt-cracker

5）伪造密钥(CVE-2018-0114)
jwk ，json web key，就是header中的密钥，通过伪造header中的密钥来控制jwt token的生成：

6）重放攻击

4.6、JWT常规的防御

从Header、Payload、Signature三个攻击面分别来说：

1）Header

在后端校验算法类型，Header中的算法类型不可信

2）Payload

Payload中不包含敏感信息；对jwt token的有效性进行校验，例如使用exp过期参数；

3）Signature

强制校验Signature的有无/正确性；密钥必须后端强制校验，防止密钥被伪造；保证密钥的强度防止被爆破；

5、SSO

SSO可以实现一处登录、多处使用，但和Oauth 有所区别，SSO常见于企业内部系统，如OA系统，Oauth 常见于跨企业跨应用的登录，如微信登录可在多个不同企业的App上使用。

用户除此登录系统时，需要先输入账号密码进行验证，验证通过后服务端会发给用户一个身份凭证，用户拿着这个身份凭证就能到 已接入SSO账号体系下的 应用中进行登录了，身份凭证过期后又再次到SSO进行登录、领取。

实现单点登录的方式有很多种，常见的有基于Cookie、Session共享、Token机制、JWT机制等方式，简单来说：

  • Cookie 存在 CSRF 和不能跨域访问问题；
  • Session 解决了跨域问题，但不能在多台服务器间共享；
  • Token 能解决前两者的问题，但是需要查库，对性能会有一定的影响；
  • JWT 和Token类似，Token 需要查库验证 Token 是否有效，而JWT不用查库，直接在服务端进行校验（用户的信息、加密信息、过期时间都存在JWT里，只需在服务端进行校验，校验也由JWT自己实现的）。

5.2 单点登录的安全风险

凭证被窃取（Url跳转漏洞）、Cookie 安全性不足（应该 https+secure+httponly）、凭证可重放/无过期机制等。

6、kerberos

  • 用于实现什么功能，用在什么场景
  • 工作流程
  • 安全隐患/加固建议
  • 漏洞案例

6.1 kerberos是什么

kerberos是一个用于身份认证的网络协议，如： windows域内的身份验证、hadoop集群生态中的对服务的身份验证等。

6.2 kerberos的实现流程

kerberos是古希腊神话中的三头地狱恶犬，kerberos的三个主要角色分别是：client、server、KDC：

  • 客户端（client）：发送请求的一方
  • 服务端（Server）：接收请求的一方
  • 密钥分发中心（Key Distribution Center，KDC），而密钥分发中心一般又分为两部分，分别是：
    • AS（Authentication Server）：认证服务器，专门用来认证客户端的身份并发放客户用于访问TGS的TGT（票据授予票据）
    • TGS（Ticket Granting Server）：票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据（Ticket）

简化的三个步骤：
1、向KDC中的AS验证身份后，得到TGT（Ticket Granting Ticket，票据授予票据）；
2、拿着TGT向KDC中的TGS请求ST（服务票据）；
3、拿着ST去请求对应的服务。

Referer： https://segmentfault.com/a/1190000020953603

7、MFA（Multi-factor authentication，多因子认证）

除账号密码之外的第二次身份认证，如：手机验证码、邮箱验证、指纹、人脸、OTP口令等。

二、授权与访问控制

1、OAuth 2.0

OAuth 有 授权码模式、简化模式、密码模式和客户端凭证模式、设备码模式 几种模式，其中授权码模式是使用较为主流的。

2、RBAC

RBAC （Role Based Access Control ），基于角色的访问控制，是最常见和常用的权限模型，又细分为 RBAC0、RBAC1、RBAC2、RBAC3:

  • RBAC0：最基础的权限角色模型
  • RBAC1：支持角色分层
  • RBAC2：支持角色约束条件
    • 互斥角色：同一个用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离原则。互斥角色是指各自权限互相制约的两个角色。比如财务部有会计和审核员两个角色，他们是互斥角色，那么用户不能同时拥有这两个角色，提现了职责分离原则；
    • 基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数据受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配；
    • 先决条件角色：即用户想获得某上级角色，必须先获得其下一级角色；
  • RBAC3：RBAC1+RBAC2

RBAC模型对功能权限的划分，与之相对应的数据权限也是权限治理中重要的一部分。

3、其他权限模型

基于属性的访问控制（Attribute-Based Access Control，ABAC模型）、基于上下文的访问控制（Attribute-Based Access Control，CBAC，防火墙/WAF中使用较多）、基于ACL访问控制（IP策略）

PBAC的简单理解：PBAC=RBAC+ABAC

PBAC的指导原则是，设置策略、用户配置文件和环境条件必须符合允许访问的标准。 由于PBAC支持运行时授权，因此它是动态的，并具有允许实时进行更改的能力。无需维护不断变化的用户角色的存储库，无需从特定组中添加或删除单个用户，也无需在公司的员工状态和职责发生变化时不断维护对资源的授权。由于PBAC是自动过程，因此可以减少与人工干预有关的风险。

TODO（挖坑）

随着云技术的发展，现在企业纷纷上云，混合云、私有云、公有云，云场景下的身份认证安全问题也是一大研究热点。
例如IAM的安全管控、云上AK/SK的泄露和安全管理等等。

posted @ 2023-01-29 13:39  人间修行  阅读(1238)  评论(0)  编辑  收藏  举报