Book review: Iron-Clad Java Building Secure Web Applications

This a review of the Iron-Clad Java: Building Secure Web Applications book.

(My) Conclusion

I will start with the conclusion because it’s maybe the most important part of this review.

For me this is a must read book if you want to write more robust (web and non web) applications in Java, it covers a very large panel of topics from the basics of securing a web application using HTTP/S response headers to handling the encryption of sensitive informations in the right way.

Chapter 1: Web Application Security BasicsironCladJavaBook

This chapter is an introduction to the security of web application and it can be split in 2 different types of items.

The first type of items is what I would call “low-hanging fruits” or how you could improve the security  of your application with a very small effort:

  • The use of HTTP/S POST request method is advised over the use of HTTP/S GET. In the case of POST the parameters are embedded in the request body, so the parameters are not stored and visible in the browser history and if used over HTTPS are opaques to a possible attacker.
  • The use of the HTTP/S response headers:
    • Cache-Control – directive that instructs the browser how should cache the data.
    • Strict-Transport-Security – response header that force the browser to alway use the HTTPS protocol. This it can protect against protocol downgrade attacks and cookie hijacking.
    • X-Frame-Options – response header that can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
    • X-XSS-Protection – response header that can help stop some XSS atacks (this is implemented and recognized only by Microsoft IE products).

 The second types of items are more complex topics like the input validation and security controls. For this items the authors just scratch the surface because all of this items will be treated in more details in the future chapters of the book.

Chapter 2: Authentication and Session Management

This chapter is about how a secure authentication feature should work; under the authentication topic is included the login process, session management, password storage and the identity federation.

The first part is presenting the general workflow of login and session management (see next picture) and for every step of the workflow  some dos and don’t are described.

login and session management workflow
login and session management workflow

The second part of the chapter is about common attacks on the authentication and for each kind of attack a solution to mitigated is also presented. This part of the chapter is strongly inspired from the OWASP Session Management Cheat Sheet which is rather normal because one of the authors (Jim Manico) is the project manager of the OWASP Cheat Sheet Series.

If you want to have a quick view of this chapter you can take a look to the presentation Authentication and Session Management done by Jim.

Even if you are not implementing an authentication framework for you application, you could still find good advices that can be applied to other web applications; like the use of the use of the secured and http-only attributes for cookies and the increase of the session ID length.

Chapter 3: Access Control

The chapter is about the advantages and pitfalls of implementing an authorization framework and can be split in three parts.

The first part describes the goal of an authorization framework and defines some core terms:

  • subject : the service making the request
  • subject attributes : the attributes that defines the service making the request.
  • group : basic organizational structure
  • role : a functional abstraction that uniquely describe system collaborators with similar or unique duties.
  • object : data being operating on.
  • object attributes : the attributes that defines the type of object being operating on.
  • access control rules : decision that need to be made to determine if a subject is allowed to access an object.
  • policy enforcement point : the place in code where the access control check is made.
  • policy decision point : the engine that takes the subject, subject attributes, object, object attributes and evaluates them to make an access control decision.
  • policy administration point : administrative entry in the access control system.

The second part of the chapter describes some access control (positive) patterns and anti-patterns.

Some of the (positive) access control patterns: have a centralized policy enforcement point  and policy decision point (not spread through the entire code),  all the authorization decisions should be taken on server-side only (never trust the client), the changes in the access control rules should be done dynamically (should not be necessary to recompile or restart/redeploy the application).

For the anti-patterns, some of then are just opposite of the (positive) patterns : hard-coded policy (opposite of “changes in the access control rules should be done dynamically”), adding the access control manually to every endpoint (opposite of have a centralized policy enforcement point  and policy decision point)

Others anti-patterns are around the idea of never trusting the client: do not use request data to make access control policy decisions and fail open (the control access framework should cope with wrong or missing parameters coming from the client).

