Web安全入门：从HTML与HTTP协议基础到实战攻防

原创于 2026-07-02 15:56:06 发布 · 430 阅读 ·

大模型引用 1 次

本内容遵循CC 4.0 BY-SA版权协议

代码可运行

1. 项目概述：为什么从HTML和HTTP开始学安全？

很多刚接触Web安全的朋友，一上来就想学SQL注入、XSS跨站脚本，或者直接上手渗透测试工具。这种热情值得肯定，但往往事倍功半，因为基础不牢。我见过太多人，能熟练使用扫描器，却看不懂一个HTTP请求包里的 Referer 和 Origin 头有什么区别；能复现一个XSS漏洞，却不明白为什么 <script> 标签在有的地方能执行，有的地方不行。

问题的根源在于，Web安全不是空中楼阁，它建立在Web技术栈之上。而这座大厦的地基，就是 HTML 和 HTTP协议 。HTML定义了Web内容的骨架与血肉，是攻击者注入恶意代码的“画布”；HTTP则是浏览器与服务器沟通的“语言”，是攻击流量传输的“高速公路”。不理解这两者，安全知识就像散落的珍珠，无法串联。

所以，这篇内容的目标很明确： 为你搭建一个坚实、通透的Web安全认知起点 。我们不急于求成，而是从最基础的HTML标签和HTTP请求/响应讲起，让你真正理解攻击是如何发生的，防御又该从何处着手。当你读完，你会对“同源策略”、“CSP”、“HTTPS”、“Cookie安全”这些常见术语有更本质的认识，而不仅仅是记住几个工具命令。

2. 核心基石：HTML不只是“网页”，更是攻击面

HTML（超文本标记语言）是Web的基石。对开发者而言，它是构建页面的工具；对安全研究者而言，它是攻击的入口。每一个标签、每一个属性，都可能成为安全链上的薄弱环节。

2.1 HTML文档结构与安全启示

一个标准的HTML5文档开头是这样的：

<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>安全示例页面</title>
</head>
<body>
    <!-- 页面内容在这里 -->
</body>
</html>

这看起来人畜无害，但其中已蕴含安全考量：

<!DOCTYPE html> ：声明文档类型，避免浏览器以怪异模式渲染，这能减少一些因解析差异导致的不确定性风险。
<meta charset="UTF-8"> ：指定字符编码。如果缺失或错误，可能导致乱码，更严重的是，可能被利用进行 编码绕过攻击 。例如，某些过滤系统可能无法正确识别不同编码下的恶意字符串。
<meta name="viewport"...> ：移动端适配。虽然不直接关联安全，但响应式设计不当可能导致界面扭曲，被用于钓鱼攻击（例如，伪造登录框）。

实操心得 ：养成在每一个HTML文件头部都规范书写这些元信息的习惯。这不仅是好实践，也能从源头减少因环境不一致导致的安全问题。

2.2 危险的“洞”：表单、脚本与资源引用

HTML的交互性和动态能力主要通过几个关键元素实现，而这些也正是安全问题的重灾区。

1. 表单（ <form> ）：用户输入的通道，也是注入的入口

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

action 属性：指定数据提交的URL。如果这里被恶意修改（例如通过DOM操作），用户凭证可能被发送到攻击者的服务器。
method 属性： POST 比 GET 更安全，因为 GET 的参数会暴露在URL和浏览器历史记录中，容易被窃取或通过 Referer 头泄露。
input 字段：没有进行输入过滤和输出编码的话，直接用于拼接SQL查询（导致SQL注入）或输出到页面（导致XSS）。

2. 脚本（ <script> ）：能力与风险的双刃剑

<!-- 内联脚本 - 高风险 -->
<script>alert('这是一个弹窗');</script>

<!-- 外部引用 - 相对安全，但需保证来源可信 -->
<script src="https://cdn.example.com/trusted-library.js"></script>

内联脚本 ：直接将JavaScript代码写在HTML中。这是 XSS攻击最直接的利用方式 。一旦攻击者能向页面注入 <script>alert('hacked')</script> 这样的内容，代码就会在受害者浏览器中执行。
外部脚本 ：通过 src 引用。风险点在于：如果引用的第三方资源（如CDN）被劫持，或者URL本身被篡改（ 供应链攻击 ），那么引入的将是恶意代码。

