Application Frameworks and Static Analysis (Part Ein)

Fortify SCA and the custom rules associated with application frameworks provide deep coverage of application frameworks.  It may not be perfect, as no product is, but our research team is probably one of the strongest that I have worked with and they understand how to vet and analyze frameworks.  I want to reveal some of our secret sauce when it comes to analyzing an application framework for vulnerabilities.  I am hoping that by giving you insight into how a framework is analyzed you will understand how we support application frameworks.  When analyzing frameworks, there are 3 primary areas of focus: architectural flows and components, dataflow analysis (sources of input, pass through methods, and output sinks) and framework specific vulnerabilities (error prone API methods).

Architectural Flows and Components

When analyzing an application framework, a security researcher has to understand the architectural components which make up the framework and the data flows between each component.  This helps with understanding the big picture.  You’ve got to understand what a framework does and how it does it if you hope of find weaknesses in it.  For example, if you are looking at Struts 2, the researcher has to understand the Struts2 filters, interceptors, Actions, Results, configurations files, and custom tags.  The following picture sums things up:

Copyright Apache Software Foundation.  Picture is from http://struts.apache.org/2.0.6/docs/architecture.data/s2-arch-big-old.png

Understanding the big picture gives you an understanding of what is going on at a macro level but developing support for an application framework requires you to dig deeper.  One of the basic rules that you write to support frameworks are dataflow rules.  These rules define the input sources, pass through methods, and sinks (where vulnerabilities can be exploited). 

Dataflow Analysis

Any application framework will usually define alternate ways of retrieving input.  For example Spring MVC utilizes Command classes, WebRequest, NativeWebRequest, and annotations (on top of the standard JEE HttpServletRequest and ServletRequest ) to define inputs for web requests.  But the Spring framework itself also provides input into the application via web services (Spring WS, XFire, JAX-RPC, etc.), remoted objects (Burlap, Hessian, Http, RMI, JMX, etc.) and other services.  Identifying these entry points requires the analysis of configuration files, class hierarchies, and annotations.  All of which are possible with the Fortify static code analysis (SCA) engine. 

In the last 2 months I have the opportunity to write some pretty advanced SCA rules to support frameworks.   I discovered that the SCA engine is a pretty amazing creation.  There are actually five phases of scanning which occur where 3 of the phases deal with scripting rules (rules written entirely in a scripting language having direct access to core SCA data structures, functions, and entities) and the other two phases dealing with standard rules (rules which are represented in xml format which pass input to specific SCA analyzers to produce findings).  Script rules are raw script blocks which hold the script code used by SCA to carry out a specific task such as parsing application configuration files and setting up the data structures containing this information.  Standard rules are analyzer specific but can also execute script logic to customize the rule definition and inputs based on application information identified in pre-phase scripts.  Standard rules are primarily focused on directing one of the many analyzers to find vulnerabilities.   The SCA engine also supports a process called labeling where mid-phase scripts or labeling rules (running in phase 2) can tag classes, methods, and fields with an arbitrary identifier.  Once labeling is complete, standard rules (which run after mid-phase script rules) can turn labeled items into findings or use labels to taint entry points or taint labeled methods as sources/sinks for dataflow analysis.  Standard rules can also directly utilize annotated code structures to turn annotated methods into findings or taint entry points for dataflow analysis.  The ability to work with annotations is important for a static analysis engine because modern frameworks such as Spring MVC (version 2.5 and above) are turning away from rigid class hierarchies and moving toward annotated POJOs (plain old java objects).  Annotations are used to identify controller classes and request mapped  methods for  web request entry points.  The SCA engine is especially well adapted to work with annotations and our rule set reflects this.  Finally, post-phase scripting rules are run after vulnerabilities are identified and can be used to clean up/prune identified vulnerabilities or add additional information to identified vulnerabilities (such as which configuration file triggered the finding).

 Labeling is an important feature of the SCA engine so let me give you an example:

If a web application utilizes a Hibernate or JPA persisted entity as its request bound object (commandClass in Spring MVC or Action attribute in Struts 2) then an attacker could use request parameters to update information in associate (foreign key related) entities/tables of the persistent entity.

In order to find this vulnerability a pre-script runs to collect all of the Hibernate and JPA entities as well as the Spring commandClasses or Struts 2 Actions within the application.  Then mid-scripts add a label such as “persistentEntity” or “reqBoundClass” to the classes which are used as Hibernate/JPA persisted entities or request bound objects.  Finally, standard rules would find all classes which had labels “persistentEntity” and “reqBoundClass” to identify objects as request bound persistent entities.

A security researcher not only needs to understand the architecture of an application framework and its inputs but he/she also needs to understand how framework APIs are utilized to pass data through the architecture of the framework (the “big” picture above).  Most applications that are scanned will not provide the source code for 3^rd party frameworks.  In order to trace data flows correctly, pass-through rules need to be created which cover tainted data as it passes through framework code.  This allows the dataflow analyzer to correctly trace dataflow through components where the source code was not provided.

Finally, framework specific sinks need to be added to support the specific application framework.  An example related to hibernate would be session.createSQLQuery(“SQL string…”);  The Hibernate specific method “createSQLQuery” could be used to execute a SQL injection attack if a user controlled string is passed to the method. 

Conclusion

This is probably a lot to take in one setting.  We have covered two of the three steps required to analyze application frameworks.  You have also gained insight into some of the inner workings of the SCA engine.  Next week we will continue our discussion of application frameworks and static analysis by looking at framework specific vulnerabilities.