Web安全实战：SQL注入与XSS攻击防御指南

1. 漏洞攻防实战：从三个典型案例看Web安全防护

刚入行时我总以为黑客攻击离普通开发者很远，直到亲眼目睹公司官网被篡改成赌博页面，才意识到安全防护的紧迫性。今天就用我亲历的三个真实案例，带你看懂SQL注入和XSS这两种最常见攻击手法的运作原理与防御之道。

2. 案例一：万能密码背后的SQL注入漏洞

2.1 漏洞现场还原

某电商平台后台系统突然出现多个管理员账号异常登录，攻击者无需密码就能直接进入后台。排查日志发现登录SQL语句被篡改为：

sql复制SELECT * FROM users WHERE username='admin'--' AND password='xxx'

--注释符使密码验证失效，这就是典型的SQL注入。

2.2 攻击原理拆解

1. 字符串拼接漏洞：系统使用字符串拼接生成SQL

   python复制sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
   

2. 恶意输入构造：攻击者输入admin'--作为用户名
3. 语句语义篡改：最终SQL变成验证用户名后注释掉密码检查

2.3 防御方案实施

我们采用三层防护：

1. 预处理语句（首选方案）：

   python复制cursor.execute("SELECT * FROM users WHERE username=%s AND password=%s", (username, password))
   

2. 输入过滤：对特殊字符如单引号进行转义
3. 最小权限原则：数据库账户仅赋予必要权限

关键教训：永远不要相信用户输入，参数化查询是底线要求

3. 案例二：存储型XSS导致的持久化攻击

3.1 事故现象

用户反馈商品评论区出现自动跳转的钓鱼链接，检查发现攻击者在评论中植入：

html复制<script>window.location="https://钓鱼网站.com"</script>

3.2 攻击链分析

1. 恶意脚本存储：攻击脚本被存入数据库
2. 未过滤渲染：前端直接显示原始HTML
3. 受害者触发：其他用户浏览时自动执行脚本

3.3 解决方案对比

最终我们选择组合方案：基础内容使用转义，富文本区域采用DOMPurify过滤+ CSP策略。

4. 案例三：反射型XSS的钓鱼攻击

4.1 攻击过程重现

用户收到伪装成官方的邮件：

code复制尊敬的客户，请点击验证链接：
https://真实网站.com/search?q=<script>窃取cookie代码</script>

点击后脚本执行，窃取用户会话cookie。

4.2 技术要点解析

1. 非持久化攻击：恶意脚本通过URL参数传递
2. DOM型变异：现代前端框架可能产生变异攻击

   javascript复制// 危险示例
   document.write('搜索结果：' + decodeURIComponent(q)) 
   

4.3 进阶防御措施

1. HttpOnly Cookie：防止JavaScript读取敏感cookie
2. X-XSS-Protection：启用浏览器内置防护
3. URL参数校验：服务端验证参数格式合法性

5. 企业级防护体系搭建

5.1 安全开发生命周期

1. 需求阶段：进行威胁建模（STRIDE方法）
2. 开发阶段：使用ESLint插件检测安全风险
3. 测试阶段：采用ZAP等工具进行渗透测试

5.2 监控与应急

1. 日志监控：建立SQL异常语句检测规则
2. WAF配置：关键正则表达式示例：

   code复制(?:union[\s\/\*].*select|(?:select|insert|update).*?(?:from|into|set)\W)
   

3. 漏洞赏金计划：鼓励白帽黑客提交漏洞

6. 开发者自查清单

6.1 SQL注入防护

• [ ] 是否所有SQL都使用参数化查询？
• [ ] ORM是否启用安全模式？
• [ ] 数据库错误信息是否暴露给前端？

6.2 XSS防护

• [ ] 所有动态内容是否经过转义或过滤？
• [ ] CSP策略是否适当配置？
• [ ] 是否禁用eval()等危险函数？

曾经有团队在修复XSS时漏掉了JSONP接口，导致防护体系功亏一篑。安全防护必须做到360度无死角，任何一个疏漏都可能成为攻击入口。建议每月进行一次完整的安全审计，毕竟在网络安全领域，防御者必须永远正确，而攻击者只需要成功一次。