Web 应用架构与安全漏洞基础学习

Web 应用框架

前端（XSS, CSRF）- 后端（SQL，越权，文件上传，文件包含...）- 数据库

场景：用户在小程序上输入手机号和密码，点击'登录'。

第一步：前端的工作 (用户看得见的部分)

前端负责展示界面、收集数据、调用 API、处理响应。

构建界面：画出登录页面，有手机号输入框、密码输入框和'登录'按钮。
监听事件：用户点击'登录'按钮时，前端代码被触发。
收集与校验：前端获取输入框里的手机号和密码，先做基本校验（如手机号格式、密码非空）。
调用 API（最关键一步）：前端使用 axios 或 fetch 等工具，发送这个请求。这个动作就叫 '调用 API'。之后，前端就进入等待状态，控制权转移给后端。
- API 地址 (URL)：https://api.yourservice.com/v1/user/login
- 请求方法 (Method)：POST
- 请求头 (Headers)：Content-Type: application/json
- 请求体 (Body)：一个 JSON 对象，里面装着用户数据。

前端按照后端提供的 API 文档，组装一个 HTTP 请求。比如：

{"phone_number":"13800138000","password":"encryptedPassword123"}

第二步：后端的工作 (服务器端，用户看不见的黑盒)

后端负责接收请求、处理业务逻辑、操作数据库、返回结果。它通过 API 来暴露自己的能力。

接收请求：后端的服务器在 https://api.yourservice.com/v1/user/login 这个地址上监听。收到前端发来的请求后，路由找到对应的处理函数（如 loginController）。
解析与验证：后端解析请求体中的 JSON，并进行严肃的业务验证：
- 手机号是否存在？
- 密码是否正确（会与数据库加密存储的密文对比）？
- 账户是否被锁定？
处理核心逻辑：
- 验证通过后，后端生成一个代表用户身份的令牌（Token），并关联这个用户 ID。
- 将这个 Token 和用户基本信息（昵称、头像）写入数据库或缓存（如 Redis）。
操作数据库：执行 SQL 语句，如 SELECT * FROM users WHERE phone_number = '13800138000'，查询用户信息。

组装并返回响应：后端处理完毕，按照 API 文档的约定，组装一个 HTTP 响应返回给前端。 响应体 (Body)：一个 JSON 对象。

