How to get the RefType without import

[thanatoskira]

When I used CodeQL to search for Class in the project, I found that only the Class that was loaded in the source code through a similar import method can be successfully searched, so I want to ask if there is any way to include those Class that have not been introduced when generating the database.

For Example，Pom.xml contains the following dependencies：

<dependency>
  <groupId>org.apache.flink</groupId>
  <artifactId>flink-shaded-netty</artifactId>
  <version>4.1.39.Final-11.0</version>
</dependency>

When I use import org.apache.flink.shaded.netty4.io.netty.handler.codec.http.multipart.HttpPostStandardRequestDecoder; to import this class, I can search for HttpPostStandardRequestDecoder through the following CodeQL syntax

import java
from Package package, RefType reftp
where
    package.hasName("org.apache.flink.shaded.netty4.io.netty.handler.codec.http.multipart") and
    reftp.getPackage() = package
select reftp

But I still can’t get some other classes under the org.apache.flink.shaded.netty4.io.netty.handler.codec.http.multipart package, such as: MemoryFileUpload

[aschackmull]

Without more information I'd say that this is working as intended. We aim to only include necessary types in the database, so if a type isn't used in the analysed code then we don't include it.

[thanatoskira]

Without more information I'd say that this is working as intended. We aim to only include necessary types in the database, so if a type isn't used in the analysed code then we don't include it.

In the process of using it recently, I feel that CodeQL is very powerful, and it also provides great convenience for vulnerability research.The usage scenarios mentioned above are mainly for searching some gadgets.For example, the deserialization vulnerability may involve some classes that are not referenced in the source code in the process of exploiting the vulnerability, so if this part of the category is missing, it will lead to a lot of underreporting.
So my main question is whether we will consider increasing this ability in the future like add an extended parameter?

[aschackmull]

Are you trying to find new gadgets or whether some codebase could access a known gadget? In the latter case I assume it's enough to simply see if a related package is referenced in the codebase, that way you avoid reliance on a direct reference of the type and it won't matter whether the specific type is in the db or not. If you're trying to find new gadgets then I guess you should probably use a database that contains the library code, since merely having the types won't give you their private fields, etc. or what else might be relevant for determining whether something might be a gadget.

[github-actions]

This issue is stale because it has been open 14 days with no activity. Comment or remove the stale label in order to avoid having this issue closed in 7 days.