By Babita Sharma, Michael Hua Xiao
Most modern web applications are built using web application frameworks, such as Enterprise JavaBeans (EJB), Apache Struts and JavaServer Faces (JSF). These frameworks simplify web application development by providing higher-level abstractions for common tasks. For example, many frameworks are based on the model-view-controller pattern and there is clear separation between business data storage, business rules configuration and the UI components of the application. In the framework-based web applications, the interactions between components are primarily invoked via configuration files and source code annotations. Interactions specified through configuration files are challenging to identify by traditional static analysis tools since they are not source code and vary from framework to framework. Without the information from configuration files, related control flow and data flow are missed and would lead to loss of vulnerability findings.
Framework for Frameworks (F4F) is an approach used by IBM Security AppScan Source to effectively analyze framework-based web applications. F4F processes configuration files and code annotations used by a framework-based application and extracts all the relevant information into a Web Application Flow Language (WAFL) file. WAFL is independent of any framework and program language. A WAFL file describes data flow and control flow extracted from configuration files.
Synthetic methods are important elements in WAFL specification. A synthetic method is a function. Like a function in any programming language, synthetic methods can have local variables and a body containing assignment statements and function calls. The function calls can be to any existing function in the application or to another synthetic method. Synthetic methods are called synthetic because they are not part of the application but are synthesized by F4F to represent the behavior of configuration files. Therefore, static analysis tools can easily convert the information in WAFL files to regular methods, calls and variables to conduct the static analysis.
In IBM Security AppScan Source, we use a component named framework handler to process a web application framework and produce the WAFL file. IBM Security AppScan Source contains a set of framework handlers; one for each framework that we support. For example, if the application to be scanned uses the Spring framework, then the Spring framework handler will come into action. It will process the annotations in source code and the configuration files of the application, and then produce a WAFL file as output. This WAFL file is consumed by the static security analysis component. Figure 1 summarizes how F4F works in IBM Security AppScan Source.
Figure 1. How F4F works
As shown in Figure 1, a cool thing about F4F is that it is extensible. Any AppScan Source user can write their own framework handler and plug it into AppScan Source. Such a framework handler is called a custom framework handler. In AppScan Source 8.6, we have provided improved APIs for WAFL generation. These APIs and other F4F interfaces can be used to easily generate WAFL code. Most importantly, in 8.6, we are shipping the source code of a sample framework handler. This framework handler processes Enterprise JavaBeans (EJB) 2 applications. It would be a good start point for developers who want to write their own custom framework handlers.
AppScan Source provides built-in support for the following frameworks: Apache Struts 1, Spring MVC 2.5, ASP.NET, JavaEE, and Enterprise JavaBeans (EJB) 2. Especially, in the 8.6 release, we have added support to Apache Struts 2 and JavaServer Faces(JSF) 2.
Figure 2 and Figure 3 are two example traces from a sample JSF2 application. With the support of JSF2 framework handler, now we can see traces (e.g., XSS traces) that go all the way from the input side on the request web page via configuration files to the output side on the response object. As shown in the following diagram, we can see an SQL injection trace which crosses different source files in the JSF 2 app.
Figure 2. A trace with SQL injection in a JSF2 application
In Figure 3, the JSF2 application uses an explicit navigation rule. In "login.xhtml", it defines an outcome value "ToPageSearch2", and in config file "faces-config.xml", it defines a navigation rule which specifies that the outcome "ToPageSearch2" from web page "login.xhtml" should navigate to page "Search2.xhtml". So on AppScan Source with the support of JSF2 framework handler, we can identify such control flow from the configuration file and see a trace from "login.xhtml" to "Search2.xhtml".
Figure 3. A trace with explicit navigation rule in a JSF2 application
To sum it up, with F4F technology, we can quickly and easily add support for new frameworks in AppScan Source. Moreover, with the built-in F4F handlers, users can identify many more framework-related security issues without any development or configuration effort.
F4F is another example of IBM's commitment to advancing application security. The F4F technology represents one of over one hundred patents granted or in the approval process for static, dynamic, and hybrid analysis.
Comments