Web安全
计算机网络
物理层
数据链路层
网络层
运输层(传输层)
应用层
基础漏洞
01前端基础【HTML】
02前端基础【CSS】
03后端基础【PHP速通】
04后端基础【PHP面向对象】
05MySQL基础操作
06前后端联动【代码练习】
07SQL注入概述
07SQL 注入类型
08SQL注入 Labs
08SQL注入速查表
09XSS
09XSS【概述版】
09XSS Labs
10跨站请求伪造【CSRF】
11服务器端请求伪造【SSRF】
12XML 外部实体注入【XXE】
13代码执行漏洞
14命令执行漏洞
15文件包含漏洞
16文件上传漏洞
17反序列化漏洞
18业务逻辑漏洞
19未授权访问漏洞集合
20跨源资源共享【CORS】
21SSTI模板注入
22并发漏洞
23点击劫持【Clickjacking 】
24请求走私
25路径遍历
26访问控制
27身份验证漏洞
28WebSocket
29Web缓存中毒
30HTTP 主机头攻击
31信息泄露漏洞
32原型污染
33NoSQL注入
小程序
小程序抓包
SessionKey
Appsecret与access_token
openid
数据库
MySQL
Oracle
MongoDB
Redis
PostgreSQL
SQL server
中间件
Nginx
Apache HTTP Server
IIS
Tomcat
框架
ThinkPHP
Spring
Spring Boot
Django
访问控制
身份认证(Authentication)
授权(Authorization)
单点登录(SSO)
零信任(ZTA)
分布式身份(DID)
-
+
首页
授权(Authorization)
授权的核心是 “**基于身份或属性,动态判断主体是否有权访问资源**”,防止合法身份的主体越权操作(如普通员工删除企业核心数据)。 其技术体系从 “静态规则” 发展到 “动态决策”,从 “集中管控” 升级到 “分布式授权”,可分为**授权模型、授权框架、实践工具**三大模块。 ## 授权模式 > 自主访问控制(Discretionary Access Control, DAC) 定义:资源所有者自主决定谁能访问资源及权限,权限可由所有者主动转让(如 “你分享文件给同事,并允许他再分享给他人”)。 核心逻辑:资源关联 “访问控制列表(ACL)”,记录 “哪个主体有哪种权限”(如 “用户 A→文件 X→读取权限”)。 优点:灵活性高,符合个人或小型团队的权限管理习惯。 缺点:权限易扩散(如 “转让的权限被多级传递”)、缺乏集中管控,不适合高安全需求场景。 场景:个人设备(如电脑文件共享)、小型团队协作(如部门内部文档共享)。 案例:Windows/Linux 文件系统的权限管理(如 Linux 的 rwx 权限:读、写、执行)、云存储桶的 ACL 配置(如阿里云 OSS 允许特定用户读取文件)。 > 强制访问控制(Mandatory Access Control, MAC) 定义:由系统(而非资源所有者)基于 “主体和客体的安全级别” 强制分配权限,所有者无法自主修改权限,核心是 “按安全等级隔离”。 核心逻辑: - 为每个主体(用户 / 进程)和客体(文件 / 数据库表)分配 “安全级别”(如 “绝密 > 机密 > 秘密 > 公开”); - 系统预设规则:仅当 “主体安全级别 ≥ 客体安全级别” 时,才允许访问(如 “机密级用户可访问秘密级文件,但无法访问绝密级文件”)。 优点:安全性极高,严格防止高敏感资源泄露。 缺点:灵活性差、权限配置复杂、运维成本高。 场景:军事系统、政府机密数据、金融核心交易数据(需最高级别的安全隔离)。 案例:美国国防部的 “Bell-LaPadula 模型”(用于机密数据隔离)、Linux 的 SELinux(Security-Enhanced Linux)、Windows 的 BitLocker 加密存储。 > 基于角色的访问控制(Role-Based Access Control, RBAC) 定义:通过 “角色” 作为中间层,关联 “主体 - 角色 - 权限”,先为角色分配权限,再将角色赋予用户,核心是 “按职责分配权限”。 核心逻辑(RBAC96 国际标准模型): - 定义角色:根据业务职责划分(如 “开发工程师”“运维人员”“财务审核员”); - 分配权限:为每个角色绑定 “最小必要权限”(如 “运维人员” 拥有 “服务器重启权限”,无 “数据库删除权限”); - 关联用户:将用户归入对应角色(如 “张三” 被分配 “开发工程师” 角色,自动获得该角色的所有权限)。 特性: - 角色继承:高级角色继承低级角色的权限(如 “高级开发工程师” 继承 “开发工程师” 的权限); - 角色互斥:冲突角色不可同时赋予同一用户(如 “财务录入” 与 “财务审核” 角色互斥,避免舞弊)。 优点: - 权限管理简化:无需为每个用户单独配置权限,只需维护角色与权限的映射; - 符合企业组织架构:角色与岗位职责对齐,人员变动时(如离职、调岗)仅需调整角色。 缺点:角色定义依赖固定职责,面对动态场景(如临时项目、跨部门协作)灵活性不足。 场景:绝大多数企业场景(如 OA、CRM、云平台管理),是目前应用最广泛的授权模型。 案例:企业 ERP 系统的权限管理(如 “财务角色” 仅能访问财务模块)、云平台 IAM(如 AWS IAM 的角色授权)。 > 基于属性的访问控制(Attribute-Based Access Control, ABAC) 定义:通过 “主体、资源、环境的多维度属性” 动态判断权限,核心是 “按属性组合决策”,而非预定义角色。 核心逻辑: 1. 定义属性维度(三类核心属性): - 主体属性:用户职位(如 “产品经理”)、部门(如 “研发部”)、资质(如 “PMP 认证”); - 资源属性:资源类型(如 “客户数据”)、敏感度(如 “高敏感”)、所属项目(如 “项目 A”); - 环境属性:访问时间(如 “工作日 9:00-18:00”)、访问设备(如 “企业办公电脑”)、网络位置(如 “内网 IP”); 2. 配置决策规则:例如「若主体部门 = 研发部 AND 资源所属项目 = 项目 A AND 访问环境 = 内网 → 允许读取资源」; 优点: - 灵活性极高:支持动态场景(如临时项目、跨部门协作),无需频繁调整角色; - 细粒度管控:可基于多维度属性精准控制(如 “仅允许张三在办公室用企业电脑访问项目 A 的高敏感数据”)。 缺点:属性定义复杂,规则逻辑易冗余(如大量属性组合导致规则数量爆炸),需依赖自动化工具(如规则引擎)管理。 场景:云环境、IoT 系统、零信任架构、跨组织协作(如供应链数据共享)。 案例:云平台权限管理(如阿里云 RAM 基于用户属性、资源属性动态授权)、IoT 设备控制(如 “仅允许家庭 WiFi 下的手机控制智能门锁”); > 基于策略的访问控制(Policy-Based Access Control, PBAC) 定义:将授权逻辑抽象为 “全局策略”,通过 “策略引擎” 解析策略并动态决策,可视为 ABAC 的 “策略化延伸”。 核心逻辑: - 制定策略:采用标准化语言(如 XACML,可扩展访问控制标记语言)定义全局策略,例如「所有财务数据仅允许财务部门在工作日访问,且需 MFA 验证」; - 策略引擎:接收访问请求(主体 + 资源 + 操作 + 环境),解析策略并判断是否允许; - 动态执行:策略变更时(如 “财务数据访问时间调整为 8:00-17:00”),仅需修改全局策略,无需逐个调整资源权限。 优点: - 集中管控:所有授权逻辑统一在策略中,便于合规审计; - 可扩展性强:支持跨系统、跨平台的统一授权。 缺点:策略语言学习成本高(如 XACML 语法复杂),策略引擎性能要求高。 场景:大型企业、跨平台系统(如混合云)、高合规需求场景(如金融、医疗)。 案例:大型企业跨平台授权(如混合云环境下的统一权限策略)、金融行业合规授权(如符合《个人信息保护法》的客户数据访问控制)。 > 基于任务的访问控制(Task-Based Access Control, TBAC) 定义:围绕 “任务流程” 分配权限,仅在任务执行的 “特定阶段” 赋予用户必要权限,任务完成后权限自动回收,核心是 “按任务生命周期管控权限”。 核心逻辑: 1. 定义任务流程:拆分任务为多个阶段(如 “采购流程” 分为 “申请→审批→付款→归档”); 2. 绑定阶段与权限:每个阶段仅赋予对应权限(如 “审批阶段” 仅允许审批人执行 “同意 / 拒绝” 操作,无 “付款” 权限); 3. 权限动态回收:任务进入下一阶段或完成后,上一阶段的权限自动失效。 优点: - 最小权限动态化:权限仅在任务需要时存在,降低滥用风险; - 贴合业务流程:与企业实际业务深度结合; 缺点:依赖清晰的任务流程定义,对无固定流程的场景不适用。 场景:流程化业务(如财务审批、采购管理)、需要追溯任务责任的场景。 案例:企业审批系统(如财务报销审批流程)、工单系统(如 IT 运维工单的 “创建→处理→关闭” 阶段权限控制); ## 授权框架 > OAuth 2.0:第三方应用的授权框架 定位:解决 “第三方应用如何在不获取用户账号密码的情况下,安全获取用户在某平台的资源权限”(核心是 “授权委托”,而非认证)。 角色: - 资源所有者(User):用户; - 客户端(Client):第三方应用(如知乎); - 授权服务器(Authorization Server):资源平台的授权中心(如微信); - 资源服务器(Resource Server):存储用户资源的服务器(如微信存储用户头像的服务器)。 授权模式: - 授权码模式(Authorization Code Flow):最安全,适合 Web 应用、移动 APP,流程见OIDC 部分; - 密码模式(Resource Owner Password Flow):用户直接向客户端提供账号密码,仅适合高度信任的客户端(如企业内部 APP); - 客户端模式(Client Credentials Flow):无用户参与,客户端用自身凭证(Client ID/Secret)获取权限,适合后端服务间调用(如 API 接口授权); - 简化模式(Implicit Flow):直接返回 Access Token,不经过授权码环节,适合纯前端应用(如 SPA),安全性较低; 核心凭证: - Access Token(访问令牌):用于访问资源服务器的临时凭证,有效期短(如 1 小时); - Refresh Token(刷新令牌):用于 Access Token 过期后重新获取,有效期长(如 30 天),需安全存储(如服务器端)。 场景:第三方登录(如 “用 QQ 登录游戏”)、跨平台 API 授权(如 “抖音 APP 授权第三方工具管理作品”)。 > JWT(JSON Web Token):轻量级权限 / 身份凭证 定位:紧凑的、自包含的令牌格式,用于在各方之间安全传递 “身份或权限信息”,常与 OAuth 2.0、OIDC 配合使用。 令牌结构(3 部分,用 “.” 分隔,Base64 编码): - Header(头部):指定令牌类型(JWT)和签名算法(如`{"alg":"HS256","typ":"JWT"}`); - Payload(载荷):存储核心信息,包括 “标准声明”(如`exp`表示过期时间、`iss`表示签发者)和 “自定义声明”(如`user_id: 123`、`role: dev`); - Signature(签名):用 Header 指定的算法对 Header+Payload 签名(如 HS256 用密钥签名),确保令牌未被篡改; 优势: - 自包含:令牌包含所有必要信息,服务器无需查询数据库即可验证权限,适合分布式系统; - 轻量:JSON 格式比 XML 简洁,传输速度快。 注意事项: - Payload 是 Base64 编码(不是加密),敏感信息(如密码)需避免存入,或使用 JWE(JSON Web Encryption)加密; - 无状态:令牌一旦签发无法撤回,需通过缩短有效期、维护黑名单(如 Redis)应对令牌泄露。 场景:OIDC 的 ID Token、OAuth 2.0 的 Access Token、分布式系统中的权限传递(如微服务间通过 JWT 确认权限)。 > STS(Security Token Service,安全令牌服务) 定位:生成临时权限凭证的服务,核心是 “动态管理权限,降低长期凭证泄露风险”。 功能: - 生成临时凭证:为主体生成短期有效的 Access Token、Secret Key,替代长期固定密钥; - 权限精细化控制:通过 AssumeRole 接口临时获取特定角色的权限(如 “只读权限”); - 跨账户授权:支持不同云账户、不同身份系统间的权限委托。 场景:跨账户资源共享、第三方应用集成、临时特权访问(如运维人员临时执行高危操作)。 案例:AWS STS、阿里云 STS,如 “企业 A 授权企业 B 的员工通过 STS 临时访问其云存储”。 ## 安全风险 | 安全挑战 | 核心风险 | 应对措施 | | ------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | 权限冗余 / 过度授权 | 普通用户拥有高级权限(如开发人员有数据库删除权限) | 1. 遵循最小权限原则;2. 定期权限审计(如每季度回收冗余权限);3. 采用 ABAC 动态调整权限 | | 权限蔓延 | 用户调岗后未回收旧角色权限(如员工从研发转行政后仍有代码库访问权) | 1. 人员变动触发权限自动调整(如 HR 系统与授权系统联动);2. 定期用户权限复核 | | 动态场景授权难 | 临时项目团队需跨部门访问资源,角色配置繁琐 | 1. 采用 ABAC/PBAC 模型;2. 临时权限自动过期(如 24 小时后失效) | | 权限决策不透明 | 无法追溯 “为何允许 / 拒绝某访问请求”,合规审计困难 | 1. 记录授权决策日志(含主体、资源、属性、规则);2. 采用 PBAC 统一策略,便于审计 | ## 协同技术 > SSO(单点登录):认证与授权的 “统一入口” SSO 不仅是认证技术,更是**认证与授权的协同载体**。 认证层面:用户一次登录,多系统共享认证状态; 授权层面:SSO 认证通过后,向各系统传递用户身份和基础权限信息(如角色、部门),各系统基于该信息执行授权决策; 典型案例:企业员工通过 SSO 登录 OA 后,访问 CRM 时无需重新认证,CRM 基于 SSO 传递的 “销售角色” 授权用户访问客户数据。 > 零信任架构(Zero Trust Architecture, ZTA):认证与授权的 “动态协同升级” 零信任架构的核心理念是 “永不信任,始终验证”,彻底重构了认证与授权的协同模式: 认证层面:从 “一次认证终身有效” 升级为 “持续认证”,实时验证用户行为、设备状态、环境属性(如 “用户从内网切换到公网时,触发 MFA 二次认证”); 授权层面:从 “静态权限” 升级为 “动态授权”,基于实时认证结果调整权限(如 “用户设备存在恶意软件时,临时收回高敏感资源访问权”); 协同逻辑:认证与授权 “持续联动”,每一次访问请求都需同时验证身份合法性和权限合法性,无 “永久信任” 状态。
毛林
2025年10月11日 11:04
转发文档
收藏文档
上一篇
下一篇
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
PDF文档(打印)
分享
链接
类型
密码
更新密码