一、开篇：两类漏洞，撑起了十堰企业网站事故的大半

在做十堰网络安全应急响应的几年里，我们统计过经手的网站入侵事件：真正由 0day 漏洞或高级可持续攻击造成的，不到 10%；剩下的大多数，源头都是两个"老掉牙"的问题——SQL 注入和 XSS 跨站脚本。它们常年稳居 OWASP Top 10，原理二十年没变，可每年仍然有大量十堰本地企业的官网、商城、报名系统栽在上面。

原因很朴素：这两类漏洞不靠高深技术，靠的是开发时一行代码写错。把用户输入直接拼进 SQL 语句，攻击者就能牵着数据库走；把用户输入原样输出到页面，攻击者就能在你的域名下执行任意脚本。本文不讲空话，直接给代码、给配置、给清单，十堰的开发和运维同学可以照着改。

二、SQL 注入：让数据库"听攻击者的话"

2.1 漏洞是怎么产生的

看一段国内中小企业系统里极常见的 PHP 代码，功能是根据 ID 查询新闻详情：

// ❌ 危险写法：用户输入直接拼接进 SQL
$id = $_GET['id'];
$sql = "SELECT * FROM news WHERE id = $id";
$row = mysqli_query($conn, $sql);

正常访问 /news.php?id=12 时，SQL 是 SELECT * FROM news WHERE id = 12，看起来没问题。但攻击者把 id 换成：

/news.php?id=0 UNION SELECT username, password, 1, 1, 1 FROM admin_users

拼出来的语句就变成了两条查询的联合，管理员账号和密码哈希被直接回显到页面上。如果页面不回显，攻击者还可以用布尔盲注、时间盲注一位一位地把数据"问"出来——只是慢一点，结果一样。

2.2 一次注入能造成多大损失

拖库：用 UNION SELECT 或 information_schema 枚举，把用户表、订单表、后台账号整表导出；
绕过登录：在登录框用户名处填 admin' -- ，把后面的密码校验条件注释掉，直接以管理员身份进入；
写文件拿服务器：数据库账号若有 FILE 权限，可通过 INTO OUTFILE 往 Web 目录写一句话木马，从"数据泄露"升级为"服务器失守"；
删库：id=1; DROP TABLE orders--，一次误操作级别的破坏。

对十堰的制造、商贸类企业来说，订单表和客户联系方式一旦泄露，往往伴随精准诈骗电话和同行撬单，损失远不止"修个网站"那么简单。

2.3 根治手段：参数化查询（预编译）

防御 SQL 注入没有"过滤关键字"这种捷径——黑名单永远可以被 /**/、大小写、URL 编码、宽字节绕过。唯一可靠的做法是让数据和 SQL 语句结构彻底分离，也就是参数化查询。

PHP + PDO 的正确写法：

// ✅ 占位符 + 绑定参数，用户输入永远只是"值"
$stmt = $pdo->prepare('SELECT * FROM news WHERE id = ?');
$stmt->execute([(int)$_GET['id']]);
$row = $stmt->fetch();

Java + MyBatis 的关键差异：

<!-- ❌ ${} 是字符串拼接，等于把注入口敞开 -->
SELECT * FROM news WHERE title LIKE '%${keyword}%'