3. 资源引用与跨域： <img> , <link> , <iframe>

<img src="http://evil.com/tracker.jpg" onerror="stealCookie()">
<link href="http://evil.com/style.css" rel="stylesheet">
<iframe src="http://another-site.com"></iframe>

img 的 onerror 属性：可以用来执行JavaScript，是XSS的常见载体。
link 和 script 的 src / href ：可以发起跨域请求。虽然通常不能直接读取响应内容（受同源策略限制），但请求本身会携带用户Cookie（如果目标站点Cookie设置不当），这可用于 CSRF（跨站请求伪造） 攻击。
iframe ：可以嵌入第三方页面。如果嵌入的页面不可信，可能引发 点击劫持（Clickjacking） 攻击，诱使用户在不知情的情况下进行操作。

2.3 关键安全属性与最佳实践

HTML也提供了一些原生安全属性，善用它们能有效提升防护等级。

1. Content Security Policy (CSP) 的 HTML 实现 虽然CSP主要通过HTTP头设置，但也可以通过 <meta> 标签定义（适用于无法控制服务器头部的场景）：

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://trusted.cdn.com;">

这个策略表示：默认只允许加载同源资源，脚本除了同源，只允许从 https://trusted.cdn.com 加载。这能有效阻止内联脚本执行和未经授权的外部脚本加载，是防御XSS的利器。

2. 表单安全增强

autocomplete="off" ：对于敏感表单（如密码、支付信息），建议关闭自动填充，防止被浏览器或恶意插件窃取。
input 的 type 属性：使用正确的类型（如 type="email" , type="url" ），浏览器会进行初步的格式验证，虽然不能替代服务端验证，但能拦截一部分无效输入。
永远不要依赖前端验证 ：前端验证是为了用户体验，服务端验证才是安全底线。攻击者可以轻易绕过所有前端检查。

3. 链接与跳转的安全

<!-- 不安全的打开新窗口方式 -->
<a href="https://external.com" target="_blank">外部链接</a>
<!-- 这样打开的新页面，可以通过 window.opener 访问原页面，存在安全风险 -->

<!-- 相对安全的方式 -->
<a href="https://external.com" target="_blank" rel="noopener noreferrer">外部链接</a>

rel="noopener" ：阻止新打开的页面通过 window.opener 访问原页面上下文，防止钓鱼攻击。
rel="noreferrer" ：同时阻止发送 Referer HTTP头，保护来源页面信息不泄露。

避坑指南 ：在代码审计或黑盒测试时，重点关注那些没有 CSP 保护、存在大量内联脚本和事件处理器（如 onclick , onerror ）、表单提交目标为 GET 、以及外部资源引用使用HTTP明文协议的页面。这些都是高危信号。

3. 通信命脉：HTTP协议深度解析与安全攻防

如果说HTML是“静态”的界面，那么HTTP就是驱动一切交互的“动态”血液。几乎所有Web攻击都发生在HTTP请求和响应的传输与处理过程中。

3.1 HTTP请求/响应模型：一切攻击的上下文

一个最简单的HTTP GET请求和响应如下：

# 客户端请求
GET /index.html?user=alice HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Cookie: sessionid=abc123

# 服务器响应
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: sessionid=xyz789; HttpOnly; Secure
Content-Length: 1234

<!DOCTYPE html><html>...</html>

安全视角的拆解：

请求行 ： GET /index.html?user=alice HTTP/1.1
- GET 方法：参数在URL中可见，易被日志记录、浏览器历史缓存，不适合传输敏感信息。
- /index.html?user=alice ：查询字符串 user=alice 。攻击者可以修改这个值进行测试（如改为 user=admin'-- 尝试SQL注入）。
请求头 ：
- Host ：指定虚拟主机。可用于 虚拟主机走私 攻击。
- Cookie ：携带会话标识。如果Cookie未设置 HttpOnly ，JavaScript可以读取它，导致 会话劫持 。
响应头 ：
- Set-Cookie ：这里设置了 HttpOnly 和 Secure 标志。 HttpOnly 阻止JavaScript访问此Cookie， Secure 要求Cookie仅通过HTTPS传输。 这是保护会话Cookie的黄金标准 。
- Content-Type ：告诉浏览器如何解析内容。如果服务器返回的是 text/html ，但实际内容是用户上传的图片，浏览器仍会尝试解析为HTML，可能导致 内容嗅探攻击 或 XSS 。应设置 X-Content-Type-Options: nosniff 来禁止浏览器进行MIME类型嗅探。