The third part of the chapter is about different approaches (actually two) to implement an access control framework. The most used approach is RBAC (Role Based Access Control) and is implemented by some well knows Java access control frameworks like Apache Shiro and Spring Security. The most important limitation of RBAC is the difficulty of implementing data-specific/contextual access control. The use of ABAC (Attribute Based Access Control) paradigm can solve the data-specific/contextual access control but there are no mature frameworks on the market implementing this.

Chapter 4: Cross-Site Scripting Defense

This chapter is about the most common vulnerability found across the web and have two parts; the presentation of different types of cross-site scripting (XSS) and the way to defend against it.

XSS is a type of attack that consists in including untrusted data into the victim (web) browser. There are three types of XSS:

  • reflected XSS (non persistent) – the attacker tampers the HTTP request to submit malicious JavaScript code. Reflected attacks are delivered to victims via e-mail messages, or on some other web site. When a user clicks on a malicious link, submitting a specially crafted form the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server.
  • stored XSS (persistent XSS) – the malicious script is stored on the server hosting the vulnerable web application (usually in the database) and it is served later to other users of the web application when the users are loading the vulnerable page. In this case the victim does not require to take any attacker-initiated action.
  • DOM-based XSS – the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser.

For the defense techniques the big picture is that the input validation and output encoding should fix (almost) all the problems but very often various factors needs to be considered when deciding the defense technique.

Some projects are presented for the input validation (OWASP Java Encoder Project) and output encoding (OWASP HTML Sanitizer, OWSP AntiSamy).

Chapter 5: Cross-Site Request Forgery Defense and Clickjacking

Chapter 6: Protecting Sensitive Data

This chapter is articulated around three topics; how to protect (sensitive) data in transit, how to protect (sensitive) data at rest and the generation of secure random numbers.

How to protect the data in transit

The standard way to protect data in transit is by use of cryptographic protocol Transport Layer Security (TLS). In the case of web applications all the low level details are handled by the web server/application server and by the client browser but if you need a secure communications channel programmatically you can use the Java Secure Sockets Extension (JSSE). The authors recommendations for the cipher suites is to use the JSSE defaults.

Another topic treated by the authors is about the certificate and key management in Java. The notions of trustore and keystore are very well explained and examples about how to use the keytool tool are provided. Last but not least examples about how to manipulate the trustores and keystores programmatically are also provided.

How to protect data at rest

The goal is how to securely store the data but in a reversible way, so the data must be wrapped in protection when is stored and the protection must be unwrapped later when it is used.

For this kind of scenarios, the authors are focusing on Keyczar which is a (open source) framework created by Google Security Team having as goal to make it easier and safer the use cryptography for the developers. The developers should not be able to inadvertently expose key material, use weak key lengths or deprecated algorithms, or improperly use cryptographic modes.

Examples are provided about how to use Keyczar for encryption (symmetric and asymmetric) and for signing purposes.

 Generation of secure random numbers

Last topic of the chapter is about the Java support for the generation of secure random numbers like the optimal way of using the java.security.SecureRandom (knowing that the implementation depends on the underlying platform) and the new cryptographic features of Java8 (enhance of the revocation certificate checking, TLS Server name indication extension).

Chapter 7: SQL Injection and other injection attacks

This chapter is dedicated to the injections attacks; the sql injection being treated in more details that the other types of injection.

SQL injection

The sql injection mechanism and the usual defenses are very well explained. What is interesting is that the authors are proposing solutions to limit the impact of SQL injections when the “classical” solution of query parametrization cannot be applied (in the case of legacy applications for example): the use of input validation, the use of database permissions and the verification of the number of results.

Other types of injections

XML injection, JSON-Based injection and command injection are very briefly presented and the main takeaways are the following ones:

  • use a safe parser (like JSON.parse) when parsing untrusted JSON
  • when received untrusted XML, an XML schema should be applied to ensure proper XML structure.
  • when XML query language (XPath) is intermixed with untrusted data, query parametrization or encoding is necessary.

Chapter 8: Safe File Upload and File I/O

The chapter speaks about how to safety treat files coming from external sources and to protect against attacks like file path injection, null byte injection, quota overloaded Dos.

