Could FlowDroid be applied to client-server applications for static taint analysis?

[jimmy66688]

Hi @ericbodden @StevenArzt , I want to perform static taint analysis on some client-server applications, but these client-server applications have one feature: there is no fixed entrypoint on the server side, and the initialization logic on the server side is separate from the request processing logic. Although I analyze all the entrypoints, the information flow is separated. Is there an idea to perform static taint analysis on server applications? Thanks!

[StevenArzt]

Your problem is similar to Android apps, which are essentially plugins into the operating system. This design principle also applies to, e.g., Spring Boot or Java Enterprise applications. FlowDroid uses dummy main methods to simulate these interactions between platform and application, i.e., it generates a fake main() method, which calls the actual entry points.

You have multiple options:

1. You implement an instance of IEntryPointCreator from your platform (inherit from BaseEntryPointCreator to make your life easier). While this approach requires some work, you can be as precise as you want in your model, also with regard to data flows between reequest processing methods.
2. Over-approximate using the DefaultEntryPointCreator, which takes a set of methods, and calls all of them in a sequence, with some heuristics on when to share objects between calls. This is a very simple solution, your mileage may vary.
3. If your target platform is Spring Boot or Java EE (or something else that we support), you might be interested in our commercial code scanner VUSC which parses all the configuration files, dynamic endpoint registrations in code, etc. to create a precise dummy main method. We have an academic program for non-commercial academic by eligible universities, and we have commercial licenses for the industry. VUSC uses FlowDroid, but with tons of code for platform modeling on top.

If you want more details on how dummy main methods work, have a look at my PhD thesis: https://tuprints.ulb.tu-darmstadt.de/5937/

[StevenArzt]

Please try and stick to a single topic per issue. If you want to discuss a second topic, please open another issue. Otherwise, it's really hard to keep track of what is still open and what has been resolved.

[jimmy66688]

Your problem is similar to Android apps, which are essentially plugins into the operating system. This design principle also applies to, e.g., Spring Boot or Java Enterprise applications. FlowDroid uses dummy main methods to simulate these interactions between platform and application, i.e., it generates a fake main() method, which calls the actual entry points.

You have multiple options:

1. You implement an instance of IEntryPointCreator from your platform (inherit from BaseEntryPointCreator to make your life easier). While this approach requires some work, you can be as precise as you want in your model, also with regard to data flows between reequest processing methods.
2. Over-approximate using the DefaultEntryPointCreator, which takes a set of methods, and calls all of them in a sequence, with some heuristics on when to share objects between calls. This is a very simple solution, your mileage may vary.
3. If your target platform is Spring Boot or Java EE (or something else that we support), you might be interested in our commercial code scanner VUSC which parses all the configuration files, dynamic endpoint registrations in code, etc. to create a precise dummy main method. We have an academic program for non-commercial academic by eligible universities, and we have commercial licenses for the industry. VUSC uses FlowDroid, but with tons of code for platform modeling on top.

If you want more details on how dummy main methods work, have a look at my PhD thesis: https://tuprints.ulb.tu-darmstadt.de/5937/

I have had the pleasure of reading your PhD thesis and all the classes in the FlowDroid source code that implement the IEntryPointCreator interface.

I see that when creating the dummy main method, I just need to specify the method signature and then all the class instances, method parameters are created automatically.

What kind of precision do you mean by as precise as you want in your model in your reply? Does it require that I manually create each parameter in the model?

For example, Cassandra contains CRUD operations, if I need to analyze the information flow of four operations, do I need to manually create method calls for each operation corresponding to the parameters?

There is only one request processing entry point on the server side of Cassandra, and it dispatches different processing logic based on the contexts carried in the request. Do I need to prepare contexts for each of the CRUD operations? Or is the context automatically created by FlowDroid soundness enough? Can FlowDroid create callgraphs that cover all four curd operations? I know that the context mainly affects the point-to-set in the SPARK callgraphalgorithm.

Thank you Steven.

[StevenArzt]

If there is only one entry point that dispatches incoming requests based on fields inside that request, e.g., to distinguish between POST and DELETE operations, you don't need to handle that explicitly. Since the request is external data, FlowDroid assumes that it can contain arbitrary data. If there are conditionals inside the Cassandra dispatcher, FlowDroid will propagate taints into all possible targets (all then/else cases). You just need to make sure that the dummy main method contains a call to the Cassandra entry point.

My comment on precision was more about, e.g., taking the configuration of your application into account as well.