第七节 宽字符

### 关于iwebsec靶场中字符型SQL注入漏洞分析 在探讨iwebsec靶场中的字符型SQL注入漏洞时，需理解其核心在于利用特定字符串构造来绕过输入验证机制并执行恶意查询。当应用程序未能正确处理特殊字符或未对用户输入做充分过滤时，攻击者可以通过提交精心设计的数据引发数据库错误或获取敏感信息。 对于字符型注入而言，在构建测试用语句时通常会附加单引号 `'` 来闭合原有查询条件，并通过联合选择 `UNION SELECT` 或其他方法尝试读取额外的信息[^5]。例如： ```sql ?id=1' UNION SELECT 1,2,3--+ ``` 此命令试图关闭原始查询并通过追加新的SELECT子句返回自定义的结果集；然而，如果结尾处缺少必要的注释符号（即双连字符 `--`），这可能导致语法不匹配从而引起服务器端异常响应。 为了进一步探索目标系统的结构以及潜在的安全弱点，可以采用如下策略来进行更深入的渗透测试： - **确认注入点**：先确定是否存在可被利用的位置，比如上述提到的ID参数。 - **探测列数**：使用ORDER BY指令调整输出顺序直至找到最大有效索引值，以此推断出内部表格所含有的字段数目。如下面的例子展示了如何检测第四列为上限的情况： ```php /sqli/02.php?id=-1%df%27%20order%20by%204--+ ``` - **提取元数据**：一旦知道了表内有多少个属性，则可通过GROUP_CONCAT()函数一次性抓取多个记录的内容。这里给出了一种方式用于收集用户名和密码组合： ```sql ?id=-1 UNION SELECT 1,2,GROUP_CONCAT(CONCAT_WS(0x7E,username,password)) FROM iwebsec.user-- ``` 值得注意的是，以上操作均基于假设环境下的实验性质活动，并非真实世界里的合法行为。实际开发过程中应当遵循安全编码实践以防止此类风险的发生，同时定期审查现有防护措施的有效性。 #### 宽字节注入技巧 考虑到某些情况下Web应用可能运行在一个特殊的字符集环境中（如GBK），此时还可以运用所谓的“宽字节注入”。这种技术依赖于多字节字符集中存在的特性——部分字符由两个连续字节组成，其中一个可能是反斜杠 `\` ，它作为转义符会影响后续字符解释的方式[^4]。 具体来说就是发送形似 `%DF'` 的请求片段给服务端解析器，后者会在遇到这样的序列之前插入一个反斜杠变成类似于 `%DF\%'` 这样的形式。而在GBK编码下，这个新产生的三字节串正好对应着某个有效的汉字，因此整个表达式不会触发任何报警而是按照预期逻辑继续向下执行下去。