The main takeaways are the following ones: validate the filenames (reject filenames containing dangerous characters like “/” or “\”), setting a per-user upload quota, save the file to a non-accessible directory, create a filename reference map to link the actual file name to a machine generated name and use this generated file name.

Chapter 9: Logging, Error Handling and Intrusion Detection

Logging

What should be be logged: what happened, who did it, when it happened, what data have been modified, and what should not be logged: sensitive information like sessions IDs, personal informations.

Some logging frameworks for security are presented like OWASP ESAPI Logging and Logback. If you are interested in more details about the security logging you can check OWASP Logging Cheat Sheet.

Error Handling

On the error handling the main idea is to not leak to the external world stacktraces that could give valuable information about your application/infrastructure to an attacker. It is possible to prevent this by registering to the application level static pages for each type of error code or by exception type.

Intrusion Detection

The last part of the chapter is about techniques to help monitor end detect  and defend against different types of attacks. Besides the “craft yourself” solutions, the authors also re presenting the OWASP AppSensor application.

Chapter 10: Secure Software Development Lifecycle

The last chapter is about the SSDLC (Secure Software Development Life Cycle) and how the security could be included in each steps of development cycle. For me this chapter is not the best one but if you are interested about this topic I highly recommend the Software Security: Building Security in book (you can read my own review of the book here, here and here).

Book review: Continuous Enterprise Development in Java

This is a very short review of the Continuous Enterprise Development in Java book.

The book can be easily split in two parts.

The first part of the book from chapter 1 to chapter 4 javaArguillian contains general information about the difficulty of testing the JEE applications, about the software development cycles, the types of testing and some more technical details about the testing frameworks (JUnit and TestNG), about build tools like Maven and (JBoss) Forge, about version control (only Git deserves a paragraph) and (finally) about the Arquillian which is presented as “an innovative and highly extensible testing platform for the JVM”.

A very nice introduction is done to the ShrinkWrap  which is an API to create programmatically deployable JEE archives (jars, wars, ears).

An entire chapter (Chapter 3) is dedicated to write and deploy some business code and the associated Arquillian tests. Almost all the tools used in this chapter are JBoss or RedHat tools; Forge for the build of the application, JBoss Application Server to deploy the application, JBoss Developper Studio to deploy on the (Red Hat) OpenShift cloud service.

The second part of the book from chapter 4 to chapter 12 contains the implementation of the http://geekseek.continuousdev.org/app/root/show application, which is the JEE application. Every chapter is treating one aspect of the application: chapter 5  treats the persistence layer, chapter 6 the integration with NoSql data bases, chapter 7 the services layer, chapter 8 the REST services, chapter 9 the security, chapter 10 the user interface and chapter 11 the deployment on live.

Every chapter follow the same pattern, it starts with an introduction to the technology that will be used within the chapter, then the use cases and the business requirements are presented then it follows the implementation of the requirements and lastly the testing of the implementation using Arquillian.

I will conclude my ticket with a few points about what i like and what i don’t like about this book.

What i like about this book:

  • The author clearly masters the different JEE components; the technology introduction paragraphs of each chapter of the second part of the book are very clear and easy to understand.
  • The author knows the Arquillian framework inside out; all the examples are well explained and the introduction to ShrinkWrap is very well done.
  • Some of the chapters contains very valuable external references, like PicketLink for the security or Richardson Maturity Model for REST.

What i do not like about this book:

  • Too much marketing of the RedHat/JBoss products; I would have preferred to have more vendor agnostic examples of use for the Arquillian framework.
  • The subtitle of the book is “Testable Solutions with Arquillian” so it suppose to focus more on the testing part of the applications. Unfortunately, for me the book is not focusing on testing the applications but rather tries to  present how to continuously develop (JEE) applications and integration testing is only one part of this.
  • Nothing is said about the integration of Arquillian with other Java (non JEE) projects/frameworks like Spring and Guice and how Arquillian could ease (if it it can) the testing of the applications using these frameworks.

AppDynamics Pro – basics

