🔒法律免责声明：本文站在白帽安全测试视角，面向研发人员讲解 Web 漏洞成因、错误代码案例与安全编码修复方案，仅用于企业内部安全开发学习，请勿用于未授权渗透攻击。所有漏洞案例均为模拟业务代码，不指向任何真实线上业务系统。

摘要
大量线上 Web 安全漏洞，并非全部来自复杂的 0day 漏洞，绝大多数高危漏洞来源于开发阶段编码不规范、安全意识缺失、只重视功能忽略安全逻辑。很多开发同学会认为安全是安全测试、WAF、运维的事情，实际上漏洞根源产生在代码编写阶段。本文从白帽挖洞实战视角，梳理线上高频出现的 Web 安全漏洞：SQL 注入、XSS 跨站脚本、命令注入、文件上传、越权访问、CSRF、业务逻辑漏洞、反序列化、CORS 配置错误、文件包含等，对比危险代码与安全修复代码，分析开发过程常见安全误区，给出可直接落地的编码规范、安全检查清单、开发流程安全实践。帮助后端、前端、全栈开发者在写业务代码时从源头规避安全风险，减少 SRC 上报、漏洞扫描爆出高危漏洞，降低数据泄露、被入侵 getshell 的业务风险。

前言
在 SRC 漏洞平台大量的上报漏洞中，70% 以上的高危漏洞属于 “开发可完全避免” 的问题。白帽子拿到一个系统，不需要多么高深的技术，仅仅修改请求参数、构造特殊字符、篡改前端数据，就可以触发高危漏洞。

为什么会出现这种现象？

1. 开发的核心目标是实现业务功能，安全经常被后置；
2. 很多开发者依赖前端校验，认为前端拦掉，后端就不会收到恶意数据；
3. 网上复制粘贴 Demo 代码，没有甄别 Demo 代码是否存在安全缺陷；
4. 框架提供安全能力，但人为绕开框架安全机制，手动拼接 SQL、拼接命令；
5. 业务逻辑漏洞没有工具扫描，单元测试不会覆盖安全场景，上线直接暴露；
6. 将安全防护全部寄托于 WAF，WAF 可以被绕过，代码层才是最后防线。

WAF、扫描器属于外部防护手段，真正的安全防线在业务代码内部。如果代码本身存在漏洞，无论上层防护多强，都存在被绕过的可能性。本文不只是讲漏洞原理，更多站在开发者视角，告诉你写代码的时候哪些坑不能踩，遇到对应业务场景应该怎么写安全代码。

1. 开发人员必须建立的基础安全思维

在写每一行业务代码前，先建立 4 条核心安全思维，几乎所有 Web 漏洞都违背下面几条原则。

1.1 永远不要信任任何外部输入

一切来自 HTTP 请求的数据都是不可信的：GET 参数、POST 表单、JSON Body、Cookie、Header 请求头、上传文件内容、URL 路径参数。

攻击者完全可以绕过前端页面，使用 Burp、脚本构造任意恶意请求。前端校验只能做用户体验优化，不能作为安全防护手段。很多开发做了 JS 校验文件后缀，就认为上传是安全的，攻击者抓包直接修改数据包，防护完全失效。所有校验逻辑必须在服务端二次实现。

1.2 白名单优于黑名单

黑名单：禁止某些危险字符；白名单：只允许合法内容。

黑名单永远防不全，攻击者有编码、变形、大小写、注释等无数绕过方式。尽可能优先使用白名单校验，定义 “什么是合法”，非法输入直接拒绝，而不是过滤掉 “什么是非法”。

举例子：文件上传，不要写 “禁止 php 后缀”，应该写 “只允许 jpg/png/gif”。

1.3 最小权限原则

应用账号、数据库账号、服务器运行账号，只分配完成业务必须的最小权限，即使被攻击者利用漏洞，也尽可能缩小危害范围。

• Web 服务运行账号不要用 root、administrator；
• 业务数据库账号，不允许访问 mysql 系统库，不允许 FILE 写文件权限；
• 普通业务接口，禁止读取服务器本地敏感文件。

1.4 失败安全原则（Secure‑by‑Fail）

权限校验、参数校验逻辑，如果程序发生异常、报错，默认拒绝访问，而不是默认放行。

错误示范：权限判断发生异常，直接跳过校验执行业务逻辑；
正确示范：校验逻辑异常，直接返回 403 拒绝访问。

