Tuesday, February 16, 2016

JPA has become -since it's appearance in 2006, but mainly from v2.0 "released" in 2009- the true standard for data management with relational databases in the Java world, and the new foundation on top of which data-driven applications are designed and written. It is "the committee" response to the de-facto standard back then (yes folks, Hibernate!), and the incorporation of annotation-driven configuration helped it quickly escalate its industry position to become the -now adays- number one used mechanism for data access and manipulation in JEE applications.

Within the advantages of using JPA, we encounter the ability to map queries into entities, a simplified object querying language (JPAQL), object mapping and a small set of basic validations that could take place (later to be extended by the javabean validation framework... based again on the original Hibernate Validator).

JPA is in itself safe, providing mechanisms for proper parameter binding and data transformations, together with JPAQL to SQL translation through dialects -optimizing queries for different databases and SQL forks-; but for the sake of flexibility, run-time "dynamic" queries are allowed and it seems to be the favorite way to use it among developers.

While doing great on the task of encapsulating database connections, logic, mapping and providing a real vendor-independent approach to data management through the usage of dialects, you or your team could still be misusing its flexibility in dangerous ways.

Here is a sample of this mis-usage, leading to a security vulnerability easily exploitable by a potential attacker:

Such a disruption in the query structure would result in the query returning the user with username 'admin' disregarding on whether or not the hashed password matched the one in the database.

The way to prevent this is to simply make proper use of the JPA API for parameter binding. Methods provided in the Query interface allow us to set parameters in an easy and safe way. Example code follows:

The above sample code not only provides a safe way to do parameter binding into the query, preventing a potential injection attack, but it also has some additional benefits depending on the implementation (query caching, 2nd level cache usage, etc.).

So, no. JPA doesn't have security issues. But is your team using it properly?

Monday, February 1, 2016

Imagine you are building a nice apartment for
various people to live-in. After the construction is completed and you are
delivering the house to people, you realise that the bricks used are weak.
That is exactly the situation when your source code is insecure but you deliver
the application to customers on time. At every sprint, you are quickly adding
more ‘weak bricks’ to the application. Even if the application was originally
strong, at every code change done by poorly skilled developer while adding new
features, the application becomes weak again. This vicious cycle continues…
until we can find a solution to ensure code is created securely.

No matter what defensive security controls are
put in place in a production environment, when the application source code
itself is weak, it is usually a serious attack surface that is continuously
targeted. It becomes even more difficult to protect applications when features
are being quickly added into the application for examples as during agile
development.

How can you ensure the code is consistently
secured at every sprint by every developer without losing the benefits
from working in agile?

Ensure developers have basic security
experience and can recognise potential security weaknesses and understand how
they can be fixed properly.

Perform a quick and effective analysis on
the source code before pushing the sprint code to the production
application.

Our Secure Code Warrior platform addresses the
first point by allowing organisations to measure the skillset of each developer
and train the developers by doing hands-on challenges in their own language and
framework.

Sample dashboard output from SCW platform

The second point is often a challenge for “agile”
application teams as they face issues on the amount of time available in a
sprint to perform analysis themselves or to hire an external company. So, how
do we take care of implementing these security tools in every sprint without
impacting the delivery date?

The answer is as straightforward as ‘implementing automation’ on using static
analysis, so called SAST (Static Application Security Testing) tools. Yes, you
read it right. We can automate static analysis on your developer-written source
code. Manual effort to run the SAST tools
needs to be limited as much as possible. Such implementation of SAST signifies that trained
application developers can purely focus on writing secure code and fixing
reporting weaknesses, leaving the actual evaluation job to SAST tools. These
automatically scan the source-code to uncover hidden security issues to the
developers, who can fix it immediately during the sprint. Most static analysis
tools like HP Fortify SCA, Checkmarx, IBM AppScan Source, etc. integrate with
various industry standard continuous integration (CI) and continuous deployment
(CD) tools like Jenkins / Hudson, etc.

The moment you see the above diagram, you might
be tricked to think that it may be impractical to implement and use static
analysis and dynamic analysis tools in such short sprints, although educating
developers before the release begins seems reasonable. So, let’s look at an example.
Consider a short sprint of three weeks, which means that new version of
application is delivered every 15 days. Before beginning the development of
application major version, if we put initial “one-time” effort to integrate industry standard SAST and DAST tools
into our CI / CD model of delivery, it could be useful in two ways.

When the developer checks-in the new source code,
the CI tool can automatically trigger the static analysis, deploy the code in a
test environment and run dynamic analysis, without any manual intervention of
an individual. This will provide the developer with a list of security issues
found in the source code and the deployed application, when the sprint is about
60% progressed (9th day of the sprint begin). This will enable
project team to know the security issues at each sprint.

The project team can than choose to:

●immediately
fix the issues (which will add little man-days to the critical path) and
delivering a more secure application OR

●Not
fix the identified issues but at least the organisation now knows about these
issues (e.g. the medium or low risk issues). You will be able to negotiate with
your customer on a new delivery date to fix them or to transfer the risk to the
customer

This is exactly the significance of effective
secure-coding training and integration of static and dynamic analysis tools
into CI / CD model. You can keep the benefits of agile development, deliver
more secure code or at least know about weaknesses before it becomes too
expensive or too late in the process to mitigate them.