{"code":200,"message":"登录成功","data":{"user_id":12345,"nickname":"张三","avatar":"https://xxx.jpg","token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}}

第三步：前端再次工作 (处理结果)

控制权随着 API 的响应，回到了前端。

接收响应：前端收到后端的 HTTP 响应。
解析结果：前端代码解析响应体中的 JSON。
业务处理：
- 如果 code 是 200（成功），前端将 token 和用户信息保存到本地（如 localStorage），然后跳转到首页。
- 如果 code 是 401（密码错误），前端在页面上弹出提示：'手机号或密码错误'。
更新界面：根据结果，前端展示成功或失败的提示，并刷新用户所见的界面。

核心分工与 API 的角色总结

角色	职责	与 API 的关系
前端	交互与展示。负责'是什么'和'怎么做'。	API 的调用方。严格按照 API 文档的格式'提问'。
后端	逻辑与数据。负责'能不能'和'给什么'。	API 的提供方。定义 API 的规则，并实现 API 背后的所有复杂逻辑。
API (HTTP 接口)	前后端的'合同'/'菜单'。	分工的边界与协作的桥梁。它明确规定了地址、方法和格式。

整个过程就像一个流水线： 前端（客户端） -> （通过 API 发出请求） -> 后端（服务器） -> （处理业务、操作数据库） -> 后端 -> （通过 API 返回响应） -> 前端 -> （更新界面）。

API 就是这条流水线上的标准化传输带和货物装箱规范，确保前后端两个不同的'工厂'能无缝协同工作。

几个问题：什么是 JSON？所以 API 是前端调用的吗？在网络空间安全中有没有可能跨过前端伪造 API 调用

1. 什么是 JSON？

JSON 是一种轻量级的数据交换格式，可以理解为一种在网络中传输数据的、人和机器都能看懂的'通用语言'。

全称：JavaScript Object Notation (JavaScript 对象表示法)，但它现在独立于任何语言，几乎所有编程语言都支持。
样子：它看起来就是纯文本，结构是键值对 (key-value) 的集合，和编程里的对象、字典非常像。
作用：它是API 通信中最常用的'语言'。前端发送请求时，把数据（如手机号、密码）包装成 JSON 格式；后端返回结果时，也把数据（如用户信息、状态码）包装成 JSON 格式。

举例：

{"name":"张三","age":25,"isStudent":false,"hobbies":["阅读","编程","篮球"],"address":{"city":"北京","street":"中关村大街"}}

2. 所以 API 是前端调用的吗？

是，但不仅仅是。 API 的核心是'接口'，任何能按照约定发送请求的程序，都可以是调用方。

主要调用方：在 Web 开发中，前端（浏览器、手机 App、小程序）是最常见的 API 调用者，因为它需要从后端获取数据或提交操作。
其他调用方：
1. 后端调用后端 (BFF/微服务)：一个后端服务可以调用另一个后端服务的 API 来获取特定数据。
2. 第三方服务调用：你的合作伙伴可以调用你开放的公开 API。
3. 脚本或测试工具：开发人员可以用 Postman、cURL 等工具直接调用 API 进行测试。

结论：前端是 API 的主要使用者，但 API 是为所有'客户端' 设计的。

3. 网络空间安全中，有没有可能跨过前端伪造 API 调用？

答案是：不仅有，而且这是 API 安全最主要的威胁之一，也是安全工程师工作的重中之重。

'跨过前端' 是极其常见且容易的。因为任何发送到网络的请求，本质上都是一段遵循 HTTP/HTTPS 协议的数据包。攻击者根本不需要你的前端界面。

常见的伪造/攻击手段：

直接构造请求：
- 攻击者用 Burp Suite、Postman、甚至简单的 cURL 命令，就能完全模仿你前端发出的请求。
- 他可以看到你的 API 地址、参数格式，然后修改参数。
重放攻击：
- 攻击者拦截一个合法的请求，然后原封不动地重复发送给服务器。
越权访问：
- 假设查看个人资料的 API 是：GET /api/user/profile?user_id=123
- 攻击者（自己是用户 123）把这个 user_id 改成 124，就可能看到用户 124 的资料。这就是'水平越权'。
- 如果是 GET /api/admin/all_users，普通用户如果尝试调用，就可能是'垂直越权'。
自动化攻击：
- 用脚本程序（机器人）高速、大量地调用你的 API。比如，用一万个手机号循环调用'发送短信验证码'API，导致你产生巨额费用（短信轰炸攻击）。

后端如何防御？（API 安全的核心）

正因为前端完全不可信，所以所有安全校验都必须放在后端。

身份认证：你是谁？
- Token/Session：登录后，后端颁发一个令牌，后续请求必须携带。后端每次都要验证这个令牌是否有效、是否过期、是否属于当前用户。
授权校验：你能干什么？
- 在处理关键操作前，后端代码必须检查当前登录的用户，是否有权限执行这个操作、访问这份数据。
参数校验：你发来的东西合规吗？
- 不仅校验格式（手机号是不是 11 位），还要校验业务逻辑（这个商品库存是否充足？这个订单是否属于你？）。永远不要相信前端传来的任何数据！
速率限制：你调用得太快了吗？
- 对 API 进行限流，比如'同一个 IP 每分钟只能调用 5 次登录接口'，防止机器人暴力破解密码或滥用服务。
签名与加密：
- 对关键请求（如支付）使用数字签名，确保数据在传输途中未被篡改。
- 全程使用 HTTPS，防止请求在传输过程中被窃听。

终极结论： API 就像你家房子的门。 前端 App 是正大光明从门进来的客人。但攻击者会尝试撬锁、翻窗、伪造钥匙，甚至用攻城锤撞门。后端安全工程师的工作，就是安装最坚固的门锁、设置警报系统、在屋内每个房间门口再加一道安检，确保无论请求从哪里、以何种方式过来，非法者都无法得逞。

是的，攻击者不仅可以轻易'跨过前端'伪造调用，这本身就是网络安全攻防的主战场。 一个健壮的 API 后端，必须假定所有来自前端的请求都可能是恶意的，并在此基础上进行层层验证。

主要漏洞类型学习

1. SQL 注入

2. RCE 远程代码执行

3. 文件上传漏洞

4. 文件包含漏洞

包含敏感文件

Linux 和 Windows 环境下均可利用路径遍历读取敏感文件。

包含上传文件漏洞利用条件：

上传路径知晓
可执行有权限
有文件包含漏洞

包含日志

核心原理正是'利用已知路径，通过访问行为写入恶意代码，再包含执行'。

5. XSS

反射型 XSS

检验是否存在：出现弹窗，说明代码被执行了，漏洞是存在的。

还可以获得网页 cookie。

存储型 XSS

永久性，常见于留言框，评论等实现保存 + 展示的地方。无需用户访问包含恶意代码的 URL。 XSS 钓鱼，XSS 挂码，XSS 蠕虫。比前面的漏洞危害更大。也可以用反射型的方式测试，也会有弹窗，而且是永久性的，哪怕刷新也会继续弹出。会发现 JavaScript 已经作为页面源代码插入与执行。

特征	存储型 XSS	反射型 XSS
存储位置	服务器数据库	不存储，在 URL 中
触发条件	访问被污染页面	必须点击恶意链接
持久性	永久（直到管理员删除）	一次性（关闭页面即失效）
攻击场景	留言板、评论、用户资料	搜索框、错误页面、URL 参数
危害等级	⭐⭐⭐⭐⭐	⭐⭐⭐

6. 暴力破解

利用 BurpSuite 抓包，send to intruder，导入字典，即可暴力破解。

7. 业务逻辑漏洞

短信验证码暴力破解

短信轰炸

8. 权限绕过漏洞

未授权访问

基于数据库，web 应用。

水平越权

攻击者和受害者权限级别相同，攻击者通过修改参数等手段，访问受害者资料。

垂直越权

攻击者和受害者权限级别不同，分为常见的向上越权（admin）和向下越权。

9. CSRF（跨站请求伪造）

以 DVWA 这道题为例。先抓包，了解到是通过 GET 传参更改的 password。

GET /vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change

在存储型 XSS 处抓包，改包，由于 cookie 一样，虽然是不同的站点，仍然可以实现更改密码操作。

正确的 Payload 示例：

<img src="http://127.0.0.1:42001/dvwa/vulnerabilities/csrf/?password_new=password1&password_conf=password1&Change=Change" style="display:none;"/>

可以发现发出去以后马上收到了另一个更改密码的包，这个是来自 CSRF 的。

10. SSRF

攻击者诱导服务器向内网/外部发送请求，可能用于探测内网信息或读取敏感文件。

1️⃣ 探测内网信息

Web 服务

开放端口

2️⃣ 读取敏感文件

例如：?url=file:///etc/passwd

CTF 中 Web 入门题型

PHP 特性

强弱类型比较科学计数法

缺陷函数

strcmp, md5, hash（都是接收到数组就返回 NULL） is_numeric（自动转换，如 404a 转换成 404）

信息泄露

注释（F12 看） robots.txt（防爬虫，但是有的时候暴露重要信息或路径） JS 信息泄露（前端代码审计） Vim 信息泄露，先下载，再用 Linux 系统命令 vim -r 文件名 查看

变量覆盖

特征：$$ 传参：GLOBALS，会输出所有变量

请求头

Cookie X-Forwarded-For

响应头

CTF 中 Web 进阶题型

代码执行

1️⃣ 可以有字母

变量函数（$a,$b 这样的可以传入参数如 system cat）

2️⃣ 不可以有字母（无长度限制）

异或或者自增，变量为$_（可以下划线作为变量名避免出现字母）

绕过 0：用弱比较漏洞返回 false 绕过 A：利用数组的 array 的第一个字母然后利用自增可以得到所有字母

2️⃣ 不可以有字母（有长度限制）

取反

原字符串：system 按每个字母转化成 ASCII 对应数字：[115, 121, 115, 116, 101, 109] 数组中每个数字写成二进制，然后按位取反 [140,134,140,139,154,146] 十进制转化成十六进制，然后 url 编码

命令执行

与上面的比起来更直接，一般可以直接获得 flag

管道符（熟悉 Linux 操作）

; 和 & 两个都执行，不管前面的真假 | 直接执行后面的 || 逻辑或，前假才后 && 逻辑与，前假后不执行 %0a 换行

空格绕过

关键字绕过

拼接，通配符 *, ?, 分割 `

文件读取（指定内容）

方法一：?file=data://text/plain,aaa（传入文本内容 aaa）方法二：?file=php://input 通过抓包 POST 传参

文件包含

1️⃣ 远程文件包含

需 allow_url_include=On(PHP 配置) 包含远程 URL（如 http://attacker.com/evil.txt）

2️⃣ 本地文件包含

目录遍历已上传（图片马、日志等）

文件上传

SQL

Web 应用框架

前端（XSS, CSRF）- 后端（SQL，越权，文件上传，文件包含...）- 数据库

场景：用户在小程序上输入手机号和密码，点击'登录'。

第一步：前端的工作 (用户看得见的部分)

前端负责展示界面、收集数据、调用 API、处理响应。

构建界面：画出登录页面，有手机号输入框、密码输入框和'登录'按钮。
监听事件：用户点击'登录'按钮时，前端代码被触发。
收集与校验：前端获取输入框里的手机号和密码，先做基本校验（如手机号格式、密码非空）。
调用 API（最关键一步）：前端使用 axios 或 fetch 等工具，发送这个请求。这个动作就叫 '调用 API'。之后，前端就进入等待状态，控制权转移给后端。
- API 地址 (URL)：https://api.yourservice.com/v1/user/login
- 请求方法 (Method)：POST
- 请求头 (Headers)：Content-Type: application/json
- 请求体 (Body)：一个 JSON 对象，里面装着用户数据。

前端按照后端提供的 API 文档，组装一个 HTTP 请求。比如：

{"phone_number":"13800138000","password":"encryptedPassword123"}

第二步：后端的工作 (服务器端，用户看不见的黑盒)

后端负责接收请求、处理业务逻辑、操作数据库、返回结果。它通过 API 来暴露自己的能力。

接收请求：后端的服务器在 https://api.yourservice.com/v1/user/login 这个地址上监听。收到前端发来的请求后，路由找到对应的处理函数（如 loginController）。
解析与验证：后端解析请求体中的 JSON，并进行严肃的业务验证：
- 手机号是否存在？
- 密码是否正确（会与数据库加密存储的密文对比）？
- 账户是否被锁定？
处理核心逻辑：
- 验证通过后，后端生成一个代表用户身份的令牌（Token），并关联这个用户 ID。
- 将这个 Token 和用户基本信息（昵称、头像）写入数据库或缓存（如 Redis）。
操作数据库：执行 SQL 语句，如 SELECT * FROM users WHERE phone_number = '13800138000'，查询用户信息。

组装并返回响应：后端处理完毕，按照 API 文档的约定，组装一个 HTTP 响应返回给前端。 响应体 (Body)：一个 JSON 对象。

{"code":200,"message":"登录成功","data":{"user_id":12345,"nickname":"张三","avatar":"https://xxx.jpg","token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}}

第三步：前端再次工作 (处理结果)

控制权随着 API 的响应，回到了前端。

接收响应：前端收到后端的 HTTP 响应。
解析结果：前端代码解析响应体中的 JSON。
业务处理：
- 如果 code 是 200（成功），前端将 token 和用户信息保存到本地（如 localStorage），然后跳转到首页。
- 如果 code 是 401（密码错误），前端在页面上弹出提示：'手机号或密码错误'。
更新界面：根据结果，前端展示成功或失败的提示，并刷新用户所见的界面。

核心分工与 API 的角色总结

角色	职责	与 API 的关系
前端	交互与展示。负责'是什么'和'怎么做'。	API 的调用方。严格按照 API 文档的格式'提问'。
后端	逻辑与数据。负责'能不能'和'给什么'。	API 的提供方。定义 API 的规则，并实现 API 背后的所有复杂逻辑。
API (HTTP 接口)	前后端的'合同'/'菜单'。	分工的边界与协作的桥梁。它明确规定了地址、方法和格式。

API 就是这条流水线上的标准化传输带和货物装箱规范，确保前后端两个不同的'工厂'能无缝协同工作。

几个问题：什么是 JSON？所以 API 是前端调用的吗？在网络空间安全中有没有可能跨过前端伪造 API 调用

1. 什么是 JSON？

JSON 是一种轻量级的数据交换格式，可以理解为一种在网络中传输数据的、人和机器都能看懂的'通用语言'。

全称：JavaScript Object Notation (JavaScript 对象表示法)，但它现在独立于任何语言，几乎所有编程语言都支持。
样子：它看起来就是纯文本，结构是键值对 (key-value) 的集合，和编程里的对象、字典非常像。
作用：它是API 通信中最常用的'语言'。前端发送请求时，把数据（如手机号、密码）包装成 JSON 格式；后端返回结果时，也把数据（如用户信息、状态码）包装成 JSON 格式。

举例：

{"name":"张三","age":25,"isStudent":false,"hobbies":["阅读","编程","篮球"],"address":{"city":"北京","street":"中关村大街"}}

2. 所以 API 是前端调用的吗？

是，但不仅仅是。 API 的核心是'接口'，任何能按照约定发送请求的程序，都可以是调用方。

主要调用方：在 Web 开发中，前端（浏览器、手机 App、小程序）是最常见的 API 调用者，因为它需要从后端获取数据或提交操作。
其他调用方：
1. 后端调用后端 (BFF/微服务)：一个后端服务可以调用另一个后端服务的 API 来获取特定数据。
2. 第三方服务调用：你的合作伙伴可以调用你开放的公开 API。
3. 脚本或测试工具：开发人员可以用 Postman、cURL 等工具直接调用 API 进行测试。

结论：前端是 API 的主要使用者，但 API 是为所有'客户端' 设计的。

3. 网络空间安全中，有没有可能跨过前端伪造 API 调用？

答案是：不仅有，而且这是 API 安全最主要的威胁之一，也是安全工程师工作的重中之重。

'跨过前端' 是极其常见且容易的。因为任何发送到网络的请求，本质上都是一段遵循 HTTP/HTTPS 协议的数据包。攻击者根本不需要你的前端界面。

常见的伪造/攻击手段：

直接构造请求：
- 攻击者用 Burp Suite、Postman、甚至简单的 cURL 命令，就能完全模仿你前端发出的请求。
- 他可以看到你的 API 地址、参数格式，然后修改参数。
重放攻击：
- 攻击者拦截一个合法的请求，然后原封不动地重复发送给服务器。
越权访问：
- 假设查看个人资料的 API 是：GET /api/user/profile?user_id=123
- 攻击者（自己是用户 123）把这个 user_id 改成 124，就可能看到用户 124 的资料。这就是'水平越权'。
- 如果是 GET /api/admin/all_users，普通用户如果尝试调用，就可能是'垂直越权'。
自动化攻击：
- 用脚本程序（机器人）高速、大量地调用你的 API。比如，用一万个手机号循环调用'发送短信验证码'API，导致你产生巨额费用（短信轰炸攻击）。

后端如何防御？（API 安全的核心）

正因为前端完全不可信，所以所有安全校验都必须放在后端。

身份认证：你是谁？
- Token/Session：登录后，后端颁发一个令牌，后续请求必须携带。后端每次都要验证这个令牌是否有效、是否过期、是否属于当前用户。
授权校验：你能干什么？
- 在处理关键操作前，后端代码必须检查当前登录的用户，是否有权限执行这个操作、访问这份数据。
参数校验：你发来的东西合规吗？
- 不仅校验格式（手机号是不是 11 位），还要校验业务逻辑（这个商品库存是否充足？这个订单是否属于你？）。永远不要相信前端传来的任何数据！
速率限制：你调用得太快了吗？
- 对 API 进行限流，比如'同一个 IP 每分钟只能调用 5 次登录接口'，防止机器人暴力破解密码或滥用服务。
签名与加密：
- 对关键请求（如支付）使用数字签名，确保数据在传输途中未被篡改。
- 全程使用 HTTPS，防止请求在传输过程中被窃听。

主要漏洞类型学习

1. SQL 注入

2. RCE 远程代码执行

3. 文件上传漏洞

4. 文件包含漏洞

包含敏感文件

Linux 和 Windows 环境下均可利用路径遍历读取敏感文件。

包含上传文件漏洞利用条件：

上传路径知晓
可执行有权限
有文件包含漏洞

包含日志

核心原理正是'利用已知路径，通过访问行为写入恶意代码，再包含执行'。

5. XSS

反射型 XSS

检验是否存在：出现弹窗，说明代码被执行了，漏洞是存在的。

还可以获得网页 cookie。

存储型 XSS

特征	存储型 XSS	反射型 XSS
存储位置	服务器数据库	不存储，在 URL 中
触发条件	访问被污染页面	必须点击恶意链接
持久性	永久（直到管理员删除）	一次性（关闭页面即失效）
攻击场景	留言板、评论、用户资料	搜索框、错误页面、URL 参数
危害等级	⭐⭐⭐⭐⭐	⭐⭐⭐

6. 暴力破解

利用 BurpSuite 抓包，send to intruder，导入字典，即可暴力破解。

7. 业务逻辑漏洞

短信验证码暴力破解

短信轰炸

8. 权限绕过漏洞

未授权访问

基于数据库，web 应用。

水平越权

攻击者和受害者权限级别相同，攻击者通过修改参数等手段，访问受害者资料。

垂直越权

攻击者和受害者权限级别不同，分为常见的向上越权（admin）和向下越权。

9. CSRF（跨站请求伪造）

以 DVWA 这道题为例。先抓包，了解到是通过 GET 传参更改的 password。

GET /vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change

在存储型 XSS 处抓包，改包，由于 cookie 一样，虽然是不同的站点，仍然可以实现更改密码操作。

正确的 Payload 示例：

<img src="http://127.0.0.1:42001/dvwa/vulnerabilities/csrf/?password_new=password1&password_conf=password1&Change=Change" style="display:none;"/>

可以发现发出去以后马上收到了另一个更改密码的包，这个是来自 CSRF 的。

10. SSRF

攻击者诱导服务器向内网/外部发送请求，可能用于探测内网信息或读取敏感文件。

1️⃣ 探测内网信息

Web 服务

开放端口

2️⃣ 读取敏感文件

例如：?url=file:///etc/passwd

CTF 中 Web 入门题型

PHP 特性

强弱类型比较科学计数法

缺陷函数

strcmp, md5, hash（都是接收到数组就返回 NULL） is_numeric（自动转换，如 404a 转换成 404）

信息泄露

变量覆盖

特征：$$ 传参：GLOBALS，会输出所有变量

请求头

Cookie X-Forwarded-For

响应头

CTF 中 Web 进阶题型

代码执行

1️⃣ 可以有字母

变量函数（$a,$b 这样的可以传入参数如 system cat）

2️⃣ 不可以有字母（无长度限制）

异或或者自增，变量为$_（可以下划线作为变量名避免出现字母）

绕过 0：用弱比较漏洞返回 false 绕过 A：利用数组的 array 的第一个字母然后利用自增可以得到所有字母

2️⃣ 不可以有字母（有长度限制）

取反

命令执行

与上面的比起来更直接，一般可以直接获得 flag

管道符（熟悉 Linux 操作）

; 和 & 两个都执行，不管前面的真假 | 直接执行后面的 || 逻辑或，前假才后 && 逻辑与，前假后不执行 %0a 换行

空格绕过

关键字绕过

拼接，通配符 *, ?, 分割 `

文件读取（指定内容）

方法一：?file=data://text/plain,aaa（传入文本内容 aaa）方法二：?file=php://input 通过抓包 POST 传参

文件包含

1️⃣ 远程文件包含

需 allow_url_include=On(PHP 配置) 包含远程 URL（如 http://attacker.com/evil.txt）

2️⃣ 本地文件包含

目录遍历已上传（图片马、日志等）