Extending WAFL Into The Application Security Information Language
sp1r0 270002FRMM Visits (958)
Given that I've been adhering more and more to what has become the leading edge of a communication paradigm shift, which I'll talk the liberty of terming HyperLink It Or Lose It , below is a response I wrote to an email with some appreciated positive encouragement which I received from one of the innovators behind the technologies that I've been using in my latest investigations.
Many thanks for the positive feedback! I'm going to assume that you're the only one that replied to this email simply because no one else could put into words how much they truly care about the intricacies of modern web frameworks :-)
Regarding WAFL and F4F, I'm really starting to see how this technology fills what has been a crucial gap in our static analysis capabilities. This is the ability to perform 'pre-analysis' on the target application in order to generate all the necessary Traces and start down the path towards visibility. The showstopper when it comes to supporting new technologies, whether the web frameworks that we're working on currently, or web services in the past, reflective, anonymous, or polymorphic functions, that we'll tackle in the near (or distant) future - if we can't first generate the traces for all the potential data flow paths, we're done.
However, once we can generate the Traces, over-generate even, then we can use [already existent and well proven] advanced filtering and stitching techniques to see through the noise, connect the pieces layer by layer, until the underlying architecture is exposed and we can scour for any clear links back to the attack surface. Of course, this 'Over-Taint Then Filter' technique has been rightly criticized as inelegant and raw many times by many parties over the years, but without any real alternative, it's served me well in countless environments - getting AppScan Source (Ounce) to show the traces that I needed (reversing the vulnerability into the tool is a time-honored tradition as I'm sure you know).
So now with a real ability to do pre-processing, using WALA, as well as post-processing, using the O2 Platform, the capability for tracing data all the way through an enterprise application and making the connections to both the input and output URLs, is directly within our grasp. And the connection with describing this information gleaned in the pre-analysis phase in WAFL, from my perspective, has tremendous potential for combining not only dynamic and static analysis, but taking a grander view, providing a link between all the tools that are responsible for monitoring and securing a mission critical application.
It seems to me that WAFL should broaden it's scope from just describing "Framework" information to describing all "Application Security" information, whether data flows or vulnerabilities, patch levels, network use profiles or anomaly data - we need a way for the tools to communicate what they each discover about an application to one another.
And this language needs to be open source. We need everyone to realize that a solution for enabling communication between security tools, especially within IBM but really for all vendors, is in the general security interest of us all.
I know this is probably a bit more than you were expecting when you asked for my suggestions, but in one way or another, creating proper intercommunication between security tools, has always been one of the main goals of the O2 (Open Ounce) Platform and one of my main points of focus in developing integration prototypes like the AppScan Source Plug-in For AppScan Standard .
Hopefully I won't end up discouraging you from emailing me again, like it seems I've done to the rest of the AppScan crew...I'd be really interested to hear your thoughts. :)