<!-- ✅ #{} 走 PreparedStatement，自动转义 -->
SELECT * FROM news WHERE title LIKE CONCAT('%', #{keyword}, '%')

很多项目出问题就出在模糊查询用了 ${}，因为 #{} 加引号后 LIKE 不好写，开发者图省事换成了拼接。正确做法是用 CONCAT 把通配符拼在 SQL 侧，而不是拼在参数侧。

Node.js + mysql2：

// ✅ 用 ? 占位符，禁止模板字符串拼 SQL
const [rows] = await pool.query('SELECT * FROM news WHERE id = ?', [req.query.id]);

2.4 兜底防线：最小权限与错误信息收敛

参数化查询是第一道墙，但项目里难免有历史遗留的拼接代码。建议同时做三件事把损失控制在最小：

数据库账号最小权限：网站连接数据库的账号只给 SELECT/INSERT/UPDATE/DELETE，绝不给 DROP、FILE、GRANT；后台管理和前台展示最好用两个不同账号。
关闭详细报错：生产环境把 PHP 的 display_errors 关掉，Java 统一异常处理，别把 SQL 语句和表名回显给用户——报错信息本身就是注入的"导航地图"。
WAF 规则兜底：在 Nginx 前置 ModSecurity 或云 WAF，开启 OWASP CRS 规则集，能拦住绝大多数自动化注入扫描器。

三、XSS：在你的域名下执行别人的代码

3.1 三种类型，一句话区分

反射型：恶意脚本藏在 URL 参数里，诱导用户点击才触发，比如搜索页把关键词原样回显；
存储型：脚本被存进数据库（评论、留言、昵称、商品标题），每个访问页面的用户都会中招，危害最大；
DOM 型：服务端没参与，前端 JS 直接把 location.hash 塞进 innerHTML 导致执行。

攻击者拿到的是什么？是你网站用户的登录 Cookie。脚本 document.cookie 一发到攻击者服务器，用户的登录态就被劫持了；再进一步，可以在页面伪造登录框钓密码，或调用站内接口替用户下单、改资料。对十堰做会员商城、预约报名类小程序和网站的企业，这类问题一旦被用户发现，口碑损失很难挽回。

3.2 防御一：输出转义（按上下文转义）

XSS 的根因在"输出"，不在"输入"。所有来自用户的内容，输出到 HTML 时都要转义：

// PHP：输出到 HTML 上下文
echo htmlspecialchars($nickname, ENT_QUOTES, 'UTF-8');

// 前端：优先用 textContent，而不是 innerHTML
el.textContent = nickname;   // ✅
el.innerHTML = nickname;     // ❌ 用户能输入 <img src=x onerror=alert(1)>

Vue 的 v-html、React 的 dangerouslySetInnerHTML、小程序的 rich-text，本质上都是"我信任这段 HTML"，只要数据来自用户就必须先做白名单净化（如 DOMPurify），不能直接塞。

3.3 防御二：CSP 内容安全策略

即使有一处漏转义，CSP 也能让注入的脚本执行不了。在 Nginx 里加一行响应头即可：

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-随机值'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'" always;

含义是：脚本只允许从本站加载且必须带正确 nonce，禁止 object 标签，禁止改 base。建议先用 Content-Security-Policy-Report-Only 模式跑一周，收集违规报告确认不影响业务后再正式开启。

3.4 防御三：Cookie 三件套

Set-Cookie: SESSIONID=xxx; HttpOnly; Secure; SameSite=Lax; Path=/

HttpOnly 让 JS 读不到 Cookie，脚本即使执行了也偷不走登录态；Secure 保证只走 HTTPS；SameSite=Lax 顺带挡住大部分 CSRF。这三项配置成本几乎为零，却是性价比最高的加固。

四、上线前的 8 项自查清单

全站搜索 SELECT、UPDATE、DELETE 关键字，确认没有字符串拼接变量；
MyBatis 的 XML 里检查是否还有 ${，尤其 LIKE、ORDER BY、表名拼接处（排序字段要用白名单映射）；
用 sqlmap 对登录、搜索、详情页做一次授权扫描，确认无可注入点；
所有用户输入的回显点，检查是否经过 HTML 转义；富文本用 DOMPurify 白名单净化；
配置 CSP、X-Content-Type-Options: nosniff、X-Frame-Options: SAMEORIGIN；
Session Cookie 开启 HttpOnly + Secure + SameSite；
数据库账号降权，关闭生产环境详细报错与调试模式；
接入 WAF 并开启日志告警，重点监控含 union、sleep(、<script 的请求。

五、十堰本地案例复盘：一个搜索框带来的拖库

去年我们接手十堰一家商贸企业的官网+订单系统。入侵路径非常典型：官网顶部搜索框的接口用字符串拼接实现模糊查询，攻击者用 sqlmap 十几分钟就跑出了管理员表和 8000 多条客户订单。更麻烦的是，攻击者用注入点写入了 WebShell，服务器被当作跳板扫描内网。

处置过程分四步：先断网隔离、保留镜像取证；再定位并修复全部拼接 SQL，改用参数化查询；然后清理 Webshell、重置所有数据库与后台密码、给数据库账号降权；最后部署 WAF 并加上 CSP 与 Cookie 加固。整个修复耗时两天，但客户因数据泄露做的用户告知和补偿，成本是这个数字的几十倍。安全投入永远比事故成本便宜，这也是我们给十堰企业做安全评估时反复强调的一句话。

六、结语：把安全做进代码，而不是贴在墙上

SQL 注入和 XSS 都不是"高不可攀"的攻击，它们的门槛低到用现成工具就能批量扫描；同理，防御也不需要采购昂贵设备——参数化查询 + 输出转义 + CSP + 最小权限这四件事做到位，就能挡掉 90% 以上的真实攻击。对于正在做网站、商城、小程序和内部管理系统的十堰企业，建议把上面那份 8 项清单直接放进上线流程，每次发版前过一遍。代码写得规范一点，比事后应急便宜得多。

如果你不确定手上的系统是否存在这类问题，可以先做一次授权渗透测试和代码审计——先知道风险在哪，再决定钱花在哪。

十堰企业网站安全加固实战：SQL注入与XSS攻击的原理、代码级防御与上线自查清单（2026版）