Security Testing of Java web applications Using Static

Security Testing of Java web applications Using Static
Bytecode Analysis of Deployed Applications
Streamline your web application Security testing with IBM Security AppScan
Source 9.0.1
Leyla Aravopoulos
[email protected]
Kenneth Cheung
[email protected]
William Frontiero
[email protected]
Nov 28, 2014
Abstract:
web applications are one of the most commonly developed and used applications today. They evolve everyday reaching
new systems and production environments. Along with that evolution comes new vulnerability incidents and the need for
Application Security testing. Yet Static Analysis of web applications has traditionally proven to be difficult due to challenges
configuring the tools. AppScan Source 9.0.1 introduces a new feature to scan Java web applications deployed to any
Application Server with the click of a few buttons. This helps organizations quickly get to the security findings and
remediation and helps them reduce the risk of becoming the victim of cyber-attacks. This white paper outlines the benefits
of importing deployed web applications into AppScan Source. This white paper also outlines the default way this feature
works in AppScan Source as well as how it can be extended through programmatic extensions to AppScan Source.
1 Introduction
In spite of the growth in the Mobile market, web applications are still widely used and provide huge benefits to
organizations and users. The architecture of web applications is becoming more complex with the introduction of
Software as a Service (SaaS) and cloud-based platforms. The Cenzic Vulnerability Report for 2014 states,
“Every day there are new reports of highly organized cyber-attacks on leading websites.” Some of the victims are
high profile organizations, such as Target (with 70 million users) or Adobe (with 38 million users). The cost of
cyber-crime in 2013 was $100 billion in the United States and $300 billion globally. The Cenzic report states the
following about web applications, “The application layer continues to be a soft target with increasing cyberattacks. 96% of all applications tested in 2013 have one or more serious security vulnerabilities. The median
number of vulnerabilities per app has elevated to (14) from last year’s count of (13).” Figure 1 shows the web
application vulnerability break down in the applications tested by Cenzic.
Figure 1
Often IT organizations quickly take steps to investigate attacks and remediate them. But after an attack, the cost
of recovering and regaining customer trust is high. The best course of action is to prevent these vulnerabilities in
the application source code prior to production deployment. That raises the need for application security testing
during the development and test phases of development. .
In this white paper, we review some of the traditional challenges with using a Static Security Analysis Testing
(SAST) tool on web applications. Next, we describe a new feature in IBM Security AppScan Source 9.0.1 that
streamlines getting to that first scan of your web application by scanning the application's binaries that are
deployed to a web application serversuch as Tomcat.
2 Configuration challenges when scanning web applications
One of the weaknesses of SAST for web applications lies in difficulties compiling the source code. Open Web
Application Security Project (OWASP) lists this as one of the weaknesses of web application security scanning,
“Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code
because they don't have the right libraries, all the compilation instructions, all the code, etc.” In the following
sections, we look at some of the unique web application compilation challenges.
2.1 Missing dependencies and JSP compilation
SAST tools that use compilation technologies need all of the following to compile a web application for
optimal analysis and coverage:
1. Full Source code of the application and the Java Compiler used
2. Dependency libraries needed by the web application
3. The JavaServer Pages Standard Tag Library (JSTL)
4. The correct JSP compiler
Clearly, the full source code of an application is needed to compile the application. But the person running
the SAST tool may not have access to all of the source code. For example, a web application may require
code from multiple developers, but no single developer running the SAST tool has authority to access all of
the source code. Furthermore, even if all of the source code is present, the SAST tool needs to know what
Java Compiler level to use to successfully compile the code. This also applies to libraries that a web
application requires to successfully compile, it they are not present the web application will not successfully
compile. This includes libraries that are part of the target Application Server, such as the IBM WebSphere
application server or Oracle WebLogic.
If custom or application server specific tag libraries are required to compile and build an application, that can
also cause problems for a SAST tool. The tag library jar file location is normally added to the classpath of all
web applications deployed on the application server. Problems can arise if the web application source code
is sent to a SAST tool without specifying the target application server and/or the version of standard tag
library jar used. There can also be problems if the necessary custom tag libraries are not packaged along
with source code. Last, but not least, application servers may have their own unique JSP compilers. If the
SAST tool does not have access to the same JSP compilers, compilation errors may occur.
As you can see, there are clear challenges when it comes to SAST tools compiling web applications. The
remainder of this article focuses on how IBM Security AppScan Source 9.0.1 streamlines the process
analyzing web applications by importing the deployed application from Application Servers. This feature
eliminates the potential compilation issues mentioned above. And it allows users to get to their first scan
quickly and enables users to get the best results from their scan.
3 Scanning deployed web applications
3.1 IBM WebSphere Application Server Liberty Profile and Apache Tomcat
With AppScan Source 9.0.1's default , out of the box capability, you can point AppScan Source to the
installation directory of WebSphere Application Server Liberty Profile servers and Apache Tomcat servers and
import the web applications from them into AppScan Source for scanning. There is no need to compile the Java
classes of the application. Instead, the deployed classes and jars are scanned. All dependencies including Tag
Libraries of the deployed web applications are retrieved by AppScan Source from the Application server.
AppScan Source can also use the JSP compiler of the web application Server to compile the JSPs. And on
WebSphere Application Server Liberty Profile, AppScan Source can use the web application's pre-compiled
JSPs.
A brief summary of the steps a user would take to import a web application from a web application s is
described below. There are also links to more detailed documentation on the instructions.
Launch AppScan Source for Analysis. Under
the Quick Start list, as show in Figure 2, select ‘Import from an application server…’
Figure 2
As show in Figure 3, in the ‘Import from Application Server’ dialog, browse and point to your WebSphere
Liberty Profile or Apache Tomcat installation directory. Note that this directory can be on the same system as
AppScan Source or on a mapped drive. A list of web applications will appear under ‘Applications to import.’
Choose the applications you want to scan and click OK.
Figure 3
As shown in Figure 4, AppScan Source will import the web applications you selected. The WAR files are
mapped to a AppScan Source application and project. EAR files are mapped to one AppScan Source
application and multiple projects, one for each WAR file in the EAR file. At this point your imported
applications and projects are ready for scanning with AppScan Source. To learn more about scanning with
AppScan Source this help document is a good starting point: http://www01.ibm.com/support/knowledgecenter/SSS9LM_9.0.1/com.ibm.rational.appscansrc.security.doc/topics/mana
ging_assessments_scan_source.html
Figure 4
To get more detailed instructions for importing existing Java web applications from Apache Tomcat and
WebSphere Application Server Liberty profile application servers, see http://www01.ibm.com/support/knowledgecenter/SSS9LM_9.0.1/com.ibm.rational.appscansrc.security.doc/topics/settin
g_up_configure_add_appserver.html
Notes
WebSphere Liberty Profile does not include a standalone JSP compiler and a the JSPs must be
manually compiles prior to importing. Please refer to these instructions: http://www01.ibm.com/support/knowledgecenter/SSS9LM_9.0.1/com.ibm.rational.appscansrc.security.doc/topics/s
etting_up_configure_add_appserver_precompile.html
By default, AppScan Source scans the JSP files and the content of web-inf/classes of the imported web
application. The content of web-inf/lib directory is not scanned by default. But in the AppScan Source
project properties, you can specify to scan .jar files in the web-inf/lib folder. You can also specifically
exclude some of the .jar files in web-inf/lib from being scanned. This exclusion is useful if only a subset
of the .jar files in web-inf/lib contain user code.
When importing from an application server, you scan the Java bytecode in the class files. But in order to
have line numbers associated with your findings, you need to compile your Java source code with debug
info. Double clicking on findings in the scan will prompt you to point AppScan Source to the location of
your source code, as shown in Figure 5.
Figure 5
When importing from Apache Tomcat, AppScan Source 9.0.1 will use the internally shipped Tomcat JSP
compiler and server libraries by default. If you prefer to use the JSP compiler and Tomcat libraries of the
Tomcat server you imported the application from, you can specify the Tomcat server's installation
directory under Edit->Preferences, as shown in Figure 6.
Figure 6
3.2 Supporting additional web application servers
In addition to WebSphere Application Server Liberty Profile and Apache Tomcat, AppScan Source can
support additional Java application servers through its import framework. Through the import framework
servers such as the IBM WebSphere Application Server or the JBOSS Application Server can be supported.
This is done by creating an Eclipse plugin that uses the application server import framework APIs. Details of
how this process works can be found at : http://www01.ibm.com/support/knowledgecenter/SSS9LM_9.0.1/com.ibm.rational.appscansrc.security.doc/topics/appse
rver_extend.html
Sample plugins to support import from the IBM WebSphere Application Server and JBOSS Application
Server can be found at: https://ibm.biz/BdE2bk. Note that the sample plugins are as-is and not officially
supported.
Once you import one of these sample plugins or create your own plugin , the ‘Import from an application
server…’ mechanism as shown in Figure 2 will recognize applications deployed under the Application Server
the extension is written for.
3.3 Using the Command Line Interface (CLI) or AppScan Source for Automation
After the first import of a web application from an Application Server, the resulting AppScan Source
applications and projects can be scanned using the AppScan Source Command Line Interface (CLI) or
using the AppScan Source Automation Server. Use the following commands to scan an already imported
web application (Web_Application) using CLI:
login username password
list
cd Web_Application
scan
If you make changes to the deployed web application, you must manually re-import the application using the
AppScan Source for Analysis UI before your scans using the CLI or the Automation Server will not include
the new changes. You can learn more about AppScan Source CLI at this Knowledge Center link: http://www01.ibm.com/support/knowledgecenter/SSS9LM_9.0.1/com.ibm.rational.appscansrc.utilities.doc/topics/comm
and_line_interface.htmlYou can learn more about the Automation Server at http://www01.ibm.com/support/knowledgecenter/SSS9LM_9.0.1/com.ibm.rational.appscansrc.utilities.doc/topics/ounce
_auto.html
4 Summary
To summarize, scanning the compiled code of a deployed web application reduces the possibility of the SAST
tool running into configuration issues and facilitates getting to findings, triage, and remediation stages quickly.
The goal of any security program is to secure the production site. Scanning deployed applications on a test
server gives users the most accurate assessment of the production site’s security. AppScan source can achieve
better scanning coverage because it doesn't miss part of an application due to failed compilation. AppScan
Source does not have to filter out findings from code that will never make it on to the production site (e.g. unit
test cases). Lastly, the AppScan Source approach opens the opportunity to use the same application set up for
both DAST (Dynamic Application Security Testing) and SAST scans.
5 Resources
Cenzic Vulnerability Report 2014: http://www.cenzic.com/downloads/Cenzic_Vulnerability_Report_2014.pdf
OWASP.org Source Code Analysis Tools: https://www.owasp.org/index.php/Source_Code_Analysis_Tools
IBM Security AppScan Source 9.0.1 Knowledge Center: http://www01.ibm.com/support/knowledgecenter/SSS9LM_9.0.1/com.ibm.rational.appscansrc.common.doc/helpindex.html
?cp=SSS9LM_9.0.1%2F0
6 About the authors
Leyla Aravopoulos is a Software Development Manager for the IBM Security AppScan Source
product. In her current role, Leyla works with a team of software developers to deliver new features in IBM's
Static Application Security Testing (SAST) space. In the past, Leyla also held software development, test, and
project management roles at IBM. Leyla has a master's degree in computer science from York University,
Toronto, Canada.
William Frontiero (10 Years with IBM, SDLC, Middleware, Automation and Security Testing tooling
Support, Advising and Customization). Advise, support and developed custom solutions for IBM projects such as
Clearcase/UCM, Build Forge, Rational Automation Framework for WebSphere, AppScan SAST/DAST Software.
Published multiple white papers, delivered several Open Mic's, Assist with client tooling around our products,
IBM Inventor for Unified Build Management Patent
Kenneth Cheung is a Software Developer for the IBM Security AppScan Source product. In his
current role, Kenneth designs and develops new features in IBM's Static Application Security Testing (SAST)
space. In the past, Kenneth also delivered features for Rational Application Developer and WebSphere
Commerce at IBM. Kenneth has a bachelor's degree in computer engineering from University of Waterloo,
Ontario, Canada.