Security Testing of Java web applications Using Static Bytecode Analysis of Deployed Applications

Transcription

1 Security Testing of Java web applications Using Static Bytecode Analysis of Deployed Applications Streamline your web application Security testing with IBM Security AppScan Source Leyla Aravopoulos Kenneth Cheung William Frontiero 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 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.

2 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 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.

3 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 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

4 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.

5 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: 01.ibm.com/support/knowledgecenter/SSS9LM_9.0.1/com.ibm.rational.appscansrc.security.doc/topics/mana ging_assessments_scan_source.html

6 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 01.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: 01.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.

7 Figure 5 When importing from Apache Tomcat, AppScan Source 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.

8 Figure 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 : 01.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: 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:

9 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: 01.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 01.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: OWASP.org Source Code Analysis Tools: IBM Security AppScan Source Knowledge Center: 01.ibm.com/support/knowledgecenter/SSS9LM_9.0.1/com.ibm.rational.appscansrc.common.doc/helpindex.html?cp=SSS9LM_9.0.1%2F0

10 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.