3.2 核心安全头：你的第一道防线

许多Web安全漏洞可以通过正确配置HTTP响应头来缓解或消除。

响应头	作用与安全意义	推荐配置示例
`Content-Security-Policy (CSP)`	内容安全策略，限制资源加载来源，是防御XSS的终极武器。	`default-src 'self'; script-src 'self'`
`X-Frame-Options`	控制页面是否可以被 `<frame>` , `<iframe>` 嵌入，防止点击劫持。	`DENY` 或 `SAMEORIGIN`
`X-Content-Type-Options`	禁止浏览器对响应内容进行MIME类型嗅探，防止某些类型的XSS。	`nosniff`
`Strict-Transport-Security (HSTS)`	强制浏览器使用HTTPS与站点通信，防止SSL剥离攻击。	`max-age=31536000; includeSubDomains`
`Referrer-Policy`	控制 `Referer` 头中发送多少来源信息，防止敏感信息泄露。	`strict-origin-when-cross-origin`
`X-XSS-Protection`	（已过时）旧版IE和Chrome的XSS过滤器，现代浏览器已废弃，应依赖CSP。	通常设置为 `0` 以禁用

配置示例（Nginx服务器） ：

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.example.com; object-src 'none';";
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header Referrer-Policy "strict-origin-when-cross-origin";

注意事项 ：CSP策略的配置需要谨慎测试。过于严格的策略（如 script-src 'self' ）可能会阻断网站正常运行的外部脚本（如统计、字体库）。建议采用渐进式策略：先设置为仅报告模式（ Content-Security-Policy-Report-Only ），观察一段时间，再正式启用。

3.3 方法、状态码与安全场景

1. 安全相关的HTTP方法

GET ：幂等，应只用于获取数据，不应产生副作用（如修改数据）。用于数据读取。
POST ：非幂等，用于提交数据，创建资源。 处理敏感操作（登录、支付）时应使用POST 。
PUT / DELETE ：用于RESTful API更新/删除资源。需要严格的权限校验。
危险的遗留方法 ： TRACE （可能用于 跨站追踪攻击 ）、 PUT / DELETE （如果未授权开放）、 CONNECT （代理隧道）。应在服务器配置中禁用不必要的HTTP方法。

2. 需要警惕的HTTP状态码

200 OK ：成功。但有时服务器处理出错，却依然返回200并携带错误信息，这可能会泄露内部细节。
301/302 Found ：重定向。如果重定向目标由用户输入控制，可能导致 开放重定向漏洞 ，用于钓鱼攻击。
403 Forbidden ：禁止访问。与 401 Unauthorized （未认证）的区别很重要，泄露了资源是否存在的信息。
500 Internal Server Error ：服务器内部错误。可能伴随详细的堆栈跟踪信息， 这是敏感信息泄露的重大风险 ，应配置自定义错误页面。

3.4 HTTPS：不只是那个小锁图标

HTTP是明文传输的，这意味着在网络上传输的所有内容（包括密码、Cookie）都可能被窃听或篡改。HTTPS = HTTP + TLS/SSL加密。

TLS/SSL的核心作用：

加密：对传输数据进行加密，防止窃听。
完整性校验 ：防止数据在传输中被篡改。
身份认证 ：通过数字证书验证你连接的是真正的“example.com”，而不是中间人伪装的服务器。

实操要点：

获取证书 ：现在可以从Let‘s Encrypt等机构免费获取可信的SSL/TLS证书。
服务器配置 ：禁用旧的、不安全的SSL协议（如SSLv2, SSLv3）和弱加密套件。可以使用在线工具（如SSL Labs的SSL Test）检测配置安全性。
HSTS ：如前所述，配置 Strict-Transport-Security 头，强制浏览器使用HTTPS。
混合内容警告 ：HTTPS页面中如果加载了HTTP资源（如图片、脚本），浏览器会报“混合内容”警告，并可能阻塞这些资源。 务必确保所有子资源都使用HTTPS 。

