Tuesday, February 16, 2016

Tips & Tricks - JPA (Java Persistence API) doesn't have security problems, but you might!

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:

@PersistenceContext(unitName = "movie-unit", type = PersistenceContextType.EXTENDED)
private EntityManager entityManager;

@Inject
PasswordEncoder passwordEncoder;

public User authenticate(String username, String password) {
    // ... some function code ...
    String encodedPassword = passwordEncoder.encode(password);
    String query = String.format(
       "from User where username = '%s' and password = '%s', 
        username, 
        password);

    User user = em.createQuery(query, User.class).getSingleResult();
    // ... some function code ...
}

Imagine a playful attacker intentionally sending an input that could disrupt that query string. A typical example of such a trial would be and result in:

// username = admin' OR username = 'a
---> query = from User where username = 'admin' OR username = 'a' and password = '!T$AVSDF17239agR@$^%%'

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:


@PersistenceContext(unitName = "movie-unit", type = PersistenceContextType.EXTENDED)
private EntityManager entityManager;

@Inject
PasswordEncoder passwordEncoder;

public User authenticate(String username, String password) {
    // ... some function code ...
    String encodedPassword = passwordEncoder.encode(password);
    String queryS = "from User where username = :username and password = :encoded";

    TypedQuery<User> query = em.createQuery(queryS, User.class);
    query.setParameter("username", username);
    query.setParameter("encoded", encodedPassword);

    User user = query.getSingleResult();
    // ... some function code ...
}


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?

Viswanath Chirravuri (Application Security Architect, Gemalto) and Anibal Ambertin (Captain Nomad, Security Code Warrior)






Monday, February 1, 2016

Leading Practice – Secure Coding in an agile SDLC

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? 
  1. Ensure developers have basic security experience and can recognise potential security weaknesses and understand how they can be fixed properly.
  2. 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.

Viswanath Chirravuri (Security Architect, Gemalto) and Pieter Danhieux (CEO, Secure Code Warrior)