Web 安全面试题解析：XSS、SQL 注入与 Linux 加固

Web 安全是后端开发、运维和渗透测试岗位面试中的核心考察模块。本文围绕三个高频考点展开：XSS 的攻击方式与前端防御、MySQL 中防止 SQL 注入的编码实践，以及 Linux 服务器的安全加固清单。每个部分都结合面试中常见的追问角度进行解析。

一、XSS 的常见方式与前端防御

1.1 XSS 的三种类型

XSS（跨站脚本攻击）的本质是攻击者将恶意脚本注入到网页中，使其在其他用户的浏览器上执行。面试中通常要求区分以下三类：

• 存储型 XSS：恶意脚本被持久化存储在服务器端（如数据库、评论系统），所有访问该页面的用户都会触发。危害最大，常见于留言板、用户昵称等场景。
• 反射型 XSS：恶意脚本作为请求参数发送给服务器，服务器未经充分处理就将其反射回响应页面。通常需要诱导用户点击特制链接才能触发。
• DOM 型 XSS：漏洞完全发生在客户端，JavaScript 从 location.hash、document.referrer 等来源获取数据并直接插入 DOM，不经过服务器端渲染。

1.2 常见注入方式

攻击者的注入入口远比想象中多，面试中能列举出以下场景会加分：

• HTML 标签注入：<img src=x onerror=alert(1)>
• 属性注入：<a href="javascript:alert(1)"> 或利用未闭合的属性值逃逸
• 事件处理器注入：onmouseover、onfocus 等
• URL 注入：javascript: 伪协议
• CSS 注入：expression()（旧版 IE）或 background:url(javascript:...)

1.3 前端防御策略

前端防御的核心原则是永远不信任用户输入，永远不将不可信数据当作代码执行。

输出编码是最根本的手段。根据数据插入的上下文选择对应的编码方式：HTML 实体编码、JavaScript 字符串编码、URL 编码、CSS 编码。例如，将 < 编码为 <，" 编码为 "。

使用安全的 DOM API。避免使用 innerHTML、outerHTML、document.write() 直接插入用户数据，改用 textContent、innerText 或 createElement + setAttribute。

启用 CSP（内容安全策略） 。通过 HTTP 头 Content-Security-Policy 限制脚本来源，禁止内联脚本执行。例如：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com

输入验证与白名单。对用户输入进行格式校验，如邮箱、URL 等使用正则白名单过滤。但需注意，输入验证不能替代输出编码。

使用现代框架的自动转义。React、Vue 等框架默认对插值进行转义，但 dangerouslySetInnerHTML 和 v-html 会绕过保护，需配合 DOMPurify 等库进行净化。

面试追问点：CSP 能否完全防止 XSS？答案是否定的——CSP 是纵深防御的一层，但配置不当（如使用 unsafe-inline）或存在 JSONP 端点时仍可被绕过。

二、MySQL 防止 SQL 注入的几种写法

SQL 注入的根源是将用户输入拼接进 SQL 语句。以下从代码层面给出几种防御写法，按推荐程度排序。

2.1 参数化查询（Prepared Statement）

这是最有效、最推荐的防御方式。以 PHP PDO 为例：

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email AND status = :status');
$stmt->execute([':email' => $email, ':status' => 'active']);
$user = $stmt->fetch();

Java JDBC 的写法：

PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE email = ?");
ps.setString(1, email);
ResultSet rs = ps.executeQuery();

参数化查询将 SQL 语句结构与数据分离，数据库引擎先编译语句模板，再绑定参数值，参数永远不会被解释为 SQL 代码。

2.2 存储过程（需注意内部实现）

存储过程本身不自动免疫 SQL 注入。如果存储过程内部使用 CONCAT 拼接参数再执行动态 SQL，同样存在风险。安全的写法是直接使用参数：

CREATE PROCEDURE GetUser(IN user_email VARCHAR(255))
BEGIN
    SELECT * FROM users WHERE email = user_email;
END

2.3 ORM 框架的安全用法

使用 ORM 时，避免将用户输入直接拼接到原生 SQL 片段中。以 Django ORM 为例：

# 安全：使用参数化
User.objects.raw('SELECT * FROM users WHERE email = %s', [email])

# 危险：字符串拼接
User.objects.raw(f"SELECT * FROM users WHERE email = '{email}'")

2.4 输入验证与最小权限

• 类型校验：对整数型参数使用 intval() 或类型转换，确保输入符合预期格式。
• 最小权限原则：Web 应用连接数据库的账号只授予必要的 SELECT、INSERT、UPDATE 权限，禁用 DROP、FILE 等高危权限。
• 关闭错误回显：生产环境不向用户返回数据库错误信息，避免泄露表结构。

面试追问点：addslashes() 或 mysql_real_escape_string() 是否足够？在正确设置字符集（如 utf8mb4）且不使用 GBK 等宽字节字符集的前提下，转义函数可以防御大部分注入，但参数化查询仍是更可靠的选择，因为它不依赖字符集配置的正确性。

三、Linux 服务器安全加固清单

以下清单适用于面试中回答“如何加固一台对外提供 Web 服务的 Linux 服务器”。

3.1 账户与认证

• 禁用 root 远程 SSH 登录：PermitRootLogin no
• 使用密钥认证，禁用密码登录：PasswordAuthentication no
• 创建普通用户并通过 sudo 提权，遵循最小权限原则
• 设置强密码策略（pam_pwquality），定期轮换密钥
• 删除或锁定不必要的默认账户（如 lp、games）

3.2 网络与服务

• 配置防火墙（iptables/nftables/firewalld），仅开放必要端口（如 80、443、SSH 端口）
• 修改 SSH 默认端口，减少自动化扫描
• 使用 fail2ban 自动封禁暴力破解 IP
• 关闭不必要的服务：systemctl disable --now 无用单元
• 禁用 IPv6（如无需求）或同样配置防火墙规则

3.3 文件系统与权限

• 关键目录设置合理权限：/etc/shadow 为 640，/root 为 700
• 使用 chattr +i 锁定关键文件（如 /etc/passwd、/etc/shadow）防止未授权修改
• 为 /tmp、/var/tmp 挂载 noexec、nosuid、nodev 选项
• 定期审计 SUID/SGID 文件：find / -perm -4000 -type f

3.4 日志与监控

• 启用 auditd 审计关键系统调用和文件访问
• 集中收集日志到远程 syslog 服务器，防止攻击者清除本地日志
• 配置 logrotate 防止日志占满磁盘
• 监控异常登录、提权操作和端口监听变化

3.5 更新与补丁

• 启用自动安全更新（unattended-upgrades 或 dnf-automatic）
• 定期使用 lynis、OpenSCAP 等工具进行安全基线检查
• 订阅发行版安全公告，及时修补内核和关键组件漏洞

3.6 内核加固（sysctl）

net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

面试追问点：加固后如何验证效果？可以使用 nmap 扫描开放端口、lynis audit system 检查合规项、尝试用弱密码 SSH 登录验证 fail2ban 是否生效。

总结

XSS 防御的关键在于上下文相关的输出编码和 CSP；SQL 注入防御的首选是参数化查询，辅以最小权限和输入验证；Linux 加固则需要从账户、网络、文件系统、日志、补丁和内核参数多个层面建立纵深防御。面试中不仅要答出“怎么做”，更要解释“为什么这样做”以及“还有什么不足”，这往往是区分候选人水平的关键。

未经允许不得转载：任鹏个人博客 » Web 安全面试题解析：XSS、SQL 注入与 Linux 加固