Case Study: J2EE Security Architecture Review for Financial Organization
Synopsis
In an architecture review of a critical financial application, Aspect uncovered a serious access control issue that would have allowed any user to access any other user's account information.
The Client and the Application
The client is a major financial organization with several thousand applications, both internal and external. This application is a customer-facing self-service web application written for the Java EE platform. The application is complex, with twelve different external interfaces including a mainframe and MQ implementation. There are dozens of different security roles that are to be enforced with a combination of SiteMinder and custom code.
Why Did They Come to Aspect?
With a strongly process-oriented culture, this client started their application security initiative by enhancing their SDLC to include security activities. The first step was to design a set of these activities and integrate them into their existing SDLC. The activities included a rigorous security architecture review process. Aspect worked in conjunction with client team members to maximize the effectiveness of the review.
How Did We Work With Them?
In the customer's security architecture review process, the software project is responsible for preparing the materials for the review. Aspect consultants guide and facilitate the review along with a client security architect. We cover the entire threat model for the application, including authentication, access control, input validation, error handling, logging, and other security areas. We also evaluate common vulnerability areas to ensure they have been addressed. All findings go into the customer's vulnerability tracking system that Aspect helped design.
What Did We Find?
In this architecture review, the team uncovered a serious access control problem common to many web applications. While SiteMinder provided URL based access control, the application code was designed to "forward" requests to an arbitrary location, specified by a parameter. An attacker could use this flaw to bypass the access control checks, and access unauthorized functions. In this case, the attacker could add and delete registered users of the application.
What Happened?
The use of forwarding is against the Java EE application security best-practices that Aspect developed for the client. The deveopment team re-architected the application to use another addressing scheme that is not susceptible to the attack described, thus avoiding costly remedial work or a security breach.