经验之谈 ：不要认为上了HTTPS就万事大吉。错误配置的HTTPS（如使用自签名证书、支持弱加密算法）可能比HTTP更危险，因为它给了用户一种虚假的安全感。定期检查证书有效期和服务器配置是必须的。

4. 从原理到实战：常见Web攻击的HTML/HTTP根源

理解了基础，我们就能看清常见攻击手法的本质。它们大多是对HTML和HTTP协议特性的恶意利用。

4.1 跨站脚本（XSS）：当HTML被注入恶意脚本

攻击原理 ：攻击者将恶意JavaScript代码“注入”到网页中，当其他用户浏览该页面时，代码在其浏览器上下文执行。 与HTML/HTTP的关系 ：

存储型XSS ：恶意脚本被保存到服务器（如数据库），随后在正常页面中被渲染为HTML的一部分。关键在于应用没有对用户输入进行 输出编码 就将其作为HTML输出。
反射型XSS ：恶意脚本作为请求参数（通常在URL中）发送给服务器，服务器未经验证就直接将其“反射”回响应页面中。这利用了 HTTP请求参数可控 的特性。
DOM型XSS ：漏洞发生在客户端JavaScript代码中，它 不安全的操作了DOM （例如，使用 innerHTML 或 document.write 直接拼接了用户可控的数据）。

防御措施 ：

对输出进行编码 ：根据输出位置（HTML体、HTML属性、JavaScript、URL）使用对应的编码函数。
实施严格的CSP ：禁止内联脚本执行 ( script-src 'self' )，限制脚本来源。
使用安全的API ：避免使用 innerHTML ，改用 textContent ；避免使用 eval() 。
设置Cookie的HttpOnly属性 ：即使发生XSS，攻击者也无法直接窃取Cookie。

4.2 跨站请求伪造（CSRF）：滥用浏览器的自动Cookie发送机制

攻击原理 ：攻击者诱骗已登录的用户访问一个恶意页面，该页面自动向目标网站发起一个请求（如转账）。由于浏览器会自动携带该站点的Cookie，服务器会认为这是用户的合法操作。 与HTML/HTTP的关系 ：

核心利用了 浏览器对特定HTTP请求（如图片加载、表单提交）会自动携带Cookie 这一机制。
攻击通常通过HTML标签发起： <img src="https://bank.com/transfer?to=attacker&amount=1000"> 或一个自动提交的隐藏表单。

防御措施 ：

使用CSRF Token ：在表单或请求中携带一个服务器生成的、随机的、与用户会话绑定的Token。服务器验证该Token是否匹配。
检查 Origin 和 Referer 头 ：对于敏感操作，验证请求是否来自同源站点。但 Referer 头可能被禁用或伪造，不能单独依赖。
设置Cookie的SameSite属性 ： SameSite=Strict 或 Lax 可以限制Cookie在跨站请求中不被发送，从根本上防御CSRF。现代浏览器的默认值已是 Lax 。

4.3 点击劫持（Clickjacking）：iframe的视觉欺骗

攻击原理 ：攻击者使用一个透明的 <iframe> 覆盖在诱饵按钮上，用户以为自己点击的是诱饵，实际点击的是iframe中目标网站的危险操作按钮（如“确认删除”）。 与HTML/HTTP的关系 ：

完全依赖于 <iframe> 标签可以嵌入并透明化显示的特性。

防御措施 ：

设置 X-Frame-Options 响应头 ： DENY （禁止被嵌入）或 SAMEORIGIN （只允许同源页面嵌入）。
使用CSP的 frame-ancestors 指令 ：这是更现代的替代方案，例如 Content-Security-Policy: frame-ancestors 'none'; 。

4.4 不安全的重定向与转发

攻击原理 ：应用程序将用户重定向到一个由用户参数控制的URL。攻击者构造一个指向恶意站点的链接，诱使用户点击。

GET /redirect?url=http://evil-phishing-site.com HTTP/1.1
Host: www.trusted-site.com

与HTML/HTTP的关系 ：

