Capa-scripts: parsing imported classes, static methods, regular methods, and class attributes.

[adamstorek]

So far, capa-scripts is only able to parse newly instantiated objects and static methods such as:

my_ps = new System.Diagnostics.Process();
System.Diagnostics.Process.Start();

However, we would also like to capture regular method calls without following objects around (potentially intractable) such as:

my_ps = new System.Diagnostics.Process();
my_ps.Start();

and similarly class attribute assignments such as:

ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = "powershell.exe";

My idea how this could be done without explicitly tracking types and new objects:

1. Load signatures (some information saying ProcessStartInfo has property FileName) - we already need to do that to even figure out whether ProcessStartInfo is System.Diagnostics.ProcessStartInfo
   Within each function:
   1. Find all newly instantiated objects
   2. Find all member accesses (determine whether these are method calls or properties)
   3. Try to match each against a hashset of loaded signatures -> yield each function call/property if match

This is nowhere near foolproof but it might be good enough - what do you think?

[mr-tz]

I think your algorithm would work well. Before we go there though, is this something limiting us right now or causing issues soon?

Could we also get away with focusing on just the method calls and/or properties (are they unique enough)?

[adamstorek]

Right now, we do not extract regular method calls or class attributes. Although class attribute assignments might not be a huge deal, not extracting dynamic methods can seriously limit us, especially for C#.

The method call/property uniqueness will largely depend on the programming language/libraries used. For C#, it should not be a huge problem. I can't tell how big the problem is for Python and JS. However, the problem might be large for languages like Go. What's more, I am not sure if the .NET rules rely on the entire namespace inclusion also for regular methods and class attributes.

[mr-tz]

Related idea:
I assume we could parse the documentation pretty easily and extract the relevant entries for APIs present in our rules (we don't care about anything else really, anyway). This would largely reduce the problem space and also help with #1109.

We'd have to update the list when we add new rules, but maybe it provides a good starting point?

[adamstorek]

This is the current approach; I wrote a simple msdocs dotnet api parser and can scrape this info relatively easily. However, there are obviously many more entries than the ones we are interested in, therefore I proposed to only maintain a list of those that we have in our rules. Nevertheless, this means that with new rules that add new APIs we also need to update this list.

[mr-tz]

🤣 ok, then we're on the same page!

[mike-hunhoff]

It should be pretty straightforward to ensure the list is updated each time a new API is added. We could maybe extend the linter to track this for us.