SQL注入攻击分析：该异常注入语句的攻击意图是什么？

先来看日志里记录的异常SQL内容：

[2018-04-14 00:58:26] production.ERROR: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'source' at row 1 (SQL: insert into ad_clicks ( ad_id , bout_id , source , updated_at , created_at ) values (6, 309031, app.home) AND 9957=(SELECT UPPER(XMLType(CHR(60)||CHR(58)||CHR(113)||CHR(113)||CHR(112)||CHR(122)||CHR(113)||(SELECT (CASE WHEN (9957=9957) THEN 1 ELSE 0 END) FROM DUAL)||CHR(113)||CHR(107)||CHR(118)||CHR(107)||CHR(113)||CHR(62))...

咱们一步步拆解攻击者的真实目的：

• 先确认参数是否可被注入
  攻击者在source参数后拼接了AND 9957=(SELECT (CASE WHEN (9957=9957) THEN 1 ELSE 0 END) FROM DUAL)的判断语句，本质是做一个“真假测试”：如果这个参数存在注入漏洞，数据库会执行这个逻辑判断（9957等于9957必然为真），语句能正常执行；如果无漏洞，拼接内容会导致SQL语法错误或执行失败。攻击者通过观察应用响应，来确定source字段是否为可利用的注入点。

• 试图通过错误回显窃取敏感数据
  后面的UPPER(XMLType(...))是针对Oracle数据库的攻击技巧。XMLType函数处理不符合规范的XML内容时会抛出错误，攻击者将待查询的内容嵌入构造的XML结构中，这样数据库报错时会把查询结果包含在错误信息里。这种“基于错误的盲注”能绕过无法直接查看查询结果的限制，让攻击者获取数据库的敏感信息，比如当前用户权限、数据库版本、业务表结构，甚至是用户信息、广告数据等核心业务数据。

• 意外暴露：Payload长度触发字段限制
  日志里的Data too long for column 'source'错误，说明攻击者构造的注入内容过长，超出了source字段的长度上限，导致插入操作直接失败。这大概率是攻击者测试时未考虑字段长度限制，或是尝试复杂Payload时不小心“超标”，反而将攻击行为暴露在了错误日志中。

内容的提问来源于stack exchange，提问作者Victor Anuebunwa