Missing Reflection-Sensitive URLStreamHandler Modeling Breaks HttpURLConnection Dispatch

[mohPYdev]

Note: This is the artifact of a research project designed to help static analysis developers reason about and localize the unsoundness issues of their tool.

Description

Summary

Soot does not fully model the runtime resolution and allocation chain behind URL.openConnection(), specifically the creation of protocol-specific URLStreamHandler instances and their role in producing concrete URLConnection objects.

As a result, the receiver of HttpURLConnection.disconnect() may have an empty points-to set during call graph construction. This happens because the concrete URLConnection subtype is created indirectly through reflective class loading (Class.forName(...)) on a non-constant string and subsequent native-assisted handler initialization, which is not resolved by SPARK’s default reflection and native modeling.

Consequently, virtual dispatch on the returned connection object is not resolved, leading to missing call graph edges for disconnect().

---

Minimal Reproduction

A minimal Java application is provided that opens an HTTP connection using URL.openConnection() and then calls disconnect() on the resulting object.

How to reproduce

Run Soot/SPARK call graph construction on the provided project using the included analysis interface script.
soot version: 4.4.1
java version: 8

Unzip the artifact. The reproducing example is located in reproducing/, and the driver script is in interface/.

attachment.zip

python analysis_interface.py \
  --framework Soot \
  --algorithm SPARK \
  --project reproducing \
  --type static \
  --reproducing_test_case_path ../reproducing \
  --boundary_id 1

---

Observed Behavior

• url.openConnection() is modeled, but the returned object lacks a precise concrete type
• The intermediate URLStreamHandler resolution via Class.forName(...) with a concatenated string is not resolved by SPARK
• As a result, the allocation of sun.net.www.protocol.http.HttpURLConnection is not propagated into the points-to set
• The receiver of conn.disconnect() has an empty or incomplete points-to set
• The call graph does not include the edge:

sun.net.www.protocol.http.HttpURLConnection.disconnect()

• The failure occurs even though the invokevirtual instruction is present in bytecode

---

Expected Behavior

For programs that use URL.openConnection():

• The analysis should model the full protocol handler resolution chain
• The URLStreamHandler subtype should be resolved to its concrete implementation (e.g., HTTP handler)
• The resulting URLConnection object should be assigned a concrete type (HttpURLConnection)
• Virtual dispatch on disconnect() should be resolved
• The call graph should include:

{
  "caller": "com.example.App.runConnection()V",
  "callee": "sun.net.www.protocol.http.HttpURLConnection.disconnect()"
}

---

Notes on Implementation (inspected behavior)

From inspection of SPARK and Soot’s call graph construction:

• The receiver of conn.disconnect() is computed from the return value of URL.openConnection()
• URL.openConnection() delegates to URLStreamHandler.openConnection()
• The concrete handler class is instantiated via Class.forName(...) inside URL.getURLStreamHandler()
• SPARK’s default reflection model only resolves Class.forName() when the argument is a constant string
• In this case, the handler class name is constructed dynamically (concatenation), so no resolution occurs
• As a result, the concrete handler (sun.net.www.protocol.http.Handler) is never added to the points-to set
• Consequently, the allocation of HttpURLConnection inside the handler is not propagated
• The virtual call resolution for disconnect() fails due to an empty receiver set

Relevant components:

• OnFlyCallGraphBuilder.java
• NativeMethodDriver.java
• virtualedges.xml
• SPARK reflection handling for Class.forName

The root issue is incomplete modeling of the JDK’s dynamic protocol handler mechanism, specifically the reflection-based loading of URLStreamHandler implementations and their influence on object allocation propagation.

---

Impact

If this limitation is unintended, it significantly affects precision of call graph construction in network-heavy Java applications.

The URL.openConnection() pattern is widely used in HTTP clients, SDKs, and enterprise systems. Missing its modeling leads to:

