Here is a reply I just posted on the O2 Mailing list, which provides a number of ideas on how to map/glue partial traces (i.e. traces that have sinks on Controllers and Sources on Views)
------------------------------------------
The first thing you must do is to make sure that you have 'scriptable' access to ALL required artifacts. Since you will need to be doing a lot 'automagically' glueing, you have to make sure that you can programatically access the data you need.
From what I understand you already have the traces for the controllers and the views. So what about the config files? Is everything on those config files, or will you also need to parse the java/class files for more metadata. Btw, this is J2EE right?
The next thing you need to do, is to figure out the exact formula that maps the controllers to the views. And before you go any further you need to have a visualization of this (which can be as simple as a treeview, or as complex as a full blow graph model (which you can also do with O2 :) ).
After that, you will need to look at your sinks and sources and see if they are easy to match (this has to be done after you matched the controllers with the view, or you will get a huge amount of mappings, most of which will never happen in the real-world). One of the beauties of the IO2Finding and O2Trace format is that I was able to join traces by simple doing string matches (there are even helper methods to do that).
The idea/concept for Joining traces, is that you rewrite the Sinks and Sources so that they match:
For example, if you had a Controller 'Sink' with
- setAttribute("A_KEY", {taint value"})
and a View 'Source' with
- getAttribute("A_Key")
Then I would rewrite them (in-memory or in disk (if there is a large number of findings)) as:
Controller 'Sink' -> getset_Attribute_A_KEY()
View 'Source' -> getset_Attribute_A_KEY()
and then just:
- do a direct string Sink-to-Source match,
- glue them with a one-to-many traces/finding generation mode (i.e you will need to create a new trace for each unique Sink-to-Source mapping),
- look at the created findings (and finally you will be able to gain a better picture of what is going on)
This actually works very well, and scales spectacularly.
I have used this on lots of different 'glue' locations: Session/Global Variables, Interfaces, Database layers, Controllers->Views, Reflection, Aspect PointCuts, Validation routines, etc...
A good way forward is probably if we work together on doing this for Spring MVC's JPetstore, since I've already started this process and it is a great case study. See the posts at http://o2platform.wordpress.com/category/java/spring-mvc/jpetstore/ , and my next step on this JPetStore security analysis is exactly to create a mapping for the JSPs (check out this post which talks about that: Finding the JSP views that are mapped to controlers in JPetStore (Spring MVC) )
Does this make sense?
Dinis Cruz
-------------------------------------- (end-of-email)
