2021 OWASP TOP 10
近些年漏洞的威胁分类也发生了很大变化，王道SQL注入也慢慢淡出历史的舞台，最新OWASP Top Ten | OWASP Foundation版，分类和排名都变化了很多
[TOP1]失效的访问控制
访问控制失效指的是：系统没有正确限制用户访问资源或功能，导致用户可以访问本不该访问的内容或操作
具体的例子：
用户越权访问
- 用户 A 修改自己的资料：
1 | POST /api/user/update?id=1001 |
- 他把 ID 改成了管理员的 ID：
1 | POST /api/user/update?id=1 |
- 没有权限校验？那就直接修改管理员信息成功了
水平越权
普通用户访问了其他用户的数据，比如：
1 | GET /api/orders/123456 |
→ 返回了别人的订单信息（严重泄露）
垂直越权
普通用户调用了管理员接口：
1 | POST /api/admin/delete_user?id=2 |
如果没检查角色权限，就能直接删号
前端控制误信
前端隐藏了按钮，认为“用户就点不到”：
1 | <!-- 管理员按钮 --> |
然而攻击者直接 F12 改代码，照样能点
[TOP2]加密机制失效
它其实是以前叫做“敏感数据暴露（Sensitive Data Exposure）”的进化版，专门指：加密没做好 or 该加密却没加密，导致敏感信息暴露
什么叫“加密机制失效”？
就是本来你用了加密，结果：
- 用错算法了
- 密钥管理乱套了
- 加密流程瞎写
- 本该加密的地方压根没加密
结果攻击者轻轻松松就拿到敏感数据：密码、银行卡、身份信息、Token、session、甚至数据库内容……
常见的失效方式：
| 错误类型 | 示例 |
|---|---|
| 使用弱加密算法 | 使用 MD5/SHA1 加密密码 |
| 明文传输敏感信息 | 登录时通过 HTTP 提交用户名密码 |
| 明文存储敏感数据 | 数据库里直接存储身份证、手机号等 |
| 加密后泄露密钥 | 把密钥写在代码里、GitHub里 |
| 没有加密 | 比如 Cookie 没有设置 Secure + HttpOnly |
| 错误的加密流程 | 密文没有加随机盐、IV 被复用等 |
攻击者怎么利用
- 截获未加密的 HTTP 请求，拿到账号密码。
- 拿到数据库后用字典暴力破解 MD5 加密的密码。
- 从前端源码或 Git 泄漏中拿到 AES 密钥解密所有数据。
- 复用泄漏的 JWT Token 冒充他人身份
[TOP3]注入
最经典的一集
什么是注入漏洞（Injection）？
就是应用程序把用户输入当成代码或命令执行了，攻击者通过构造恶意输入，控制程序行为，从而实现：
- 执行任意命令
- 查询/篡改/删除数据库
- 提权、越权
- 甚至远程控制服务器
常见的注入类型
| 类型 | 简介 |
|---|---|
| SQL 注入 | 向数据库查询语句中注入恶意 SQL 代码 |
| 命令注入 | 向系统命令中注入恶意命令 |
| LDAP 注入 | 向 LDAP 查询语句中注入内容 |
| XPATH 注入 | 攻击 XML 查询逻辑 |
| NoSQL 注入 | 攻击 MongoDB、Redis 等非关系型数据库 |
| 表达式注入 | 如 SpEL、OGNL 等框架表达式被执行 |
| ORM 注入 | 即使用了 ORM 框架，但拼接查询也能被注入 |
[TOP4]不安全的设计
不安全的设计指的是：在系统架构、业务流程、功能逻辑上，一开始就没有考虑安全，导致再怎么加补丁也“补不住”。
它和“实现缺陷”不同，强调的是设计阶段的安全问题，而不是代码实现时的小失误
举个栗子：
例1：没有验证码
- 登录接口无限试错 → 被爆破了
- 注册接口被批量打脚本 → 被刷号了
例2：密码重置只用邮箱地址就能触发
- 没有身份验证 → 轻松盗号
例3：未做权限分离的业务逻辑
- 所有人都能访问
/admin/delete_user?id=1
例4：可预测的文件上传路径
- 上传文件保存为
/upload/{用户名}.jpg - 恶意访问
/upload/admin.jpg直接泄露敏感资源
[TOP5]安全配置错误
什么是“安全配置错误”？
安全配置错误是指：系统、框架、服务器、数据库等组件的默认配置太危险，或者运维部署过程中配置疏忽、遗漏，导致被攻击者利用的情况。
一不小心就把“后门”留给了黑客
常见的配置错误示例：
| 类型 | 示例 |
|---|---|
| 默认密码未修改 | admin/admin、root/root、123456 |
| 目录/文件暴露 | .git/、/backup.zip、/WEB-INF/可访问 |
| 错误信息泄露 | 报错页面暴露堆栈、路径、数据库结构等 |
| 开启调试模式 | Flask 的 debug=True，Spring Boot 的 actuator |
| 开放未使用端口 | Redis、Elasticsearch、MongoDB 未授权访问 |
| 跨域配置不当 | CORS 允许任意来源：Access-Control-Allow-Origin: * |
| 缺少 HTTP 安全头 | 没设置 X-Content-Type-Options, X-Frame-Options 等 |
| TLS 配置弱 | 使用 SSL3.0、弱密码套件、没有证书校验 |
| 容器或云服务配置问题 | Docker 映射敏感目录、云 bucket 设置成公开可读写 |
[TOP6]自带缺陷和过时的组件
什么是“自带缺陷和过时的组件”？
指的是：你的项目中依赖了有已知漏洞的软件组件、库、框架、服务，但你却没有及时更新、替换或做防护，攻击者一看版本就知道怎么打。
也叫：
- 第三方组件漏洞
- 供应链安全问题的一种
常见的“有毒”组件例子：
| 类型 | 漏洞例子 | 危害 |
|---|---|---|
| Web框架 | Struts2（S2-045） | 远程命令执行 |
| JS库 | jQuery <1.9 | XSS 漏洞 |
| Java依赖 | log4j（Log4Shell） | 任意代码执行 |
| Python包 | requests 老版本 | SSL验证绕过 |
| Node库 | lodash、express 老版本 | 多种原型链污染 |
| CMS系统 | WordPress 插件漏洞 | 任意文件上传、SQL注入 |
只要我们获得了某个组件的版本，就可以用https://www.exploit-db.com/去查找对应的 exp
当然有时 exp 会不奏效，我们可以根据实际情况对 exp 进行修改
[TOP7]身份识别和身份验证错误
什么是“身份识别与身份验证错误”？
指的是系统在识别用户身份或验证用户合法性的机制上设计不当、实现出错，导致攻击者可以伪装他人、绕过登录、劫持账号、撞库成功等
具体表现有哪些？
| 类别 | 示例 | 危害 |
|---|---|---|
| 弱密码策略 | 可以设置 123456 或 admin |
被撞库/穷举轻松成功 |
| 无登录限制 | 登录接口无限尝试密码 | 爆破成功，账户被盗 |
| 验证码缺失/可绕过 | 验证码固定、简单或能跳过 | 自动化暴力攻击 |
| Session管理不当 | Token 泄露、过期机制缺失 | 会话固定、劫持 |
| 身份验证信息明文传输 | HTTP 明文传用户名/密码 | 被中间人攻击窃取 |
| 多因子认证缺失 | 仅靠密码验证 | 易被撞库或钓鱼攻击 |
| 身份切换不安全 | 登录后修改参数切换为他人身份 | 水平越权或账号接管 |
[TOP8]软件和数据完整性故障
什么是“软件和数据完整性故障”？
指的是：系统在运行过程中依赖的软件、配置、代码或数据，没有进行完整性校验或校验机制被绕过，攻击者就可以篡改这些内容，进而控制系统。
简而言之：
你信任的东西被“偷偷动手脚”了，但你没检查
常见攻击场景
| 类型 | 示例 | 后果 |
|---|---|---|
| 供应链投毒 | **开发依赖了被挂马的 NPM 包（如 ****event-stream**） |
项目编译就中毒，攻击者远控系统 |
| 自动更新缺乏签名验证 | 软件启动时更新 **.exe** 没做签名校验 |
MITM 劫持替换为木马 |
| CI/CD 脚本可被注入 | 发布脚本中引用外部 Bash/Python 脚本 | 远程代码执行、上传后门 |
| 缺少完整性校验 | 静态文件未设置 Hash，容易被篡改 | 攻击者插入恶意 JS/XSS |
| Docker 镜像来源不明 | 使用了不可信的第三方镜像 | 镜像自带恶意服务或后门账号 |
[TOP9]安全日志和监控故障
什么是“安全日志和监控故障 ”？
安全日志和监控故障是指系统未能妥善记录安全相关事件，或者在发生攻击或异常时未能及时检测与响应，导致攻击行为未被发现或延迟应对，从而扩大损害范围。
常见表现
- 系统关键操作没有记录日志，如登录、权限变更、敏感数据访问。
- 日志记录过于简单或不一致，缺乏时间戳、用户标识、IP 信息等。
- 日志没有集中存储或无法追踪。
- 未部署 SIEM（安全信息与事件管理）系统或告警规则缺失。
- 日志被攻击者删除或篡改后无恢复机制。
- 发生攻击时无自动响应机制（如封锁 IP、断开连接等）。
实际危害
- 攻击滞后发现：例如 Webshell 被植入服务器几个月都未被察觉。
- 取证困难：无法还原攻击路径，影响溯源与司法调查。
- 监管不合规：如金融、医疗等行业必须满足日志留存合规要求。
- 扩大损害：攻击者反复尝试暴力破解或横向移动而不被发现。
[TOP10]服务器端请求伪造(SSRF)
什么是“服务器端请求伪造(SSRF) ”？
SSRF 是指攻击者诱使 服务器端发起请求，目标通常是：
- 内网服务（如
http://127.0.0.1:2375） - 云服务元数据接口（如 AWS 的
http://169.254.169.254/latest/meta-data/） - 其他本不应被访问的地址
攻击原理：
攻击者控制请求地址，让服务器代为访问：
1 | POST /fetch?url=http://169.254.169.254/latest/meta-data/iam/ |
服务端拿这个 URL 去请求，就泄露了内部数据。
检测方法（实战技巧）：
- 使用 burp 修改参数试探内网 IP，如：
1 | url=http://127.0.0.1:80/ |
- 利用 DNSlog 验证是否存在请求发出
- 用 Gopher 协议构造 Redis 注入等高级 SSRF
延伸场景（云原生）：
- SSRF 是打穿云平台、K8S 集群、获取云凭证的第一步
- 可与 RCE、反序列化、身份提升等漏洞组合使用，形成 链式攻击
**— **
OWASP Top 10 总结了当今最常见且最严重的 Web 安全风险，涵盖了访问控制失效、加密机制薄弱、注入攻击、设计缺陷、配置错误、使用过时组件、身份验证问题、完整性缺失、日志监控不足以及服务器端请求伪造等各个层面。
了解这些风险的原理、成因和防护方式，有助于开发者、运维人员与安全工程师在系统设计与实现过程中构建更加健壮、可信赖的应用程序。
安全不是一次性的操作，而是一个持续演进的过程。只有将安全理念融入整个软件生命周期，才能真正有效降低攻击面，提升整体防护水平。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2025-07-24
ADS数据流实现隐藏文件
ADS：Alternate DataStreams，全称 NTFS 交换数据流，是 NTFS 磁盘格式的一个特性，在 NTFS 文件系统下，每个文件都可以存在多个数据流。简单来说，就是其他文件可以寄宿在某个文件身上。利用 ADS 数据流可以做很多有趣的事情 在NTFS分区创建ADS数据流文件有两种形式： 一是指定宿主文件； 二是创建单独的ADS文件。 创建的指令有两个：echo 和 type echo 用于常规字符 type 用于将文件附加到某个文件 使用方法1. 使用宿主文件1echo test > 1.txt:flag.txt 正常用 dir 是无法查看到的，可以使用 dir /r 123456789101112131415161718192021222324C:\test>dir 驱动器 C 中的卷没有标签。 卷的序列号是 46BD-3363 C:\test 的目录2025/07/22 03:53 <DIR> .2025/07/22 03:53 <DIR> ..2025...
2025-08-21
Python Bottle SSTI
XYCTF 中碰到的 Bottle 框架，当时做题根本没想到通过审计框架代码找漏洞点，也是学到新东西了 Bottle 简介Bottle 是一个 Python 的轻量级 Web 框架，完全依赖标准库（除了 wsgi 的部分），体积非常小（一个 .py 文件就能运行），适合写小型 Web 应用、API 或原型系统。它的设计理念是 “单文件、零依赖”，所以部署非常方便。 主要特点 特点 说明 单文件 框架代码就是一个 bottle.py 文件，方便直接打包或拷贝 零依赖 除了 Python 标准库外不需要额外安装其它库 内置开发服务器 用 run() 就能启动 HTTP 服务 支持多模板引擎 默认内置 SimpleTemplate，也支持 Jinja2、Mako 等 路由简洁 使用装饰器 @route() 定义 URL 对应的处理函数 WSGI兼容 可以在任何 WSGI 服务器（如 gunicorn、uWSGI）上部署 内置常用工具 请求/响应处理、静态文件服务、Cookie、表单解析等 基本结构示例1234567from bottle...
2025-08-07
SQL预编译——预编译真的能完美防御SQL注入吗
SQL注入原理sql注入是指攻击者拼接恶意SQL语句到接受外部参数的动态SQL查询中，程序本身未对插入的SQL语句进行过滤，导致SQL语句直接被服务端执行。拼接的SQL查询例如，通过在id变量后插入or 1=1这样的条件，来绕过身份验证，获得未授权数据的访问权。 1SELECT * FROM user WHERE id = -1 or 1=1 由于or 1=1 满足永真结果，sql语句会执行输出user中的全部内容。 那么这么危险的漏洞，有没有办法进行阻止呢 有的兄弟，有的 预编译就能解决大部分的SQL注入问题 什么是预编译（Prepared Statement）？预编译就是在执行 SQL 前，把 SQL 语句先告诉数据库服务器，编译好结构，然后再单独传参数进去执行！ 它的全名叫： Prepared Statement（预处理语句 / 预编译语句） 正常写 SQL 是怎样的？我们先看看普通的拼接 SQL 是怎样的： 123username = input("请输入用户名：")sql = "SELECT * FROM u...
2025-08-23
SQL to RCE
有一些陈旧、庞大的系统中，因为一些复杂的原因，往往仍在使用 sa 账户登入 SQL Server，而在有如此高权限的资料库账户权限下，我们可以轻易利用 xp_cmdshell 来执行系统指令，但是这是几乎不可能的，我们取得的数据库账户必然是低权限，但因为发现的 SQL 注入是堆叠注入，我们仍然可以对表进行 CRUD，运气好可以控制一些网站设定变数的话，甚至可以直接 RCE 就比如我们可以发现某些特殊的数据库： 123456Database: ASPState[2 tables]+---------------------------------------+| dbo.ASPStateTempApplications || dbo.ASPStateTempSessions |+---------------------------------------+ 这个数据库的存在用途是用来保存 ASP.NET 网站应用程式的 session。 在 ASP.NET 网站应用程式里，Session（会话数据，比如用户登录状态、购物车资料）...
2025-09-15
base64解码小trick
N1CTF Junior 2025 2/2 中的，也是不出意料没做出来 python 的 base64 解码逻辑和命令行的 base64 命令是不一致的 Python 的base64.b64decode(..., validate=True)在遇到 padding（=）后还有额外的 base64 字符，会报错，而用默认解码base64.b64decode(...)时，只会解出等号前的那一部分 但是命令行中会将两段都成功解出并拼接 这是因为 Base64 的编码本质上是一系列 4 字符为一组的字符块，最后一组可能用 = 填充以满足块对齐，根据解析器类型的不同，解析方法也会有区别 **严格解析器（Python 的 ****validate=True**）：一旦遇到合法的填充字符 =，就认为这是该 base64 段的结束；如果填充后仍有数据，会报错为“padding 之后有额外数据” 宽松/流式解析器（GNU **base64 -d** 等）：通常会把整个输入当作可能包含多个 base64 段（或忽略某些格式约束），会尽量解出每一段能解的部分，因此出现“先解出第一...
2025-07-21
python 内存马
之前一直想学内存马，但是碍于对 java 的了解近乎为0，对jndi的了解也是只停留在会背面经的层面，所以一直没有去学，直到后来翻一些文章发现 python 也可以利用 SSTI 进行内存马注入，于是迅速开整 Flask常见的 Python Web 框架如 Django 和 Flask 都有可能存在 SSTI（Server-Side Template Injection，服务端模板注入）漏洞 在 Flask 中，使用 render_template_string() 渲染模板时，若将用户输入直接传入而未做过滤处理，就可能导致 SSTI 漏洞。攻击者可通过该漏洞注入恶意模板代码，从而实现 代码执行，甚至进一步植入 内存马 内存马注入原理（Flask 路由机制）Flask 常规注册路由的方式是通过装饰器 @app.route()，但底层实际是调用了： 1self.add_url_rule(rule, endpoint=None, view_func=None) 各参数说明如下： rule：URL 路径（必须以 / 开头），与 @app.route() 中的路径一致 endpoin...