The goal of this ticket is to present and explain the basic notions of the AppDynamics Pro product.

  • Node – a node is the basic unit of processing that AppDynamics monitors. A node is instrumented by an AppDynamics agent.
  • Tier – a tier represents an instrumented service or multiple services that perform the exact same functionality. It represents a more logical view of the application.A tier is composed of one or multiple nodes.
  • Application – multiple tiers gathered together.
  • Business Transaction – represents a distinct logical user activity. The entire application traffic is organized in Business Transactions.
  • Transaction Snapshot -set of diagnostic data, taken at a certain point in time, for a specific Business Transaction across all the tiers though which the transaction has passed. The Transaction Snapshots are triggered periodically (every 10 minutes) or automatically for the slow and error business transactions.
  • Metrics -application performance informations sent from the App Server Agents and Machine Agents to the controller.
  • Baselines – set of metrics within a time range.
  • Baseline Deviations – degree of deviation from baseline at any given point in time and by default are calculated by a number of standard deviations above the average.
  • Service Endpoint – performance metrics focused on a particular service or set of services independent of business transactions.
  • Health Rule – defines a condition or set of conditions in terms of metrics. The condition compares the performance metrics that AppDynamics collects with some static or dynamic threshold that you define. If performance exceeds the threshold, a health rule violation event is triggered. There are two types of thresholds: Warning and Critical.
  • Diagnostic Session – the goal is to collect extra Transaction Snapshots for one or more Business Transactions for a period of time.
  • Events – emitted when the application state change. Eight type of events:
    • Health rules violation
    • Too many slow transactions
    • Too many errors
    • Code problems
    • Application changes
    • JVM and CLR (.NET) Crashes
    • AppDynamics Config Warnings
    • Discovery (new application, tier or done discovered)
  • Errors – AppDynamics treat as errors the following events:
    • unhandled exceptions
    • HTTP error codes from 400 to 505 (the error codes to catch are configurable)
    • Error or Fatal logging events (Log4j or java.util.logging)
  • Information Points – collects metrics outside the context of Business Transactions and across several Business Transactions. For me it looks similar with the Service Endpoints.
  • Data Collectors – collects extra-information at the Business Transaction level like application code arguments, return values, and variables and displays the information in the Call Drill Down panels. There are two types of Data Collectors : method invocation date collectors and HTTP data collectors.

How to use an external JavaScript file in a BIRT report

In a recent assignment I had to write some custom Java Script code to treat some table cells from an Eclipse BIRT report.

This ticket explains the setting of an external Java Script file in a BIRT report.

Define the resources folder for your BIRT project.

First step is to define the resources folder for your BIRT project. Go to the project properties -> Report Design ->Resource (as shown in the following screenshot). In our case the BIRT project is a (Java) Maven project so all the external resources are in the folder src/ressources.

BIRTProjectResourceSetting

Add the external Java Script file(s) to the BIRT report

In the property editor of the BIRT report, define the external resource files (in the following screenshot the “CustomFunctions.js” was added an external JavaScript file).

BIRTReportPropertyEditor

After adding the JS file, the rptdesign file the will look something like :

<report xmlns="http://www.eclipse.org/birt/2005/design" version="3.2.23" id="1">
 <property name="createdBy">Eclipse BIRT Designer Version 4.3.1.v201309091055 Build <4.3.1.v20130917-1035></property>
    <list-property name="includeScripts">
       <property>CustomFunctions.js</property>
     </list-property>
....

Use the custom JavaScript functions in the report

In the BIRT expression builder, use the custom JavaScript function (as in the following screenshot):

BIRTExpressionBuilder

Update the BIRT web viewer

When the war file will be created, the src/ressources content will be copied under the folder WEB-INF/classes so, the BIRT web viewer servlet should be instructed where to find the resources folder under using a context parameter:

 <!-- Resource location directory. Defaults to ${birt home} -->
 <context-param>
 <param-name>BIRT_RESOURCE_PATH</param-name>
 <param-value>WEB-INF/classes</param-value>
 </context-param>