• Loss of virtual dispatch resolution for URLConnection implementations
• Incomplete call graphs for networking libraries
• Under-approximation of API usage in security and dependency analysis
• Missing edges in widely used JDK-based communication flows
• Reduced accuracy of interprocedural analyses that depend on network behavior modeling

Overall, this results in systematic under-modeling of JDK protocol-based object creation and its downstream effects on call graph construction.

[MarcMil]

I'd consider this a known limitation of SPARK in general and treat it as a "won't fix". The concatenation could lead to a variety of different classes being loaded and depending on where the strings come from it might be impossible to compute statically.

Furthermore, I'd argue that these kind of edges are not useful for the majority of client analyses. Rather than analyzing concrete JDK implementations it might be better to have a stub/API model based approach. Note that the concrete implementations might be highly dependent on the used JVM, so you could end up with totally different results when using other JVMs.

You say that the impact is that "Reduced accuracy of interprocedural analyses that depend on network behavior modeling" and "Missing edges in widely used JDK-based communication flows", but when I want to implement an analysis that is interested in network APIs I'd create specific API models for each network API call in java.net.* in order to not rely on specific implementations of the JDK.

At some point the analysis has to have the information that a certain API call handles a network connection, because otherwise, you'd just see some native socket methods in your analysis (e.g. PlainSocketImpl.socket*). You'd just have to add some more class models such as (Http)URLConnection.* in order to get a correct network handling, regardless of which implementation class is used when you actually run the program.
In my experience, client analyses want a precise call graph regarding edges from user code to user code. Edges from user code to JVM-methods are not really that interesting usually.

If a client analysis were to really want to do it in that way, it could resort to use a CHA-style call resolution mechanism as a fallback when there is no SPARK points-to-set. Note that we have certain other known cases were SPARK cannot compute points-to-sets (e.g. storing and retrieving objects from collections).

If you want, feel free to implement a solution that models precisely these calls somehow or improves SPARK.

[mohPYdev]

So in this case, As I understood, the actual limitation is that Class.forName reflective call only resolves edges with string constant parameter. regardless of the actual edge that is being missed, if we can improve the handling of that reflective call, wouldn't that make the analysis more sound? For instance, if the variable (classname) in Class.forName(classname) could be actually resolved statically, it would improve the reflective calls. The only thing that is required to do this is to track the variable that is the parameter of the forName call, and see if there is a constant declaration of it in the source code (that is the only way we can precisely resolve this call) which then fixes the problem with subsequent virtual calls that the receiver is coming from that reflective call such as this network API.

[StevenArzt]

So in this case, As I understood, the actual limitation is that Class.forName reflective call only resolves edges with string constant parameter.

Correct. There are works on this issue, e.g., S Rasthofer, S Arzt, M Miltenberger, E Bodden: "Harvesting runtime values in Android applications that feature anti-analysis techniques." In: NDSS 2016. We are also working on an entirely new callgraph algolrithm for our commercial code scanner that can resolve such calls.

if we can improve the handling of that reflective call, wouldn't that make the analysis more sound?

In general, yes. This problem not only exists in JDK code, but may also show in user code. As @MarcMil wrote, most client analyses are not so much interested in the JDK, but rather treat the public JDK API as a block box. Keep in mind that all these sun.* classes might be there in one variant of the JDK (Oracle, Eclipse, etc.), but not in another. They are not part of the Java standard library and if you use them from user code (which isn't even that easy with Java 9 module protections), your code is no longer portable.

Having said that, I know that some researchers want to derive statements about the JDK itself, e.g., to compute summaries that can then be plugged into client analyses.

The only thing that is required to do this is to track the variable that is the parameter of the forName call, and see if there is a constant declaration of it in the source code (that is the only way we can precisely resolve this call)

We can do quite a bit better than that. We're working on it, at least for a paper and the commercial scanner. Whether this comes to Soot at some point is questionable because the code unfortunately relies on a lot of private/commercial stuff.

[mohPYdev]

Thanks for the clarification.