利用了HTTP 302 Found 状态码和 Location 头的重定向功能。
攻击链接可能通过HTML邮件或网页传播。

防御措施 ：

避免使用用户参数控制重定向目标 。
如果必须使用，应进行严格的白名单校验 ，只允许重定向到预设的、可信的域名列表。
对于站内转发，可以使用映射表（将token映射到真实URL）而非直接传递URL。

5. 实战演练：搭建一个可观察的安全/不安全环境

最好的学习方式是动手。我建议你在本地搭建一个简单的实验环境。

1. 环境准备：

安装 Node.js 和 npm 。
创建一个新目录，初始化项目： npm init -y 。
安装基础Web框架，如Express： npm install express 。

2. 创建有漏洞的服务器（ vulnerable-server.js ）：

const express = require('express');
const app = express();
app.use(express.urlencoded({ extended: true }));

// 漏洞1：反射型XSS
app.get('/search', (req, res) => {
    const query = req.query.q || '';
    // 危险！直接输出用户输入到HTML
    res.send(`<h1>搜索结果: ${query}</h1>`);
});

// 漏洞2：开放重定向
app.get('/redirect', (req, res) => {
    const url = req.query.url;
    if (url) {
        // 危险！未验证重定向目标
        res.redirect(url);
    } else {
        res.send('缺少url参数');
    }
});

// 漏洞3：Cookie未设置HttpOnly
app.get('/login', (req, res) => {
    // 模拟登录
    res.cookie('sessionId', 'fake-session-123'); // 缺少 HttpOnly 和 Secure
    res.send('登录成功！');
});

app.listen(3000, () => console.log('漏洞服务器运行在 http://localhost:3000'));

3. 创建加固后的服务器（ secure-server.js ）：

const express = require('express');
const helmet = require('helmet'); // 使用helmet库自动设置安全头
const app = express();
app.use(helmet()); // 启用helmet
app.use(express.urlencoded({ extended: true }));

// 修复1：防御XSS - 对输出进行编码
const escapeHtml = (text) => {
    return text.replace(/[&<>"']/g, (match) => ({
        '&': '&amp;',
        '<': '&lt;',
        '>': '&gt;',
        '"': '&quot;',
        "'": '&#39;'
    }[match]));
};
app.get('/search', (req, res) => {
    const query = req.query.q || '';
    // 安全：输出前编码
    res.send(`<h1>搜索结果: ${escapeHtml(query)}</h1>`);
});

// 修复2：安全重定向 - 白名单校验
const allowedDomains = ['https://www.example.com', '/local-path'];
app.get('/safe-redirect', (req, res) => {
    const url = req.query.url;
    if (url && allowedDomains.some(allowed => url.startsWith(allowed))) {
        res.redirect(302, url);
    } else {
        res.status(400).send('非法的重定向目标');
    }
});

// 修复3：安全的Cookie
app.get('/secure-login', (req, res) => {
    res.cookie('sessionId', 'fake-secure-session-456', {
        httpOnly: true, // 阻止JS访问
        secure: process.env.NODE_ENV === 'production', // 生产环境强制HTTPS
        sameSite: 'lax' // 提供一定的CSRF防护
    });
    res.send('安全登录成功！');
});

// 手动添加更严格的CSP
app.use((req, res, next) => {
    res.setHeader('Content-Security-Policy', "default-src 'self'; script-src 'self'");
    next();
});

app.listen(3001, () => console.log('安全服务器运行在 http://localhost:3001'));

4. 实验步骤：

分别运行两个服务器： node vulnerable-server.js 和 node secure-server.js 。
访问 http://localhost:3000/search?q=<script>alert('xss')</script> ，观察弹窗（XSS触发）。
访问 http://localhost:3000/redirect?url=http://evil.com ，观察跳转。
在浏览器开发者工具的Console中，输入 document.cookie ，尝试读取Cookie。
对安全服务器（端口3001）重复步骤2-4，观察所有攻击尝试都被阻止。

通过这个对比实验，你能直观地看到不安全的编码、缺失的HTTP头会带来怎样的风险，以及正确的防护措施如何生效。

6. 进阶安全头与配置详解