Generating Excel files with Apache POI – Removed Feature: Format from /xl/styles.xml part (Styles)

The problem

Some (big) Excel files generated using Apache POI cannot be correctly open by Excel (none of the styles applied to the cells are rendered). The error message shown by Excel is the following one :

Removed Feature: Format from /xl/styles.xml part (Styles)
Repaired Records: Cell information from /xl/worksheets/sheet1.xml part
Cell information from /xl/worksheets/sheet2.xml part
Repaired Records: Cell information from /xl/worksheets/sheet3.xml part

The cause

The root cause is that Excel can handle only a limited number of cell styles by workbook; Excel 2010 for example can handle 4000 cell style by workbook (see Excel specifications and limits).

The solution

The solution is quite simple (in theory). You have to limit the number of unique instances of org.apache.poi.ss.usermodel.CellStyle used in your workbook. For this you can use the POI utility class org.apache.poi.ss.util.CellUtil.

GenericSignatureFormatError while deploying SOAP web services

This ticket will present some problem that I encountered using  JAXB.

Environment

  • OS: Windows 7
  • Servlet container : Tomcat 7.X
  • JRE: Sun Java 1.6.0_11
  • JAXB version: 2.2.1

Stack trace

Trying to deploy a web application containing (SOAP) web services  failed with the following stack trace:

WSSERVLET11: failed to parse runtime descriptor: 
java.lang.reflect.GenericSignatureFormatError
at sun.reflect.generics.parser.SignatureParser.error(SignatureParser.java:103)
at sun.reflect.generics.parser.SignatureParser.parseSimpleClassTypeSignature(SignatureParser.java:262)
at sun.reflect.generics.parser.SignatureParser.parseClassTypeSignatureSuffix(SignatureParser.java:270)
at sun.reflect.generics.parser.SignatureParser.parseClassTypeSignature(SignatureParser.java:244)
...
 at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147)
 at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:124)
...

Cause of the exception

One of the web services had as return value a list of enums. The enum was defined something like :

public enum Season { WINTER, SPRING, SUMMER, FALL }

(no default constructor).

In order to fix the problem it must add a no parameter contructor; something like:

public enum Season { 
WINTER, SPRING, SUMMER, FALL 
 Season() {}
}

How to deploy from Ant to Tomcat through SSL

Problem: Deploy a war using the Ant to Tomcat. The Ant task should be something like this (where ${tomcat-manager-url} is something like httpS://targetServer:port/manager/text):

<target name="deploy" description="Deploy application to tomcat">
<echo>deploying from local source</echo>
<deploy url="${tomcat-manager-url}" username="${tomcat-manager-username}" password="${tomcat-manager-password}" path="/${deployed-application-name}" war="file:///${project-workspace}/${war.name}" />
</target>

Solution: The basic idea is to add the server certificate to the keystore from witch the deployment will be done and use this this certificate to talk with the server through SSL.

Step 1: Get and save the server certificate to the disk.

Step 2: Add the server certificate to the keystone truststore of the system from which Ant will deploy the application.
C:\>keytool -importcert -keystore keystoreFile -trustcacerts -alias targetServer
-file full path to the certificate file

Step 3: Execute the ant script script with the following system properties:
-Djavax.net.ssl.keyStoreType=jks
-Djavax.net.ssl.keyStore=Full path to the keystore file
-Djavax.net.ssl.keyStorePassword=keystore password
-Djavax.net.ssl.trustStore=Full path to the keystore file
-Djavax.net.ssl.trustStorePassword=keystore password

Problems: Some errors that can appear and how to solve them.

Problem: PKIX path building failed. The full error message is:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target

Solution: The executed Ant script cannot find the keystore passed as parameter in the Step 3

Problem: No name matching “serverName” found. The full error message is:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching serverName found

Solution: The server name on which the deployment is made should be the same as the FQDN(Fully Qualified Domain Name) of the certificate. The FQDN of the certificate is something like serverName.foo.org; the server name on which the deployment is made by Ant should be exactly the same.