2. 注入类漏洞防护（SQL 注入｜命令注入｜表达式注入）

注入类漏洞是 OWASP Top10 常年高危类型，成因：把外部可控输入直接拼接进 SQL 语句、系统命令、代码表达式，攻击者篡改原有逻辑。

2.1 SQL 注入

危险代码示例（Java，错误写法，字符串拼接 SQL）

// 高危！直接拼接用户传入name参数 String name = request.getParameter("name"); String sql = "select * from user where username = '"+ name +"'"; stmt.executeQuery(sql);

攻击者传入' or '1'='1，直接拖库。

✅安全修复：使用预编译参数化查询（PreparedStatement）

String sql = "select * from user where username = ?"; PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setString(1,name); ResultSet rs = pstmt.executeQuery();

PHP 危险写法：

// 危险，字符串拼接 $sql = "select * from user where username = '".$_GET['user']."'";

PHP 安全写法 PDO 预编译：

$stmt = $pdo->prepare("select * from user where username = :username"); $stmt->bindParam(':username',$_GET['user']); $stmt->execute();

重要避坑点：很多开发使用 Mybatis，仍然手写({}字符串拼接，造成注入；#{}预编译，\){}直接字符串拼接，禁止业务参数使用${}。

<!-- 高危 --> select * from user where username = ${username} <!-- ✅安全 --> select * from user where username = #{username}

特殊场景：排序、表名无法预编译，此时不能直接接收前端参数，需要做白名单枚举校验，不允许直接传入原始参数。

// 排序字段，白名单校验 String sortBy = request.getParameter("sort"); List<String> allowSort = Arrays.asList("id","create_time","name"); if(!allowSort.contains(sortBy)){ return "非法参数"; }

2.2 命令注入

业务中有时候需要调用系统命令，比如 ping 网络检测。如果把用户输入直接拼接到系统 shell 命令，出现命令注入漏洞。

危险 Java 代码：

// 高危！用户可控ip直接拼接命令 String ip = request.getParameter("ip"); Runtime.getRuntime().exec("ping -c 4 "+ip);

攻击者传入：127.0.0.1;cat /etc/passwd，执行任意系统命令。

✅安全方案：

1. 尽可能避免直接调用系统命令，优先使用 SDK、内部函数实现业务，不要调用 shell；
2. 无法避免调用命令时，严格白名单校验输入，禁止特殊符号; | & $ > <；
3. 使用数组形式 exec，避免 shell 解析元字符。

Java 安全示例：

String ip = request.getParameter("ip"); //简单IP格式校验 if(!ip.matches("^\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}$")){ return "IP格式非法"; } //数组传入，不经过shell解析 String[] cmd = {"ping","-c","4",ip}; Runtime.getRuntime().exec(cmd);

2.3 SSTI 模板注入

不要把用户输入直接传入模板引擎渲染，Freemarker、Thymeleaf、Twig 如果渲染可控用户数据，会造成 SSTI，执行服务器代码。

业务场景：邮件模板、自定义页面功能，极易踩坑。
禁止：templateEngine.process(userInput,context)；用户输入不能作为模板源码。

3. XSS 跨站脚本漏洞，前端后端联合防御

XSS 分为反射型、存储型、DOM‑XSS，成因：可控用户输入未经处理输出到 HTML 页面，浏览器将用户输入当做 JS 代码执行。很多开发以为只需要前端转义，实际上存储型 XSS 需要后端输出编码。

3.1 危险场景

1. 留言板，用户提交

❌危险后端伪代码

//直接把用户评论输出到HTML页面 out.print("<div>"+comment+"</div>");

✅安全方案：输出编码，根据输出上下文选择转义方式

1. 输出到 HTML 正文：HTML 实体编码，< > " ’ & 转义；
2. 输出到 JS 变量：JS 转义；
3. 输出到 CSS：CSS 转义；
4. 输出到标签属性：属性编码。

SpringBoot 开发可以使用 OWASP‑Java‑Encoder 工具包做上下文编码。

//html正文输出编码 String safeComment = Encoder.forHtml(comment); out.print("<div>"+safeComment+"</div>");

前端 DOM‑XSS 重点：
禁止直接使用innerHTML、outerHTML、document.write、eval()处理外部可控数据；优先使用textContent，自动转义。

3.2 CSP 内容安全策略，深度防御

配置 HTTP 响应头 Content‑Security‑Policy，即使出现 XSS，也阻止脚本执行，属于深度防御手段，不能替代编码修复。
示例响应头：

Content‑Security‑Policy: default‑src 'self'; script‑src 'self'

3.3 开发常见误区

误区 1：后端过滤掉<script>标签就安全。攻击者可以用<img onload=alert(1)>、<svg onload=alert(1)>绕过黑名单过滤。黑名单过滤 XSS 不可靠，优先输出编码。
误区 2：前端框架（Vue/React）就不会 XSS。框架插值{{ }}自动编码，但 v‑html、dangerouslySetInnerHTML 会关闭转义，可控数据传入就会触发 XSS。

4. 文件相关漏洞：文件上传、文件包含、目录遍历

文件类漏洞是高危漏洞重灾区，很多业务都有头像上传、附件下载功能，稍有不注意直接 getshell。

4.1 文件上传漏洞

❌高危开发错误：只做前端 JS 校验；只校验 MIME‑Type；只修改文件名但保留原始后缀；上传目录允许脚本解析。

完整安全上传步骤，缺一不可：

1. 服务端二次校验，不要依赖前端 JS 校验；
2. 文件后缀采用白名单，仅允许业务需要的后缀，如 jpg、png；
3. 校验文件真实文件头，不仅仅看文件名后缀；
4. 后端重新生成随机文件名，丢弃用户原始文件名，防止 00 截断、双后缀攻击；
5. 上传文件存储目录，关闭脚本解析权限；上传目录不要直接可以执行 php/jsp；
6. 文件存放在 web 访问目录之外，通过接口读取返回；
7. 返回下载的时候设置响应头X‑Content‑Type‑Options: nosniff、Content‑Disposition:attachment，浏览器直接下载不解析执行。

危险示例：用户上传shell.php.jpg，后端没有校验文件内容，web 服务器存在解析漏洞，执行脚本。

4.2 目录遍历（路径穿越）

业务场景：文件下载，url 传入 filename 参数读取服务器文件。
危险：

/download?filename=../etc/passwd

❌危险伪代码

String filename = request.getParameter("filename"); File file = new File("./upload/"+filename);

攻击者使用../跳出业务目录，读取服务器任意敏感文件。

✅修复方案：

1. 对文件名做路径标准化，禁止../；
2. 白名单，数据库存储文件 ID，不要直接传入文件名参数；根据 ID 查询真实文件路径，强制限定基础目录。

File baseDir = new File("./upload"); File targetFile = new File(baseDir,filename); //判断文件是否在基础目录内，防止跳出 if(!targetFile.getCanonicalPath().startsWith(baseDir.getCanonicalPath())){ return "非法访问"; }

4.3 文件包含漏洞

PHP include、require 直接引入外部用户可控参数。

//高危 include($_GET['page']);

✅修复：禁止直接包含用户输入，白名单限定可包含的文件名称。

5. 访问控制类漏洞：垂直越权、水平越权、未授权访问

越权漏洞属于业务逻辑漏洞，扫描器很难发现，但是在 SRC 上报数量非常高，很多开发很容易忽略。

• 水平越权：同角色，A 用户可以查看 / 修改 B 用户数据。普通用户 A 修改请求里 user_id=2，直接访问用户 2 订单信息。
• 垂直越权：低权限普通用户，访问管理员接口，执行管理员操作。
• 未授权访问：没有登录校验，直接访问后台管理接口。

❌典型错误逻辑：
接口接收前端传过来的orderId，直接查询数据库，没有校验当前登录用户是否属于这条订单的拥有者。

//高危！只根据orderId查询，没有和当前登录用户绑定 Order order = orderMapper.selectById(orderId);

✅正确逻辑：每一个涉及用户私有资源的接口，拿到资源 ID 之后，必须结合当前登录会话中的 userId 做权限校验，不要信任前端传入的用户标识，必须从 session/token 会话里面获取真实登录身份。

//当前登录用户，从session/token获取，不是前端传参 Long loginUserId = (Long)session.getAttribute("userId"); Order order = orderMapper.selectById(orderId); if(order == null || !order.getUserId().equals(loginUserId)){ return Result.fail("无权访问"); }

未授权访问常见坑：后台接口忘记添加登录拦截器；静态资源、controller 接口忽略鉴权注解。SpringSecurity 开发注意不要写@PermitAll放开不该公开的接口。

开发自测越权小技巧：登录 A 账号拿到订单 ID，复制 ID，打开 B 账号，手动传入这个 ID 调用接口，看是否可以访问成功。

6. CSRF、CORS 跨域配置错误防护方案

6.1 CSRF 跨站请求伪造

原理：用户登录网站后，访问恶意网站，恶意网站自动发起请求，利用浏览器 Cookie 自动携带，执行业务操作。

高危场景：修改密码、绑定手机号、支付、重要业务提交接口。

✅防御手段：

1. 状态改变接口，增加 CSRF‑Token，服务端校验 token；token 不能放在 Cookie，需要放在请求体 /header；
2. Cookie 设置 SameSite 属性SameSite=Strict/Lax；
3. 重要操作增加验证码、二次确认。

SpringSecurity 默认开启 CSRF 防护，不要随意关闭 csrf ().disable ()。

误区：仅仅校验 Referer。Referer 可以被攻击者伪造，不能作为唯一防护。

6.2 CORS 跨域配置错误

很多开发为了解决前后端跨域，直接配置允许全部来源Access‑Control‑Allow‑Origin: *；或者获取请求 Origin 直接回写，没有校验，造成 CORS 漏洞，攻击者恶意域名可以读取接口返回的用户敏感数据。

❌高危错误 Java 伪代码

//高危，直接把请求Origin返回 response.setHeader("Access‑Control‑Allow‑Origin",request.getHeader("Origin"));

✅安全配置：

1. 允许的域名配置固定白名单列表，判断 Origin 是否在白名单，再设置响应头；
2. 不要同时配置*和Allow‑Credentials:true，标准不允许；
3. 线上环境禁止允许任意 Origin。

List<String> allowOriginList = Arrays.asList("https://a.com","https://b.com"); String origin = request.getHeader("Origin"); if(allowOriginList.contains(origin)){ response.setHeader("Access‑Control‑Allow‑Origin",origin); response.setHeader("Access‑Control‑Allow‑Credentials","true"); }

7. 业务逻辑漏洞：验证码、密码重置、重复提交

业务逻辑漏洞没有标准 Payload，完全是业务设计缺陷，扫描器很难检测，但是 SRC 上报占比极高。

7.1 验证码相关漏洞高频坑

1. 验证码客户端校验，后端不校验：前端删掉验证码参数直接提交成功；
2. 验证码复用，不销毁：同一个验证码可以无限次使用；
3. 验证码弱，4 位纯数字，无频率限制，可以暴力爆破；
4. 返回包直接返回验证码；
5. 密码重置，验证码绑定手机号，但是修改请求中的手机号，用 A 收到的验证码修改 B 账号密码。

✅安全编码规范：

• 验证码生成存储在服务端 session/redis，提交时后端校验，校验通过立即销毁验证码；
• 限制同一个手机号获取验证码频率；限制验证码有效期；
• 验证码校验时，必须绑定对应的账号，不能只校验验证码本身。

7.2 密码重置漏洞

常见缺陷：重置链接的参数使用用户 id，没有随机 token；攻击者遍历 id 批量重置账号；重置 token 长期有效。

✅修复：生成高熵随机 uuid token 存入数据库，设置过期时间，不要使用自增 id 作为重置凭证。

7.3 业务重复提交、逻辑绕过

比如：低价购买商品、优惠券重复领取，前端限制，后端没有幂等校验；攻击者重复发包多次领取优惠券。
✅修复：后端增加幂等、事务锁，数据库唯一约束，不能只依靠前端按钮置灰。

开发测试逻辑漏洞思路：修改 http 请求每一个参数，观察业务逻辑会不会发生预期之外变化。

8. 反序列化、XXE 高危漏洞开发避坑

8.1 Java 反序列化

不要反序列化不可信的外部输入数据。
ObjectInputStream.readObject()直接解析 http 传来的数据会触发反序列化 RCE。

• 禁止直接反序列化外部可控数据；
• 如果业务需要序列化传输，使用 JSON 替代原生 Java 序列化；
• 开启序列化白名单校验。

8.2 XXE XML 外部实体注入

解析 XML 文档，如果开启外部实体，攻击者构造 XML 读取服务器本地文件。

Java 中 SAX、DocumentBuilder 解析 XML，默认部分版本开启外部实体。
✅修复：解析 XML 时，关闭 DTD、外部实体解析。

SpringBoot 中如果接收 XML 请求，注意配置关闭外部实体；业务尽量优先使用 JSON，减少 XML 解析。

PHP libxml 处理 XML，禁止加载外部实体。

9. 开发高频踩坑清单：那些自以为安全的错误写法

很多漏洞并不是完全不懂安全，而是一些想当然的错误认知，整理开发高频踩坑点。

1. ❌“前端已经校验过，后端不用校验” →所有输入后端必须二次校验，前端只是体验优化
2. ❌“加了 WAF，代码漏洞没关系” → WAF 可以被编码、变形绕过，代码层才是根本修复
3. ❌“黑名单过滤危险字符就安全” → 黑名单永远绕不完，优先白名单校验
4. ❌Mybatis 使用({}接收业务参数，以为框架可以防注入 →\){}直接字符串拼接，会产生注入
5. ❌文件上传只校验后缀名，不校验文件内容，上传目录允许脚本解析
6. ❌越权接口，直接使用前端传入 user_id、order_id，不结合登录会话身份校验
7. ❌CORS 跨域直接把 Origin 请求头原样返回，不做域名白名单
8. ❌验证码校验完成不销毁，支持重复使用
9. ❌日志打印用户密码、token 等敏感信息，造成日志泄露
10. ❌接口错误堆栈直接返回给前端，泄露服务器路径、类名、版本信息；生产环境关闭详细异常栈，统一返回业务错误码。
11. ❌Cookie 不设置 HttpOnly，XSS 盗取 Cookie；重要 Cookie 配置 HttpOnly、Secure 属性。
12. ❌把密钥、数据库密码硬编码写在代码里面，上传 git，密钥泄露。密钥放到环境变量、配置中心，禁止提交到版本仓库。

10. 框架层面安全最佳实践（SpringBoot / PHP）

10.1 SpringBoot 开发安全要点

1. 优先使用 SpringSecurity，不要手写登录鉴权；不要随意关闭 csrf；
2. 鉴权注解不要遗漏，controller 方法粒度控制权限，不要依赖前端隐藏按钮；
3. 使用 JSR‑303 参数校验@Valid，后端做参数校验，长度、格式、非空；
4. 生产关闭 banner，关闭详细异常堆栈输出，统一全局异常处理器；
5. 添加安全响应头：X‑Frame‑Options、X‑Content‑Type‑Options、Content‑Security‑Policy；
6. 依赖组件定期升级，避免 log4j2、fastjson 等组件漏洞；定期扫描第三方依赖漏洞。

10.2 PHP 开发安全要点

1. 禁止使用原始 mysql_query，使用 PDO 预编译；
2. php.ini 关闭危险函数disable_functions：exec、system、passthru 等不需要的系统函数；
3. 关闭错误回显 display_errors=Off，生产环境不要输出 PHP 报错；
4. 文件上传目录禁止 php 脚本执行权限；
5. 不要使用 $_REQUEST 接收全部参数，明确 GET/POST 来源。

框架不等于自动安全，框架提供防护，但是开发者人为绕过框架能力（手动拼接 SQL、拼接命令）依旧会产生高危漏洞。

11. 软件研发流程中如何嵌入安全，左移安全

安全不应该等到测试、上线之后再发现修复，要 “安全左移”，在需求、开发阶段就考虑安全。

1. 需求阶段：涉及登录、密码重置、上传、支付、权限管理的需求，同步思考安全风险点；
2. 开发编码阶段：开发人员掌握基础安全编码规范；复制网上 Demo 代码，确认 Demo 是否存在安全漏洞；
3. 代码评审环节：安全敏感接口增加安全评审点，重点看：SQL 拼接、文件上传、权限校验、外部输入处理；
4. 测试阶段：不仅仅测试功能是否正常，补充安全测试用例；越权、验证码、注入、上传；
5. 上线前：依赖漏洞扫描；使用 SAST 静态代码扫描工具扫描代码；
6. 上线后：定期更新组件版本，关注漏洞通告；收到 SRC 漏洞反馈及时修复更新。

很多公司把安全全部交给安全团队，但业务代码量巨大，安全团队无法全部覆盖，每一个开发人员才是安全第一道防线。

12. 上线前自查安全 Checklist，直接复制使用

开发完成上线前，对照清单快速自查接口安全：

输入校验

• 所有 HTTP 输入，后端全部校验，不依赖前端校验
• SQL 全部使用预编译，禁止直接字符串拼接；排序表名做白名单
• 系统命令调用尽量避免，必须调用做严格白名单过滤

文件功能

• 文件上传：后缀白名单，重新生成随机文件名，校验文件内容；上传目录关闭脚本执行
• 文件下载：防止路径穿越，不直接接收文件名参数

权限访问控制

• 所有私有资源接口，做身份鉴权；从会话获取登录用户，不相信前端传入用户 ID
• 测试水平、垂直越权：切换账号修改资源 ID 访问接口
• 后台接口没有忘记鉴权、没有 PermitAll 误放开

业务逻辑

• 验证码后端校验，校验完成销毁，绑定账号，有过期时间，防暴力
• 密码重置使用随机 Token，不使用自增 ID
• 重复操作接口增加幂等、锁处理

Web 头与 Cookie

• CORS 配置域名白名单，不直接回写 Origin
• 敏感 Cookie 设置 HttpOnly、Secure
• 添加基础安全响应头，关闭 X‑Powered‑By 版本泄露
• 生产环境不输出详细异常堆栈

其他

• 密钥密码不硬编码在代码，不提交 git
• 第三方依赖组件版本定期更新，排查高危组件漏洞

13. 写在最后：安全不是附加功能，是业务的一部分

很多开发同学觉得安全是额外的负担，优先保证功能跑通，安全以后再说。但线上一旦出现高危漏洞，会带来用户数据泄露、业务被入侵、合规处罚、品牌受损，修复漏洞的成本远高于开发阶段规避漏洞的成本。

从白帽挖洞视角看，大部分高危漏洞都不是高深的 0day，都是简单的编码疏忽：没有做后端校验、直接拼接 SQL、没有做越权判断、上传没有严格限制。攻击者利用这些简单缺陷，就可以造成巨大的业务损失。

安全不是安全工程师一个团队的事情，而是每一个研发人员的责任。掌握基础安全编码思维，写代码的时候多思考一句：这个参数来自外部，攻击者篡改这个参数会发生什么问题？

WAF、安全设备属于 “防御盾牌”，而健壮安全的业务代码才是根基。希望本文可以帮助开发同学理解攻击者视角，在编码阶段规避绝大多数 Web 高危漏洞。

最后

关于网络安全技术储备

学好网络安全不论是就业还是做副业赚钱都不错，但要学会网络安全还是要有一个学习规划。最后大家分享一份全套的网络安全学习资料，给那些想学习网络安全的小伙伴们一点帮助！

对于0基础小白入门：

如果你是零基础小白，想快速入门网络安全是可以考虑的。

一方面是学习时间相对较短，学习内容更全面更集中。

二方面是可以找到适合自己的学习方案

包括：网安成长学习路线图、SRC&黑客文档、护网行动、黑客必读书单、面试题、学习视频等教程。带你从零基础系统性的学好网络安全！

需要的可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

👉1.成长路线图&学习规划👈
要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

👉2.网安入门到进阶视频教程👈
很多朋友都不喜欢晦涩的文字，我也为大家准备了视频教程，其中一共有21个章节，每个章节都是当前板块的精华浓缩。（全套教程文末领取哈）

👉3.SRC&黑客文档👈
大家最喜欢也是最关心的SRC技术文籍&黑客技术也有收录

SRC技术文籍：

黑客资料由于是敏感资源，这里不能直接展示哦！（全套教程文末领取哈）

👉4.护网行动资料👈
其中关于HW护网行动，也准备了对应的资料，这些内容可相当于比赛的金手指！

👉5.黑客必读书单👈

随着互联网技术的飞速发展，网络安全已经成为了当今科技领域的一大热点。这些SQL注入、CCNA、Web渗透、Linux服务器等，以其强大的语言理解和防御能力，正在守护着我们网络世界。 那以下这些PDF籍就是非常不错的学习资源。

👉6.网络安全岗面试题合集👈
当你自学到这里，你就要开始思考找工作的事情了，而工作绕不开的就是真题和面试题。

这份完整版的网络安全学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】