诡异，java连接sql中 distinct 不生效，jdbc方式连接，用的是2000的数据库

Posted 2023-05-08

我的数据库有358条记录，
我在查询分析器中用
select distinct 字段 from BusinessIonfo where 1=1
得到的结果是65条。
但是同样的语句在java程序中得到的效果确实
select 字段 from BusinessIonfo where 1=1
我确认传入的语句没有问题，求高手啊

参考技术A 先创建一个视图：
create view bus_view
as
select distinct * from
BusinessIonfo(nolock) where 1=1

在JAVA中用下面的语句看看

SELECT *FROM bus_view
where 1=1 参考技术B 你的问题是想问什么是distinct 在sql语句中在数据库中执行时 不起作用 还是在java中 不起作用哦
java 中的sql语句没有加distinct哦追问

晕，那java如何去除重复列啊？这个语句，在查询分析器中有效果，在java中报报错，但是也不生效啊

追答

java中的就是关于查询这块代码你是怎么写的贴出来哦

追问

我的其他语句执行都没有问题，只是这个关键字有问题，在java里面，传入的语句是
select distinct 字段 from BusinessIonfo where 1=1
其效果是：
select 字段 from BusinessIonfo where 1=1
但是我把语句改为：
select max(字段) from BusinessIonfo where 1=1 groupby 字段
就得到了我要的效果，这个，是为什么啊？

但是我用查询分析器，都是对的

本回答被提问者采纳 参考技术C 查询分析器中如果可以，java肯定可以，不知报什么错，不便回答。另一实现方式：select 字段 from BusinessIonfo group 字段。追问

现在就是，查询分析器可以，java不可以，不报错，只是结果不对，你的实现方式，经过测试，是可以的。

参考技术D 完整的SQL是什么？

当SQL注入遇到诡异的编码问题

前言

最近给甲方爸爸做渗透测试时发现了一个诡异的SQL注入，之所以说诡异，是因为该系统数据库连接编码与实际的数据库编码不一致，并且数据库表字段名使用了中文的字段名，导致通过正常手段无法获取到数据库数据。

故事开始

1、拿到资产清单后，发现有这样一个站。

2、简单测试了一下，发现该页面无验证码，无密码验证次数限制，可进行暴力破解，但进行了一波爆破后，并未得到可用账号。

3、通过系统资产表得到负责人和维护人的手机号。

4、使用负责人的手机号为账号，暴力破解得到弱口令186xxxxxxxx/12345678登录系统。

5、简单看了下页面，发现以下页面存在base64编码的sid参数，解码为手机号186xxxxxxxx，改为186xxxxxxxx’再编码发送会报错。

6、看到这里心里大喜，显然这里应该存在基于错误显示的SQL注入，话不多说，SQLMAP一把梭，成功跑出了注入点并且得知该数据库用户是管理员。

sqlmap -r sql.txt -p sid --tamper base64encode --technique Esqlmap -r sql.txt -p sid --tamper base64encode --technique E --is-dba

7、至此这个漏洞算是存在了，本不想深挖，但是又发现该系统存在一个后台页面，于是想从数据库中拿个账号登陆看看。

8、当我熟练地拿起SQLMAP跑出字段名时，我惊呆了，这开发大哥居然用的中文字段名。

sqlmap -r sql.txt -p sid --tamper base64encode --technique E -D CANTEEN -T XXX_INFO_USER --columns

9、照着平常的命令dump几条数据看看，果然跑不出来。

sqlmap -r sql.txt -p sid --tamper base64encode --technique E -D CANTEEN -T XXX_INFO_USER -C 工号,密码 --start 1 --stop 3 --dump

10、刚开始我以为只是SQLMAP对中文的兼容性问题，尝试了以下几种方法，都没有成功：

不使用报错回显注入，使用布尔盲注的方式

在Linux上面跑

—encoding GBK/—encoding UTF-8等

设置cmd页面编码为utf8

11、于是使用SQLMAP调试输出看看数据包，发现了奇葩的事情，报错页面居然存在两种编码！

sqlmap -r sql.txt -p sid --tamper base64encode --technique E -D CANTEEN -T XXX_INFO_USER -C 工号,密码 --start 1 --stop 3 --dump -v 7

12、为了验证我的猜想，在burpsuite上面把SQLMAP的请求重放看看。果然，web数据库连接编码与后台数据库编码不一致。当前burp设置的编码为utf8，所以猜测下图中乱码部分的编码为gbk。而图11中红框部分编码正常部分恰好是burp乱码部分，所以推测SQLMAP应该是使用了gbk解码显示。

13、看到这里，我有一句mmp不知当讲不当讲。吐槽完毕，还是乖乖地想起了应对方法，毕竟砖还是要搬的。重新梳理了一下字符的编码转换过程，对字段名做了个编码，如下。对的，你没有看错，确实是编码成了一个不正常的字符，SQLMAP正确识别出了编码，成功跑出了数据：

sqlmap -r sql.txt -p sid --tamper base64encode -T XXX_INFO_USER -C 宸ュ彿,瀵嗙爜 --start 1 --stop 3 --dump

原理解析

1、从上面实验中，我猜测WEB中间件连接数据库的编码为gbk，而数据库字段名的实际编码为utf8。

2、梳理一下从用户发起HTTP请求到数据库中间的数据流，其关键的编码过程如下（以下仅为本人不太专业的理解，不一定准确）。关键问题在于，SQLMAP输入的payload经过gbk编码成字节流，然后被数据库以utf8解码。

3、既然知道了编码的逻辑，那么通过反向编码就可以让数据库拿到正确的中文字符串了。举个例子，如果密码两个字要被数据库解码，那么它的字节流应该是xe5xafx86xe7xa0x81。

ss = '密码'e = s.encode('utf-8')print(e)

4、而字符串瀵嗙爜通过gbk编码后的字节流也是xe5xafx86xe7xa0x81，所以数据库能够把中文字段名正确地查询：

5、所以r0yanx才有了上面的操作，把中文字符串先进行utf8编码再进行gbk解码得到字符串，Python示例代码为：

#!/usr/bin/pythons = '密码'e = s.encode('utf-8')print(e.decode('gbk'))

FreeBuf+ FreeBuf+小程序：把安全装进口袋 Mini Program

精彩推荐