除了前面提到的常见安全头，还有一些更细粒度的控制策略。

1. Subresource Integrity (SRI) - 子资源完整性 当从CDN等外部源加载脚本或样式时，如何确保资源未被篡改？SRI通过哈希值来验证。

<script src="https://cdn.example.com/jquery.min.js"
        integrity="sha384-...sha384哈希值..."
        crossorigin="anonymous"></script>

如果CDN上的文件内容与 integrity 属性中的哈希值不匹配，浏览器将拒绝执行该脚本。

2. Cross-Origin Resource Sharing (CORS) - 跨源资源共享 CORS是一种机制，允许一个源的Web应用访问另一个源的资源。配置不当会导致信息泄露。

服务端响应头 ： Access-Control-Allow-Origin: https://trusted-site.com （指定允许的源，不能用通配符 * 处理携带凭证的请求）
携带凭证的请求 ：如果请求需要Cookie，客户端需设置 fetch(..., {credentials: 'include'}) ，服务端需设置 Access-Control-Allow-Credentials: true ，并且 Access-Control-Allow-Origin 不能为 * 。

3. Permissions Policy (formerly Feature Policy) - 权限策略 控制浏览器特性（如摄像头、地理位置、支付等）在页面中是否可用。

Permissions-Policy: camera=(), geolocation=(self "https://maps.example.com"), payment=*

上述策略表示：禁用摄像头，仅允许本域和 maps.example.com 使用地理位置，允许所有来源使用支付功能。

7. 工具链与持续学习建议

理论结合实践，工具能极大提升效率。

1. 浏览器开发者工具 (F12)

Network（网络）面板 ：查看每一个HTTP请求和响应的详细信息，包括头、参数、响应体。这是分析Web通信的瑞士军刀。
Console（控制台） ：查看JavaScript错误、CSP违规报告、执行测试代码。
Application（应用）面板 ：查看和操作Cookie、LocalStorage、SessionStorage。可以手动修改Cookie值测试会话管理。
Security（安全）面板 ：快速查看当前页面的HTTPS证书信息和安全问题。

2. 安全扫描与评估工具

OWASP ZAP / Burp Suite Community Edition ：功能强大的渗透测试代理。可以拦截、查看、修改HTTP/HTTPS流量，进行自动化的漏洞扫描（如XSS, SQLi）。对于学习而言，Burp Suite的“Repeater”（重放）和“Intruder”（入侵）模块是理解HTTP请求构造和参数模糊测试的绝佳工具。
Mozilla Observatory (observatory.mozilla.org) ：在线工具，输入一个URL，它会检查一系列安全HTTP头的配置情况（如CSP, HSTS, Cookies等），并给出评分和改进建议。非常适合用于快速检查自己网站的安全配置基线。
Security Headers (securityheaders.com) ：类似Observatory，专注于分析HTTP安全响应头。

3. 学习资源与社区

OWASP (Open Web Application Security Project) ：Web安全领域的圣经。必读 OWASP Top 10 ，了解当前最重要的十大Web应用安全风险。其提供的 Cheat Sheet Series （速查表系列）是极佳的实战参考。
MDN Web Docs (developer.mozilla.org) ：关于Web技术（包括安全）最权威、最准确的文档。本文中提到的许多概念（CSP, CORS, HSTS）在MDN上都有极其详细的阐述。
HackerOne Hacktivity / Bug Bounty平台报告 ：阅读公开的漏洞报告，看真实世界的漏洞是如何被发现的、如何描述、如何修复。这是从“知道”到“会用”的关键一步。

学习Web安全是一个螺旋上升的过程。从HTML和HTTP这个基础开始，建立起清晰的概念模型。然后去学习具体的漏洞（如SQL注入、文件上传、SSRF等），你会发现它们最终都落在对输入输出处理、对HTTP请求响应的操控上。接着，在学习防御措施时，你会回头来更深入地理解CSP、各种HTTP安全头的精妙之处。

不要试图一口吃成胖子。从搭建一个简单的漏洞环境开始，亲手触发一个XSS，然后修复它。用工具扫描你自己的博客或练习项目，看看报告里说了什么，然后去研究如何解决。这个过程积累下来的，才是真正属于你的、扎实的安全能力。

标签