ASP.NET MVC 3.0 F4FHandler – “The Controllers Are Under Control “
sp1r0 270002FRMM Visits (3674)
AppScan Source Framework 4 Frameworks Support Series
As I'm just now beginning to fully realize - The Web Application Framework Language (WAFL) and the associated Fram
Putting aside the potential uses and intricacies of WAFL for the moment, this post is intended to server as a general update as to where we currently stand in our quest for complete and accurate data flows (the so-called 'Visibility') through an application. Given that our target is the previously unsupported ASP.NET MVC Framework - Version 3.0 - which happens to follow the current trend of modern web frameworks (Struts 2.x, Spring 3.x, Grails, Stripes, etc.) of “coding by convention”, sometimes referred to as choosing “convention over configuration”.
What makes the ability to generate information to customize the Analysis Engine particularly striking is that our original “out-of-the-box” assessment with AppScan Soure 184.108.40.206 yielded just as close to zero visibility as one would ever expect from a "successful scan" - just 2 data flow Traces. The general reason for this abscence of useful data is that the Engine is not seeing any Known Sources as 'being called' in a known way. Most classes here are invoked as part of the URL Routing Module, the only indication of the specific functionality of many methods is the presence of source code Attributes [of a flavor not currently recognized] and the data binding of the Model to the View follows a certainly discernible, however, quite unorthodox pattern.
Although this is just the first step, it certainly seems to be in the right direction. Next up (on this tangent) is a deeper investigation into the workings of the ASP.NET MVC 3.0 in order to be able to first map out how the pieces fit together and then describe that using my newly developed WAFL generation talents and newly discovered treasure trove of static analysis functions buried in our installation directory.